为什么我不太想用 Laravel ？

挺好的，批评的有理有据。

我选择 Laravel。

单纯评价框架没意思，结合实际项目

没有 java 的命，得了 java 的病。

为了 写而写，要简单你用 yaf，不用框架。搞笑的是 第一个理由竟然是 IDE 不友好，这个理由服了。

就凭作者写的 1.4，就一看楼主没有了解 composer 的优点，更不用说 laravel 了。 连 larave 一些不常用的优点都不了解，如何就能评价 laravel 呢？
好好看看 composer.json require-dev 这个节点意思，作者能不能活学活用，灵活使用 Laravel. 看代码
```php
<?php

namespace App\Providers;

use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
/**
* Bootstrap any application services.
*
* @return void
*/
public function boot()
{
//
}

/**
* Register any application services.
*
* @return void
*/
public function register()
{
if ($this->app->environment() !== 'production') {
$this->app->register(\Barryvdh\LaravelIdeHelper\IdeHelperServiceProvider::class);
}
}
}

```

所以老哥 你到底推荐用啥???

@ninja911 我已经是加到 require-dev 里的，不过这同样是对代码有侵入性，只不过侵入的是非 prod 环境。

@Light3 不做推荐，个人喜好而已。

第一个问题我建议你可以期待一下 Laravel Plugin 的更新，未来版本会移除对 IDE Helper Generator 的依赖（ https://plugins.jetbrains.com/plugin/7532-laravel-plugin ）；当然对于你的理由本身其实我并不赞同，难道你不用任何需要修改 composer.json 的开发辅助工具吗？例如 debugbar ？（ provider 的问题在 5.5 会有改善） btw，我也不是很能接受 laravel 的 facade 的设计，在我看来没必要。。。

至于通过 phpdoc/annotations 实现路由，一方面这是一个设计思路的问题，分散和集中各自有各自的优势。另外一方面这个的解析效率会是个瓶颈。php internal 里有人提过一个 annotation 的 rfc，但是因为实现上的一些问题最终就停留在了讨论阶段，都没开启投票。。。

不喷怎么显得我牛逼？？？！！！

@vus520 哈哈哈，赞

laravel 的 breaking changes 太多，可能你只是升级了一个小版本 （ a.b.1 -> a.b.2 ） 就坏了。

写的还行，还算蛮有道理，不过也只是「为什么 **我** 不太想用 Laravel 」而已，作者所列举的那些槽点只是对他自己而言的，其他人可能并不感冒 \_(ツ)_/

1. 对 IDE 不友好：确实，IDE 很好用很方便，省很多事，但是也不是所有人都离不开 IDE 的语义识别代码提示，而且我认为 `laravel-ide-helper` 足够解决问题。至于觉得这个方法不优雅，这是个权衡的问题，见仁见智；
2. Laravel 做得太多
- 写法五花八门：很多语言本身写法就已经五花八门了，标准很关键；
- 容易误导刚入门的程序员：刚入门就不要用框架了吧，先把原生 PHP 熟练了再说；
3. 反直觉：我个人是觉得还好；
4. Blade 模板，依然是标准问题；

再下面的是作者的个人喜好，这也确实是选择框架的一个重要考虑因素。综上，作者个人不喜欢 Laravel 还是有原因的，并不是无脑黑，但这篇文章对于其他人来说，可能并没有什么使他们放弃 Laravel 的说服力。

laravel 确实用到了很多魔术方法，IDE 对魔术方式支持不太好，但是可以通过注释提示 IDE，我记得 guzzle 就是通过注释实现的 IDE 提示 get、post 等魔术方法。

service container 无法避免啊，即使是 symfony 通过容器获取的信息 IDE 也不能提示，本身容器就是大杂烩，只能在注释让 IDE 自动提示。

本人是从学习 laravel 到转向 symfony，都是很不错的框架，学习之。

以前公司基于 Laravel 做项目的时候研究过源代码代码

感觉就是过度设计的一大陀，想把 PHP 变成 Java 的框架。

yii 叫还行…我不知道你是只用过 yii 还是用过 yii2

IDE 问题我也很头疼，写法的问题看团队约定吧，如果都是各写各的，我觉得用其他框架也会有这样的问题

laravel 设计过度的东西，蹂躏进来那么多东西，连奥卡姆剃刀都不知道，只是一味追求华而不实的东西。

"N 年前 Laravel 刚面世时，的确让很多人眼前一亮，众人惊呼原来 PHP 代码还可以写得这么简洁优雅。"

我觉得正好相反，用 Laravel 失去了 PHP 的简洁优雅。Laravel 让 PHP 变得像 java 那么复杂，那为什么不直接用 java 呢？ 对，所以我现在正在学 java。

哈哈... V2 的 三大 论点

1.苹果 和其他
2.laravel 和其他
3.辞职等过年 和其他

php 本身就是脚本语言，没有必要搞那么复杂。

解决 IDE 不友好的问题，只需要加个注释， @property / @method

@MelodyMKII 想给 yii2 跪下。

换成任何一门语言的一个框架都可以写一篇比作者这篇还长的精彩吐槽

CI 虽然代码比较过时，但是简约的设计思想还是很先进的，又容易上手。CI -》 laravel -》 CI -》 Slim，silm 用得还不错

看了下文章，推荐作者试一下 Phalcon 框架

作为一个 php，java，python，golang，c#（ asp.net ）都写过的 hello world 工程师，这种文章就是月经贴，挑战或者博眼球吸粉的文章而已。

1 对 ide 不友好？你说的容器获取到的实例无法提示成员的问题，这是由于 php 本身是弱类型的原因，和框架是没有关系的。你去看看 java 的 spring，从容器中 get 出来的 bean 难道不是 object 吗？难道不要强制类型转换吗？况且 php7 出来那么久了，我用的不多，但是我还是知道他是有严格模式而且支持强类型的。至于其他什么 ORM，Facade 无法提示可以照着 5 楼所述。

2.1 讲到这个事情我就总是想起当年 Python，Golang 刚刚火起来的时候，人人都吐槽写 Python 要用游标卡尺，写 Golang 要被迫适应他的代码 format 方式，骂这些语言的作者在编码风格上强奸程序员。这些语言为了让所有风格和不同水平级别的程序员能够写出统一风格的代码，做了很多专制制度，而 PHP 从一开始所倡导的理念就是自由开放，给了程序员们最大的自由。而现在这反倒经常成为 PHP 的黑点。说句不好听的，有些人啊就是贱就是矫情，现在的程序员真难伺候。

2.2 我阅读过 BAT 某大厂的一款 PHP 框架源码，里面也把一些 PHP 中明明有的内置函数做了一层封装，比如说 json_encode，我开始也百思不得其解，直到后来看到 sh 部署脚本中，PHP 版本还是 5.2 我就明白了，框架作者考虑到 PHP 在版本迭代的过程中可能某些扩展和函数会被废弃，因此做了一层封装，而且 PHP 扩展一般都是没有命名空间的，而且大家都知道 PHP 的内置扩展和函数命名都是五花八门的，在一堆面向对象代码中写起来会很不优雅，再次封装一层也是为了让一些东西统一，或者在以后底层函数出现变化之后能够做更少的替换。

3.1 我也不想扯太多，麻烦文章作者去翻一番 Laravel 官方文档看看 Facade 的应用场景和解决的问题是什么再来喷把。作者的逻辑就好比是在冬天穿了一件夏天的衣服，冷得打哆嗦，还不停的骂说这衣服怎么这么破。

3.2 难道 JSP，ASPX 里面不能写逻辑？你喜欢什么模版引擎你自己用 Composer 配一下改一下就 OK 了，强行凑喷点条数我也是服了。

4.1 Symfony 那种注释写法不就和 JAVA 里面的注解很像吗，各有各的好处。我就是喜欢集中式的配置文件。这样的项目如果给别人接手，看一眼路由配置我就大概能从宏观角度知道整个项目的运作和具有的接口了，无论是做路由分组，批量分发中间件（ JAVA 里面的拦截器）或者其他什么 URL 前后缀修改也是非常方便的。还是那句话：你喜欢什么路由你自己用 Composer 配一下改一下就 OK 了，强行凑喷点条数我也是服了。

4.2 你说的不就是 Hibernate 里面的注解吗？ Laravel 其实是一个很轻量松散的框架，ORM 你用的不爽你可以直接替换掉或者干脆不用，像我我就不喜欢 ORM，我就喜欢查询构造器。好像 Laravel 官方的作者也说过，数据库，项目实体模型关联这些东西，在架构设计的时候就应该要非常谨慎地考虑。如果你做一个开发，数据库还要动不动就大修改，那么我认为你这个项目从一开始设计上就存在很多不合理不优雅的地方，说句不好听的话：你这种设计水平就算用了 Laravel 这种优雅的框架，也还是能把代码写的一团糟。而且 migration 本身就类似于一个数据库 DDL 的表结构版本控制，它记录了你的项目数据库修改日志，如果以后代码或者数据出现问题也可以很方便的回滚，这个优点你怎么不说呢？还是那句话：migration 你爱用不用，Laravel 又没有逼你使用它。

可能有些地方喷的不是很到位，还欢迎大家轻喷和指出我的错误。

哦对了，还有第一条，php5.5 开始对象就已经有了 class 成员可以让 ide 很方便的提示，而楼主给出的代码居然还是用的 make("xxx")这种字符串的方式给出对象字面量，有优雅和方便的特性放着不用能怪框架？

一直用 ci

laravel，性能差，自由度不够，容易使人懒，还学不到东西。把新手搞得什么都不会！

作为用上世纪框架的人瑟瑟发抖。

全文我就感觉到是作者想用 symfony，无奈用 laravel

一直在用 Symfony

一直在用 Symfony +1

用了 3 年多的 symfony，体会就不想要用别的框架了。。

一直在用 Symfony +4

文中作者居然没有用过 phalcon，还敢品头论足

@jhdxr 我记得 dz 有个无心宠物虾米版，作者就是你整个头像

相比 Laravel 我更喜欢 slim，但是我的 slim 确实借鉴了不少 Laravel 的东西，当然还有 Symfony.
Laravel 的优秀没人会去质疑，但现实的世界里面还是适合自己和项目才是最重要的。

简直胡扯 谁说不能追踪的...

通过 block doc 就可以实现追踪；额、

对 IDE 不友好? 装个 laravel 插件你提到的基本都支持了.

@ivmm 我就是那个虾米→_→ （逃（那个已经是很多很多年前了。。。

赞楼主，Laravel 的确反直觉。
我也有项目实际用了 Laravel。就效率来看，lara 的效率并不比其他框架差，我的实际测试时 lara 比 yii2 要稍微优越点。不过在实际团队开发过程中，lara 的确不好推，对于新人来说很难理解 Facade 等概念。
个人宁愿啃 TP 都不愿意碰 Laravel。。。

所以在 v2 楼主写这个帖子的意义就在于爽于被喷的快感

@jhdxr 是啊，满满的都是回忆了

@ywisax 我猜，你没有 composer dump-autoload

Laravel 感觉太重了，封装太多。我用 TP。。。勿喷。

感觉像是在推荐 laravel

挺好的，批评的有理有据。

我选择 Laravel。

我选择 Laravel。

发这种吸眼球的文章就做好被喷的准备，心理素质不行就不要发这种，有这时间不如分享一些最佳实践

果然任何一篇关于框架的帖子都能引起一场大战

我感觉你只适合自己撸个框架~然后让别人喷你！！！

说实话 slim 足以

不用，因为名字都叫不顺

想自由度就用 symfony，想省事就用 laravel。 框架嘛，都是工具，顺手就行~

喂喂你们把人家说跑了啊

Yaf 党有么

@ck65 我就静静的看着大家喷 哈哈 懒得一一回应

@Immortal 有。之前在朋友印象时用的 yaf，很多东西要自己实现。

我选择上世纪框架

“其实到目前为止，还没有一款真正让我喜欢的框架。”

你要求高你自己造轮子啊！到时来 v 站大家评评理

看到 LZ 被喷我就放心了。不过感觉 LZ 真心应该转 Java...

什么叫权限太大？模版说白了也是 php 代码，模版的变量、语法最终都要替换成 php，@foreach 这个也要替换成<?php foreach(){} ?>，模版能写 php 代码很稀奇吗？

我用一个叫 Fatfree 的 framework。极轻便，挺好用。

每个月都会有那么几天

简称月月喷！！

@lyragosa 用上世纪的框架+1 还有 Yaf