这是一个创建于 3325 天前的主题，其中的信息可能已经有所发展或是发生改变。
缺点：
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 ），并不太适合移动互联网的高并发应用。（可能是我错了）
 |
1
xuxu 2015-10-16 09:56:23 +08:00  1
你所说的除了第 5 条，其它没看到是缺点。
|
 |
2
freefcw 2015-10-16 10:00:02 +08:00
都是轮子，看怎么组装。不能指望 laravel 给你造好
说实话，怎么弄能比 laravel 更好，我看基本没这个指望 laravel 的基准样例，就是以单个系统为基准设计的，但是哪个不是这么展示的呢。很多功能都是可以剥离的，要性能可以用 lumen |
 |
3
holystrike 2015-10-16 10:04:26 +08:00 1
如果 laravel 流行起来了
国内也就没那么多人吐槽 PHP 了 |
 |
4
Raidal 2015-10-16 10:10:19 +08:00 1
前面几点倒不是问题。 packagist 版权问题和层级过多导致可读性不好，相对于其他框架的确有些麻烦。总的来说， laravel 依然是一个值得学习和使用的好框架。
|
 |
5
WildCat 2015-10-16 10:10:50 +08:00 via iPhone
最大的缺点是不方便部署在虚拟主机，如果部署在 VPS 完全可以用其他语言了。
至于 ORM ，抄的 Rails 。 |
 |
6
jaguar 2015-10-16 10:13:54 +08:00 via Android
laravel 适合做小项目。。。小项目还需要框架吗？
|
 |
7
timsims 2015-10-16 10:15:44 +08:00 7
我第一次看到这么呵呵
在国外大牛都在争论 datamaper 和 active record 优劣的时候， LZ 还在入门和搭建这么肤浅的层面上去抱怨 |
 |
8
Moker 2015-10-16 10:17:43 +08:00
新手小白，除了资料少了点之外，有些时候莫名其妙不知道问题错误在哪
其他用很爽 特别是 blade |
 |
9
kslr 2015-10-16 10:21:47 +08:00 4
楼主不是我给你戴帽子，第一条你就完蛋了。
|
 |
10
ysz1121 2015-10-16 10:31:15 +08:00
我辣么喜欢 symfony 为毛 symfony 在国内也火不起来， symfony 的优点数不胜数啊
|
 |
11
JackyHua 2015-10-16 10:41:04 +08:00
中文资料少是事实
|
 |
12
void1900 2015-10-16 10:47:11 +08:00 4
1.中文资料严重不足，搜个错误提示都搜不到，必须各种翻墙
golaravel.com 2.手册可读性差，或者说严重不符合国人的习惯 golaravel.com 3.搭建过程繁琐 是比 ci thinkphp 那些麻烦 4.composer 不给力 有国内镜像，或者日本镜像。 http://pkg.phpcomposer.com 不过有时候好像不太稳定 5.packagist 上的 vendor 容易涉及版权问题（一旦涉及就被下架，然后再也找不到了，例如 Excel ） 暂时没遇到 6.自己扩展着实不意 larval 扩展性非常高，耦合低，所谓的扩展应该是没搞清楚结构或者是说需要较多的文件才能实现扩展。 7.代码可读性非常的差，层级过多（是太 TM 的多了） 8.无法方面的支持 soa 9.模板引擎太过于强大，未定义参数全报错 10.自定义配置较差 |
|
13
void1900 2015-10-16 10:49:05 +08:00
7.代码可读性非常的差，层级过多（是太 TM 的多了）
项目是挺大的，可读性我觉得比 thinkphp 这些好多了。 8.无法方面的支持 soa 没用过 9.模板引擎太过于强大，未定义参数全报错 未定义参数报错，你是要输出一个空？明明要输出，你却未定义，检讨下吧兄弟 10.自定义配置较差 自定义配置？我不懂了， laravel 可以根据环境来配置，配置项很强 |
 |
14
flymemory 2015-10-16 10:56:15 +08:00 1
哈哈，这个帖子成功吸引了不少 laravel 的忠实粉丝。
第一条确实不属于缺点，首先中文资料不是必须的，其次自备梯子已经是开发人员必备技能了，如果因为没有梯子而吐槽一个框架不好，我觉得有点不合适，毕竟不是 Laravel 本身导致的。 |
|
15
timsims 2015-10-16 10:57:40 +08:00
补充 @void1900
3.搭建过程繁琐 homestead 新项目 laravel new your-project-name 域名访问 serve your-domain your-project-path 真是简单得我想哭..... 8.无法方面的支持 soa soa == Service Oriented Architecture ? 没用过，但 google 一下就有很多相关文章和社区讨论 |
 |
16
jarlyyn 2015-10-16 11:03:20 +08:00
虚拟空间不支持。
不是为了虚拟空间为啥用 php? |
 |
17
maddot 2015-10-16 11:07:19 +08:00
主要是英文不好，快去用 wordnote.net 来提高英语吧
|
 |
20
guotie 2015-10-16 11:19:52 +08:00
错，因为 nodejs
|
|
21
maddot 2015-10-16 11:24:35 +08:00
@jarlyyn 应该很多都支持 5.4 吧，毕竟这是个卖点，又很容易做到，看看以前用过的 hawkhost,Support for PHP 5.2, 5.3, 5.4, 5.5, 5.6 and 7.0. 毕竟这是个竞争激烈的行业
|
|
22
jarlyyn 2015-10-16 11:35:38 +08:00
|
|
23
timsims 2015-10-16 11:54:19 +08:00
公司项目用虚拟空间！？
|
 |
24
yxzblue 2015-10-16 11:58:52 +08:00
“看手册都看不懂”戳中我心啊，这句话。
我也看不懂。。。 |
 |
25
printempw 2015-10-16 12:04:48 +08:00 via Android
一楼说的好。
|
 |
26
pein 2015-10-16 13:12:31 +08:00
Laravel 用起来确实比较闹心，比如我想把它默认的 bcrypt 加密验证方式改成 md5+salt ，在不改 vendor 的情况下很麻烦。。。
|
 |
29
solaro OP @timsims 高手，你好
@holystrike php 业务层面上的话注定是没办法写出好代码的，语言就是如此， php 本来就是追求快速入门，快速开发，快速上线，再说了， php 在国内的使用人数、薪酬都很 low （相比其他例如 oc ），我曾面过一家公司，他们招 PHP ，然后跟我说进去之后先做 PHP 再转 JAVA ，我问为什么不直接招个 java ，他说需要有人来做 php ，我说那为什么后面要去做 java ，他说因为 php 工作内容不多，而且 php 人多便宜，容易招， java 人少又贵，我说那可以把 php 项目外包出去或者让 java 去学 php ，他还是强调， java 比 php 贵。。。外包也不舍得那几万块。。。说这些，你明白吗？你可以觉得 php 便宜就得写垃圾代码吗？我想表达的是：这种氛围下，这种环境下。。。能写出什么好的 php 代码。。 |
 |
33
est 2015-10-16 14:21:58 +08:00 3
其实就一个原因：培训班没教。。。。
|
 |
34
raincious 2015-10-16 14:26:54 +08:00
|
|
35
freefcw 2015-10-16 14:30:38 +08:00 1
@est 哈哈，相对之前的框架来说， laravel 是复杂很多，设计理念和思维不是之前操三板斧两下就可以搞定的，认真研究 laravel 的思维才能理解他的优点。
|
 |
36
cxbig 2015-10-16 14:32:47 +08:00
@solaro 这年头还在比较 Java 和 PHP 的薪水太 low 了，出来混几年都要会好几门手艺，看综合素质。
我周围 PHP ＋前端技术的，年薪 100k EUR 的多的是，大部分 Java 也就这收入。 |
|
37
pein 2015-10-16 14:41:07 +08:00
@raincious 为什么要改上层的东西？可能是因为历史遗留问题，也可能是因为仅仅不想用 bcrypt ，毕竟速度巨慢很吃计算资源，人少看不出来，访问并发一多的话就得加服务器了。
其实我每次提这个问题都有很多人会站出来（包括国外社区），然后说 bcrypt 如何如何安全，其它的如何如何过时，可是我只是单纯的想问，我就想换，能换吗？ 如果一个框架连换个默认加密方式都极其费劲的话，那何来灵活，何来优雅？ |
|
38
pein 2015-10-16 14:45:39 +08:00
@timsims 即使自己写 HasherService ，更换加密函数是可以的，但 salt 是无法获取的，除非你把它整个验证流程都重写。
|
 |
39
hantsy 2015-10-16 14:48:41 +08:00
@ysz1121 Symfony 改变了整个 PHP 生态圈， PSR 中 middleware 等规范最初原型都是 Symfony 的抽象。现在很多开源 PHP 项目是基于 Symfony 或者其 Kernel 的等。 Zend 3 也不得不回来拥抱全系列的 PSR 了。
|
|
41
pein 2015-10-16 15:05:38 +08:00 2
Laravel 社区现在新出来了不少，但其实就那么点人，活跃的一直都是那几个老面孔。我认为 LZ 说的大部分还是比较中肯的，代码可读性差是因为用了很多设计模式，最后弄得一些编辑器都追踪不到代码了。中文资料不足其实严格来说不能算是缺点，主要是它的英文文档写得也不咋的，基础的都写了，进一步深层次的内容就只是含糊提一下敷衍了事。
|
|
43
raincious 2015-10-16 15:17:08 +08:00
@pein
不了解 Laravel ，但是它内部没有提供一些更弱的 Hash 方式么？ 或者你想修改哪里的 Hash 方法？如果是想要替换 Hash 密码用的 Bcrypt 那么确实是不应该的。况且用户验证过程不应该是一个被频繁访问的服务。 但是如果只是用在普通的 Hash （比如文件 Hash 比较用来减少储存占用）这样，那么自己写个 Hash 处理过程也不难（写个类封装下 hash 函数而已）。 至于 Salt 设置之类，你可以独立设定一个 Salt 的配置，然后用 Laravel 自己的 Config 去读就行了，最多也就是复制下设置的值。 其实说到底就是：你不一定需要完全使用框架自己的功能的。 |
|
44
cxbig 2015-10-16 15:48:40 +08:00
@neutrino 我的意思，单一的语言去谈工资没有意义，都是多技能融合才有高收入。单一个 PHP 或 Java 能有高工资的人太少。
|
|
45
xuxu 2015-10-16 16:02:59 +08:00
https://github.com/illuminate/contracts/blob/master/Hashing/Hasher.php
salt 不可以放在 option 里？ @pein @solaro |
 |
47
lucky215 2015-10-16 16:35:15 +08:00
多年不看 PHP 框架的我见到 laravel 很兴奋
|
|
49
solaro OP |
|
51
cxbig 2015-10-16 17:51:02 +08:00
@solaro 工资这个事急不得，我只想说不要单纯去比较一种技术，做精了都不差钱。我说的 100kEUR 就是纯码农的价格， 15 年左右经验的那些。
|
 |
53
des 2015-10-16 18:54:11 +08:00 via Android
文档确实不够好，封装的层级有点多，不过注释是非常赞的
|
|
54
cxbig 2015-10-16 19:04:15 +08:00 1
@hbkdsm 打杂
工作中主要是 PHP ， JS ， jQuery ， React 。 Ruby 也用一点，主要是部署 Capistrano 之类的脚本。 这里整个环境给我的感觉就是用什么技术的都有，很散，要说哪个特别多的，那一定是 JavaScript 。 现在 Java 、 PHP 、 Ruby( on Rails)、 Python 、 Go 这些已经快沦为 JSON API 了。 经常去的一些小型交流会议，几乎每个人都在做自己的一个小领域。 光是 React 下的分支就一堆稀奇古怪没听过的组件，倒是蛮有意思的。 |
 |
56
jellybool 2015-10-16 19:49:52 +08:00 2
1. 嗯，这个确实在国内是个问题，不过在推动中
2. 我个人倒是觉得非常适合我，可能我是特例 3. 并不觉得，直接使用 PHP 内置服务器也可以跑，就是个下载过程而已 4. 额，写代码难道没有 VPN 么 5. 这个确实，不过相信情况应该不会很多 6. 看扩展哪方面的内容咯，要是非得改加密，那是在。。。 7. 我觉得用 PHPStorm 看源码还是可以的 8. 额。。 9.模板引擎强大也是错？ 10. 比如说哪种差？ 优点： 1. 我也觉得 2. 还行 总结： 1.哎，我也不敢说 laravel 性能强大，只是觉得在这个时代下，它的思想还有快速开发能力是在棒呆。 2.恩，也是，所以也只是做了一个小东西。 以上 |
|
57
cxbig 2015-10-16 20:29:33 +08:00
@hbkdsm
BackboneJS 已经没落了，这边用的人很少 AngularJS 依然有很大的用户基础。但是我们放弃了，根据我们的项目， React ＋ Flux 的性能更好，开发周期更短。 后端我们做电子商务以 Magento 为主，周边站点用 WordPress 和 Laravel 。 |
 |
58
msg7086 2015-10-16 20:40:40 +08:00
@solaro 说到 100K ，美国很多 IT 企业给本科毕业生的起薪就要 100K+ USD 了，而且不关心你到底会啥语言。
|
|
59
pein 2015-10-16 20:54:59 +08:00
@xuxu 这个早就看过了，你可以去看一下 EloquentUserProvider.php 中调用 check()方法的地方，那边根本就没有给出第三个参数。
|
 |
60
Wangxf 2015-10-16 20:59:47 +08:00
还是搞 thinkphp 吧，哈哈，前端来说， tp 足以
|
 |
61
mahone3297 2015-10-16 21:30:37 +08:00
@cxbig 100k 欧元， 70w 人民币？好多啊。。。膜拜。。。
|
|
62
cxbig 2015-10-16 21:35:47 +08:00
@mahone3297 别忘记税收部分，能拿到这个水准的收入，税和社保大概要占 45%。
|
 |
63
hylent 2015-10-16 22:02:06 +08:00 1
初次看 Laravel 的 ORM ，感觉很惊艳，设计到我心里了。可惜后来发现原来是借鉴来的。。
|
 |
64
konakona 2015-10-16 23:36:43 +08:00 1
除了 5 ，不觉得有什么问题。
laravel 把 PHP 的语法水平都体现出来了，这一点可以带动新一代的 PHPer ，可以说功不可没，让更多的 PHPer 自主的去学习，何乐而不为？ 至于 smart..=,= 这种落伍的就别提了，我早就放弃它很久了...blade 还好，连 PHPStorm 都开始主动支持了（而非插件而已），可见其对 MVC 、 Layout 这块的解决机制有效。 我个人是 OK 的，唯一坑的也就是 Composer 的很多 Package 水平和二次开发的问题了。 |
 |
65
ibcker 2015-10-17 00:35:49 +08:00
被 rails 虐过后觉得还好~就是没 rails 调试爽~
|
 |
66
movtoy 2015-10-17 00:38:07 +08:00
告诉你们，法拉利在中国永远流行不起来。。。
|
 |
67
AbrahamGreyson 2015-10-17 06:50:33 +08:00 1
@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 ），并不太适合移动互联网的高并发应用。（可能是我错了） |
|
68
AbrahamGreyson 2015-10-17 07:27:35 +08:00 3
上一条点错按键，就发出去了。
本来是搜点资料无意中进来了，看到有人问题就回答下，索性顺便回复一下吧。 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 视频走一圈就知道大概咋回事。语言比较没逻辑 抱歉啦各位。 |
 |
69
fising 2015-10-17 09:04:44 +08:00
同不喜欢。设计过了头。
|
|
70
pein 2015-10-19 11:38:32 +08:00
@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()方法。 也许这个加密验证最终是能改的，但也肯定非常复杂，不是简单几部能搞定，应该要重写很多东西。有什么说得不对的地方请指正，欢迎交流。 |
 |
71
nickfan 2015-10-19 14:46:33 +08:00
楼主的逻辑很有意思，人家啥都要给你伺候好了，代码、文档、示例、全部本地化了才去学习。
知道为什么有的人一辈子穷么？你给他渔具他不是去学着打渔，而是嫌渔具不好用，继续用老办法挨日子。 因为觉得使用起来繁琐就觉得不如 xxx ，且不问为什么别人非要用繁琐的步骤做框架，理解一下其中的缘由再喷好么？ |
 |
73
lyz1990 2015-10-19 18:00:24 +08:00
怎么会可读性差呢？我觉得代码里面的注释写得超级棒啊！！！文档也很详细，在线文档用的是 Algolia 搜索，速度快到哭。有了 composer 的帮助，搭建也不繁琐， composer 简直太好用了。
|
|
74
AbrahamGreyson 2015-10-20 11:36:05 +08:00
@pein 我没有要改接口， 我说的 1 中不是改这个接口，是重新实现。
你的 salt 如果也存在数据库中， 应该还需要覆写一两个 auth 类的方法，具体我没看源码，不过估计也不是特别麻烦。 |
 |
75
prometheus 2015-10-21 18:29:03 +08:00
英语真真真是门槛，所以我给自己增加了一门程序员英语，程序员嘛，官方文档都看不懂，那真真要狗带了。
|
 |
76
atan 2015-10-22 18:15:56 +08:00
laravel new ... 和 artisan 结合， PHP 界没见过更快的开发方式了
|
Select Language