告诉你 laravel 为什么在国内流行不起来

@cxbig 100k 欧元， 70w 人民币？好多啊。。。膜拜。。。

@mahone3297 别忘记税收部分，能拿到这个水准的收入，税和社保大概要占 45%。

初次看 Laravel 的 ORM ，感觉很惊艳，设计到我心里了。可惜后来发现原来是借鉴来的。。

除了 5 ，不觉得有什么问题。
laravel 把 PHP 的语法水平都体现出来了，这一点可以带动新一代的 PHPer ，可以说功不可没，让更多的 PHPer 自主的去学习，何乐而不为？
至于 smart..=,= 这种落伍的就别提了，我早就放弃它很久了...blade 还好，连 PHPStorm 都开始主动支持了（而非插件而已），可见其对 MVC 、 Layout 这块的解决机制有效。
我个人是 OK 的，唯一坑的也就是 Composer 的很多 Package 水平和二次开发的问题了。

被 rails 虐过后觉得还好~就是没 rails 调试爽~

告诉你们，法拉利在中国永远流行不起来。。。

@xuxu @raincious @pein
1, 实现自己的 HasherContract 类（ implements Illuminate\Contracts\Hashing\Hasher ），其中的加密解密都用自己的方式。
2 ，增加自己的 CustomHashServiceProvider ，继承自目前系统中的（ extends Illuminate\Hashing\HashServiceProvider ），在其中 register 方法中将上面新建的 HasherContract 类绑定到 app()['hash'] 上（$this->app->singleton('hash', function() { return new CustomHaser; })）；
3 ， config/app.php 中的 Illuminate\Hashing\HashServiceProvider::class 替换为 2 中新建的。
至此你的应用 auth check 过程将由你新建的 hasher 接管。

另外 bcrypt 是基于因子的加密，为的是防止未来攻击者计算能力提高，彩虹表碰撞时间越来越短，方便使用者调节加密层数，默认情况下因子设置的比较大。
你加密慢，黑客解密也慢，很难去否定 bcrypt ，就我的理解，这算是目前最完美的密码方案之一。用所谓流量大，并发高去理解加解密也很不合适，因为只有登录、注册时才会调用 bcrypt 函数，这两种行为相比日常房问简直是杯水车薪（除非你的应用每秒几十个人注册）。


缺点：
1.中文资料严重不足，搜个错误提示都搜不到，必须各种翻墙
2.手册可读性差，或者说严重不符合国人的习惯
3.搭建过程繁琐
4.composer 不给力
5.packagist 上的 vendor 容易涉及版权问题（一旦涉及就被下架，然后再也找不到了，例如 Excel ）
6.自己扩展着实不意
7.代码可读性非常的差，层级过多（是太 TM 的多了）
8.无法方面的支持 soa
9.模板引擎太过于强大，未定义参数全报错
10.自定义配置较差

优点：
1.ORM 模型，连 TP 都来仿了
2.模板引擎很强大，用惯了 Smarty ，再用 blade ，感觉有点诡异

总结：
1.都说 laravel 强大性能高，真心没觉得，没基础的小白看手册都看不懂，有经验的又觉得其灵活性较差、排查 BUG 困难。
2.以我目前看来： laravel 适合做单个项目（例如：一个 cms 系统、图片系统、中小 ERP ），并不太适合移动互联网的高并发应用。（可能是我错了）

上一条点错按键，就发出去了。
本来是搜点资料无意中进来了，看到有人问题就回答下，索性顺便回复一下吧。

Laravel 国内相对不是特别热，的确和国人英语水平有很大关系（我英语也很差，自学的），增加了学习和使用成本，不过感觉中文资料已经够用了，尤其是官方文档，基本想了解的东西都能在上面找得到。我觉得既然做了这一行，那英语早晚都得是必须攻克的东西，否则变量取个名都要想半天，会很闹心。

搭建过程和其它现代框架一样 composer ， composer 本身的网络不稳定相信网上有好多镜像可用，我是不用镜像，如果不能顺畅 update ，通常是退出命令重新来（类似刷新网页），多试几次通常就可以。

可扩展性、代码可读性我还没涉及到，还有 soa ，听起来挺高大上的。 源码目前除了 loc 之外，其它也没太看。

模版引擎和 Smarty 显然没什么可比性，相差了近乎 10 年的东西，两个时代了，刚接触 php 的时候记得 ecshop 还是什么用的。 blade 引擎和 twig 风格类似，我觉得比 Smarty 简单好多，方便不懂 php 的直接往里套变量。你喜欢的话也可以直接写原生的 <?php ?> 。

你要是说 laravel 灵活差，那还没看到 yii 呢，哈哈，当改一个 script 地址都要去控制器里改调用的方法，那才是醉了。 laravel 的错误提示也还好，目前我还没碰到需要去搜提示才能解决的问题，通常就是直接照着他提示的行数去找相应 bug ，或者下个断点就出来了。

我之前用的是 Yii ，后来觉得有些过度封装了。接触 Laravel 有 2 个月。 Laravel 的性能是我所知道的最差的框架之一（我自己也 ab 了几次）。 好在现在的我已经不把性能作为选择框架的首要考虑，写着爽，语法糖多，开发速度快就行，用句《 yii for beginner 》作者的话说， Laravel 可以让你变成更好的 PHP 程序员。在使用过程中，深深感觉到作者为了用户所做的那些各种贴心的设计，之前其它框架所不支持的 Orm 的多态关联，多个中间表的多态关联，竟然一个方法就搞定。还有就是作者的注释非常的有趣而且言简意赅。速度的事，以后再说喽，实在不行就改写路由，加内存缓存， config 入驻内存等等乱七八糟的常规优化呗。速度问题是个小问题。

PHP 是一门用户数量很多语言，大家的水平悟性以及努力程度也不尽相同，如果一个框架能让自己水平提高稍微一点点，还是值得用的，这就是我选择 Laravel 的原因。倒也不是什么粉丝。还没脑残到成为一个语言或框架的粉丝，只是既然写 php ，就用一个自己觉得爽的吧。还有就是 laravel 的生态圈太强大了。基本 laracast 视频走一圈就知道大概咋回事。语言比较没逻辑 抱歉啦各位。

同不喜欢。设计过了头。

@AbrahamGreyson 首先感谢打了那么多字来讲述流程，但不知道你亲自试过没有，这种方式对于把默认方式改为 md5(password+salt)方式是无效的:(
你的方法只是改变了 hash 方式而已，而 hash 方式只是整个登录验证流程中的一部分，整个登陆流程在 Illuminate\Auth\EloquentUserProvider 的 validateCredentials()方法中实现的，是被它控制的，其中调用 check()方法只有两个参数，它所 use 的 HasherContract 是 Illuminate\Contracts\Hashing ，这些都是在 vendor 中不能改的。
你的实现方式也是有问题的，因为 contract 是一组接口，原则上是不能改的。它的作用是由其它类来实现它，这个接口是由各种类来实现的，用户只要更换一下实现的类就行了，这样就降低了耦合非常方便。这边要达到修改 hash 方式的目的并不需要改 contract ，只需要更换一下实现 contract 的类就行了，步骤类似你的第 2 第 3 步。
概括一下就是你的方法虽然连 contract 类都改了，但还是无法影响到整个验证流程即 EloquentUserProvider 中的 validateCredentials()方法， hash 方法确实是可以改的，可以自己弄一个然后在 make()里面把 bcrypt 改成 md5 或其它，但这边还需要获取数据库中的 salt ，这个 salt 是无法在自己的 hash 方法中获得的，甚至你连在自己的 make()方法中查数据库获得 salt 都无法做到，因为查询的依据 email 你没有办法获得，它在流程 validateCredentials()中并没有把$credentials 数组传给 make()方法。
也许这个加密验证最终是能改的，但也肯定非常复杂，不是简单几部能搞定，应该要重写很多东西。有什么说得不对的地方请指正，欢迎交流。

楼主的逻辑很有意思，人家啥都要给你伺候好了，代码、文档、示例、全部本地化了才去学习。
知道为什么有的人一辈子穷么？你给他渔具他不是去学着打渔，而是嫌渔具不好用，继续用老办法挨日子。
因为觉得使用起来繁琐就觉得不如 xxx ，且不问为什么别人非要用繁琐的步骤做框架，理解一下其中的缘由再喷好么？

@nickfan 你这种人，职场上估计很难沟通，动不动就给人戴帽子

怎么会可读性差呢？我觉得代码里面的注释写得超级棒啊！！！文档也很详细，在线文档用的是 Algolia 搜索，速度快到哭。有了 composer 的帮助，搭建也不繁琐， composer 简直太好用了。

@pein 我没有要改接口， 我说的 1 中不是改这个接口，是重新实现。
你的 salt 如果也存在数据库中， 应该还需要覆写一两个 auth 类的方法，具体我没看源码，不过估计也不是特别麻烦。

英语真真真是门槛，所以我给自己增加了一门程序员英语，程序员嘛，官方文档都看不懂，那真真要狗带了。

laravel new ... 和 artisan 结合， PHP 界没见过更快的开发方式了

@atan 我太 low 了，真心不习惯这种自动化的，个人做事喜欢求个明白