目录

如何挑选框架

很多时候，讨论问题从抠概念出发是个好想法。框架是团队在项目初期选定的开发框架，或者在长期开发过程中提炼的公共逻辑等。所以无论是初期挑选框架、是中途重构更换框架、还是需要抽离团队内部自己的框架，都应当以下面三个角度综合考虑

结合团队情况

团队成员情况 & 未来团队成员情况 & 所在地职业市场情况

如果团队现在和未来都只有你一个人(比如自己的toy project)，那选自己最想用的就好。但只要不是这个情况，你最好先得了解市面上常见的各种框架，然后忘记自己的个人偏好。

了解你的团队成员的现在情况，考虑你的团队未来的发展速度，未来可能加入的团队成员的情况，以及你所在地职业市场情况。打比方说，Laravel经常是个不错的选择，但如果你在产业不发达的小城市，团队又必须高速发展大量招人，选择Laravel可能很快会让你陷进“composer和现代PHP技能培训班”的窘境，而一些更“接地气”的框架则能让你的团队迅速扩张，快速满足业务发展的需求

结合项目

项目生命周期 & 未来演变方向

有的项目，作为贵司的主营业务是需要长期维护，持续迭代的。而另一些项目可能作为一些边角、过渡的项目，可能做完以后不会再有什么后续的需求。最后还有一些外包/类外包的项目，交付以后就没有需求/后续需求可以当另一个项目。

再大的项目，需求再多，如果是第三种，无需考虑未来演变的，那么框架的扩展性就能够被牺牲(从而换取开发速度或其他好处)，打比方说基于一些成品二次开发的选择就可以被考虑。再小的项目，如果是贵司的主营业务，持续迭代的，那么就算工作量再小，也必须慎重考虑框架的扩展性。

那么，什么是框架的扩展性呢? CI是扩展性很好的框架吗?ZendFramework1/2是扩展性很好的框架吗?

答案是，看未来演变方向。有的项目未来的压力在访问流量大，有的压力在数据量大检索频繁，也有项目压力在需求迭代快，变动频繁而周期短。项目面临的问题越是普遍，那么预设各种解决方案的框架可能越能减少重复造轮子，反之项目面临的问题越是极端，那么轻量化的那些框架可能更适合让你的团队自己研究解决方案对接到框架中。另外，项目维护的时间越长，变动越难预测，采用预设各种解决方案的框架的风险就会越大(那些预设的解决方案恰好能解决你的每个问题的概率越来越小)

框架本身

框架本身的基本素质

性能和跑分。除了phalcon和Yaf两个C实现的框架，其他框架请认为一样快。另外除非你在主持类似新浪微博更换PHP框架这样的事，或者说除非你管理的项目web机器超过100台，请忽略PHP框架的性能因素

psr和composer亲和性。这是双刃剑，前面已经聊过怎么看待这个特质了。

安全性。某些框架甚至本身自己有安全漏洞不多说。另外如果框架层面提供了一些安全方面的东西，建议还是要简单看一遍代码，有时那可能反而不如自己写。

功能性。也就是预设的解决方案的数量和质量，前面有提过。

模块化程度。框架内的各个部分是否能够自定义，自定义的代价多高。另一个角度是框架的各个部分是否能脱离框架运行。

表达能力(业务功能需要多少代码量来实现)，这三个特性(表达能力、功能性、模块化程度)互相冲突，无法达到三者兼得。功能丰富，模块化程度又高可以随意定制、替换的框架，往往普通的业务代码也要写一堆。一句话能写出一大堆功能的框架，往往模块化程度不理想，不容易自定义。 模块化程度高，而业务代码不啰嗦的框架，则往往没有丰富的预设功能。

周边生态和活跃程度以及兼容性。活跃的框架就还有成长和改进的空间，但相应过于活跃有时会导致应用无法兼容。另一个指标是周边的生态，有没有其他人基于这个框架开发一些周边的模块/插件之类的东西，以及文档的丰富程度、出问题后能是否容易找到的解决方案等。

PHP框架

Laravel

laravel是目前php中最火的框架，github上最热门的php框架，对java开发人员非常友好。

优雅设计、文档丰富、丰富的扩展包

ThinkPHP

因为国内，所以把tp放在第二位。

国产框架，主要有成熟版本3.2、5.0，正在推6.0

3.2只能还算是框架，更多的是提供工具函数

5.x虽然版本有点混乱，但至少借鉴了laravel及java生态一些东西，对开发者来说没有bug就可以了，对tp团队来说，应该是一个有价值的版本，让tp团队练级，过渡到6.x

Yii

Yii2

CodeIgnite

CI是比较早的一个框架，php面向过程的时代，CI就很流行。

Swoole类框架

严格来说Swoole不是框架，而是一个扩展库，但这几年基于Swoole的框架也不少，详见本站PHP/swoole页

修炼一定程度后，不论什么框架，心中有mvc，一周上手开发。

@tsingchan