php框架 - Laravel vs CakePHP vs CodeIgniter 的看法（性能，开发效率，负债能力）

Question

最近打算用做一个比较中型的PHP应用，想到用比应用广泛的MVC框架。
要求

1.支持命名空间
2.不支持PHP4
3.架构、性能更重要
4.长期稳定，而不是很快就会被淘汰或者解散的框架

Yii2、symfony2都太庞大，不适合。考虑到了Laravel CakePHP Kohana CI。
先说一下自己对这三款框架的看法

1) CI 2.x
    官网一种放弃状态
    CI框架太轻巧，很多东西都要自己做，非常陈旧
    CI框架在IDE中无法进行代码跟踪，点击类名无法跳转过去

2) CakePHP 2.x
    为什么非得向下兼容PHP4?弄得非得用一个蹩脚的App::use()来替代namespace！
    为了兼容PHP4弄得整个架构乱七八糟
    如果CakePHP放弃对PHP4的兼容，应该会有更多的人使用

3) Laravel
    不支持php4,支持命名空间
    网上非常多的好评，仔细看每个评测文章都是复制粘贴的感觉很枪手。

网上包括segmentfault上都有对框架的比较，但基本上是都是摘抄的转载的，而不是自己使用过后的真实体会，期待有使用过后的真实体会，而不是复制粘贴网上人云亦云的测评。

---

今天使用Laravel，发现文档不是官方宣传的那样丰富，而是少非常不清晰。
Route的所有方法有那些，根本就找不到这些说明。官方的文档只是几个简单的例子，根本就不详尽。

---

2015-6-16 补充：
再次回到这个问题，我已经一路使用了CodeIgniter、ThinkPHP 再到Yii2，开发了一些完整的项目。现在发觉 PHP 的 MVC 模式确实难以满足需求，到后来的 component，现在再到laravel的思路，难以理解，总是一直感觉在追赶，特别疲惫。

其实一开始，我走过太多的弯路，很多年以前，对于OOP都有着强烈的排斥和极端的抵触，原因就是使用了class 类会导致程序运行非常慢，究其根本是我使用的运行环境实在是太烂了，虚拟主机都不如，而且还是win。到后来MVC模式，加载的文件数目几乎是无法比拟。后来开始使用MVC框架，普通的主机已经完全无法支撑，绝大部分虚拟主机大部分都是win服务器、而且PHP最多最多PHP5.3就不错了，还有很大一批居然还在PHP5.0（虚拟主机就是只提供一个FTP用户名密码的那种）。

走过太多的弯路，一直以来总是被硬件条件、运行环境束缚思维。

Answer 1

CakePHP没用过不予置评。

一个php程序员的成长过程往往可以类比成 CI -> Laravel -> CI。CI和Laravel基本可以认为是过去几年和现在两个时期的PHP框架霸主，使用率最高的框架。CI适合完全新手和高手，Laravel适合中级别程序员提高生产力。

详解

CI提供的东西少，恰恰是其立于不败之地的最重要的原因。

另外，CI的文档简直就是开源软件的典范，非常之清晰、详尽！

它能给我们最核心的功能，让我们真正感悟php做web的精髓，感受MVC的真正魅力。BTW，不要小看MVC，它作为现代GUI软件开发久经考验的最流行结构，不是在还没用过MVC时候看两眼描述就能理解的，我们需要去做，去感受。

---

Laravel号称完全模仿Rails，不得不承认他们做到了，包括性能。^_^ Laravel其实是符合互联网产品的开发特点的：迅速做出可用产品，再高速迭代。

如果你用了Laravel，也不用担心性能问题，因为当出现性能问题的时候，性能也就不是问题了。有用户有钱有时间，想怎么重构怎么重构，妥妥的~

Answer 2

你的分析很多都是错的.

(1) EllisLab确实曾经想找人接盘CI, 但事实上, github上CI的更新一直没停过.

(2) cakephp 2.x只支持php 5.x, 并不支持php 4.x, 支持php 4.x的是cakephp 1.x, cakephp 2.x不用命名空间是因为命名空间是php 5.3后才有的, 而原先php社区的计划是把这些特性放到php 6里. 仅支持php 5.4的版本是cakephp 3, 马上要出正式版了. 如果你优先看中长期稳定的话, cakephp肯定是首选, 它到现在还在维护仅支持php 4.x的cakephp 1.x版的bug修正.

(3) 如果你认为yii2和symfony算大的话, Laravel你就不该考虑, 这东西是构建在大量symfony components上的, 不过大小真有那么重要么? 现在也并不是10多年前1MB空间1~2RMB的时代了, 不是么?

Answer 3

7月20日更新：最新的Yii2已经原生支持读写分离，支持一个写数据库和多个从数据库。也支持多个写库多个从库！

不赞同题主关于Yii2庞大的说法，Laravel算上他依赖的第三方代码，比Yii2文件多的多。况且仅仅从一个文件多少就来断定一个框架是否庞大是非常肤浅的。

事实上Yii2本身非常灵活，绝大部分的组件是可被替换掉的。你可以阅读一下他们最新的文档，Yii2本身就可以单独的嵌入到你原有的代码里去，你想用AR就载入AR组件(事实上这个功能在Yii1时代就提供了，当初我就在本自有项目里非常容易的用到了Yii1的model组件，不过由于之前的架构实在过于混乱加上一些其他缘故，最终放弃了该项目)。

Yii2本身功能完善，而且一直在积极吸收其他框架优秀的特性，比如symfony2的AssetBundle、WebDebug都是非常实用的功能。然后是后台神器Gii+GridView这两个组件，应付大多数后台开发就是简单的点两下，改改就OK了，还有DataProvider这个组件也非常实用。总之大部分web开发中要用到的功能Yii都帮你提供了现成的，你只需要用就好了，不好用就继承一个改改，然后在配置里将他替换掉就OK了。

然而在提供如此多功能的前提下，Yii2的性能居然不差，我已经有两个项目是基于Yii2的，其中一个日均pv在300W左右，完全无压力。很多第三方的测试也显示Yii框架的性能一直名列前茅(yaf、phalcon这些用C写的就另算了，CI功能太简单，我觉得拿他来比较不合适)

当然，Yii2也不是没有问题，就目前我遇到的一个情况就是某些地方组件的耦合度有点高，比如yii\web\User这个类，他为了最大限度的提升开发效率，跟ActiveRecord耦合的有点高，在web上这当然没问题，但现在移动开发当道，这个就有点不适合了，需要自己改一些东西。

另外一个就是框架本身缺少数据分层的支持，所有跟数据库打交道的东西都是ActiveRecord。而由于Yii2提供的ActiveRecord非常易用，很容易就导致滥用，我其中的一个项目就是这样滥用过，很多类似这样的代码$user = User::findOne($uid);直接就写在了controller里，醒悟过来后花了不少时间来处理。

当然怨念最深的就是号称为web2.0而生的框架，居然从1到2都没有官方支持的读写分离功能，这点实在说不过去。

最后Phalcon绝对是神器！http://phalconphp.com

Answer 4

Laravel的核心思想是IoC和Facades，要实现这两个思想就难免需要大量的抽象类，一个框架好不好要综合来看，整体看来Laravel还是非常优雅的，尽管为了实现Facades使用了一些__call魔术方法，但这样就非常完美的解决了耦合问题，我觉得没有一定的大型网站开发经验很难真正的体会解耦的重要性，因此相比性能，业务的耦合度要重要得多，其实代码本身都不复杂仔细去分析几个核心文件你就会豁然开朗，推荐一篇文章，说得很细http://www.yuansir-web.com/?p=1012&preview=true

我个人觉得现在的框架主要分两种，一种是纯MVC的，CI是典型代码，很多程序员自己写的框架都是受CI的影响，我个人就是深受CI的影响，因此在自己的项目里面自己写的框架基本可以算作是CI的核心剥离，去除了不需要的兼容性和国际化的部分，但是经过了一些大型项目之后，我发现现有的MVC已经远远不能满足我对业务的需求，复杂的代码导致越来越多的MVC三层庞大错综，依赖严重，很多进行业务拆分的时候发现MC已经完全没有办法拆开了，工程量浩大，最后只有把代码写得越来越像面条，越拉越长

最近自己重写框架的时候我的View类不得不从static转换为普通类，使用new的方式实例化，因为只有这样我才能在模板中使用$this指向View类，从而在模板里面调用一些View的功能函数，如request实例$this->request()->get('user_id')，获取$_GET参数user_id，但是如果这样做我原来代码里面View::display('index.php')这样的调用方式就不行了，在PHP5.5中会有一个警告，说你使用静态方式调用非静态类，但是我又不想使用new的方式，一方面不够优雅，另一方面不够独立，如果给在Controller里面使用View就需要继承或者实例化之后赋值给Controller的一个属性，这样就依赖了，我希望Controller是独立的，在不使用View的时候（很多情况的API开发不需要View）完全都不用引入View类，而这个问题正是Laravel的Facades解决的

Facades允许使用静态方式调用非静态累，具体可以看代码的__callStatic，原理很简单，尽管这样牺牲了一些性能，但为了这个优雅性我觉得还是值得的，然后最重要的是IoC和Facades的结合，为什么Laravel能和使用大量的第三方框架的代码，完全基于其先进的IoC思想，不用怎么改动第三方代码就可以轻松的注入到IoC容器中，然后组织绑定到Laravel中，看起来像东拼西凑的，其实核心思想就是这样的，任何模块都是独立的，就好像盖楼一样，所有的配件都是独立生产的，然后组合到一起，只有这样框架的耦合才完美的解决了，因此我现在写代码都会写得特别独立，不需要用某个功能，直接删除掉相应的文件，整个框架不受任何影响，依旧顺畅执行

说了很多，其实主要是想说国外很多框架之所以火不是没有理由的，要学会从中立的角度去看待别人的思想精髓，不能从程序员简简单单的测评就一口否定，这也是开源的精髓，集思广众

Answer 5

本人项目历程：原生PHP->CodeIgniter->Yii1->Yii2

2014年07月12日那会，Yii2处于Beta期，Yii官方也不推荐用于生产环境，同时个人也认为还不成熟。

经过一年时间发展，目前截止2015年10月15日，Yii2已经非常成熟了，而且本人目前的项目也是基于Yii2开发的，已运用到生产环境中。

具体开发、修复bug历程，可以看Github和官网

目前，部分文档并不健全，比如 Development Tools 模块，指南文档

Answer 6

swoole如何? http://www.swoole.com/

Answer 7

Laravel 我尝试过写一个DEMO，并没有想象中那么好用，个人觉得小项目用 CI 足够，大项止还是用 Symfony2 吧！

Answer 8

我个人认为Laravel对第三方包依赖太多(特别是Symfony)，给人的感觉就是对Symfony的二次开发

Answer 9

Laravel API文档也太精简了吧。精简得让你不看源码都不知道怎么用。

Answer 10

laravel5.1一个空项目，或者链接数据库，取一个表的几条记录显示出来：
用 ab -t 10 -c 10 http://127.0.0.1/laravel511/public/index.php
或 ab -n100 -c100 http://127.0.0.1/laravel511/public/index.php
得出的结果 request per time: <50

而如果换slim3 或 ci3 测试，可以达到 reququest per time : 200-300

如果不用任何框架，同样测试，则可以达到：request per time : 1300

不明白这样的情况下，还要用框架吗，项目套上框架性竟然能这么低啊。

赶脚白瞎了机器硬件啊。