这是一个创建于 2494 天前的主题，其中的信息可能已经有所发展或是发生改变。
想确认一下：
（国内企业）相比于 Laravel，似乎更多选用 yii
e.g. 科大讯飞似乎用的是 Yii
在类似的场景 yii 和 laravel 区别是什么？
看之前帖子有人说是安全和性能（？
安全这个…差在哪里？
性能的报告有人有链接吗？
还是文档？
还有什么其他原因？
注意：
1.不对比其他框架，只是想了解这两者的区别和为什么企业会选用（或者本身命题就是有问题的）
2.没有说两者谁好谁坏，请列具体情况 /数据
3.如果了解有用到 Laravel 的可以回复一下了解一下行情？（比如给赞的 api 是 Laravel ）
（国内企业）相比于 Laravel，似乎更多选用 yii
e.g. 科大讯飞似乎用的是 Yii
在类似的场景 yii 和 laravel 区别是什么？
看之前帖子有人说是安全和性能（？
安全这个…差在哪里？
性能的报告有人有链接吗？
还是文档？
还有什么其他原因？
注意：
1.不对比其他框架，只是想了解这两者的区别和为什么企业会选用（或者本身命题就是有问题的）
2.没有说两者谁好谁坏，请列具体情况 /数据
3.如果了解有用到 Laravel 的可以回复一下了解一下行情？（比如给赞的 api 是 Laravel ）
 |
1
tabris17 2018-02-05 15:10:21 +08:00  1
Yii 出现比较早，作者是个华裔（没记错的话），中文文档做得比较好
|
 |
2
zjsxwc 2018-02-05 15:12:42 +08:00 via Android 1
框架而已，看你们技术负责人的偏好，哪个熟悉用哪个。
|
|
3
zjsxwc 2018-02-05 15:14:13 +08:00 via Android
只要设计合理，我见过把 thinkphp 稍微改下就无痛切换到 symfony 的
|
 |
4
bryanly 2018-02-05 15:15:56 +08:00 2
yii 更早吧，我记得两年前 Laravel 生态还没有现在这么好。然后已经选了 Yii，不会好端端的又切另一个框架折磨自己吧
|
 |
5
AlwaysBehave OP 1
@bryanly 看来时间也是一个要素🌚
|
|
6
bryanly 2018-02-05 15:20:32 +08:00 1
现在 Laravel 生态好多了，很多初创公司都是用的 Laravel。至于安全和性能，应该很多公司还没有到考虑这个的时候吧
|
 |
7
jasonchen168 2018-02-05 15:54:33 +08:00 1
进入公司就用的 yii,所以没的选。。。
|
 |
8
torbrowserbridge 2018-02-05 16:04:21 +08:00 via Android 1
怎么下的结论呢？毫无依据呀。
|
 |
9
owenliang 2018-02-05 16:24:33 +08:00 3
写业务一般就是增删改查，框架功能用的很轻，实际上啥框架都差不多吧？
YIi2 设计模式用的一流，看源码解决问题成为一种习惯。 Laravel 没用过，不评价。 |
 |
10
kran 2018-02-05 16:45:35 +08:00 via iPhone 2
yii 设计上的一致性不能更赞了
|
 |
11
realwangyibo 2018-02-05 16:47:43 +08:00 1
出得早，生态更完善，习惯等。
有一种情况是云空间（生产环境）的 PHP 版本最高 5.6，用不了 Laravel |
 |
12
not4jerk 2018-02-05 17:07:01 +08:00 3
yii 前端 css 和 js 代码放到 php 里面管理非常不习惯
|
 |
13
Seanfuck 2018-02-05 17:23:17 +08:00 1
Yii 增删查改不够方便（相比别的）； Laravel 乱七八糟的东西太多，增加不必要的折腾。谁简单实用就用谁吧，安全问题框架解决不了。
|
 |
14
myrobotech 2018-02-05 17:24:33 +08:00 1
因为我们 CTO 说 Yii 更早，沉淀更多
|
 |
15
lsylsy2 2018-02-05 17:41:42 +08:00
Yii 作者是鸟哥（不是私房菜那个），原来在新浪现在在链家应该？是国内第一个（好像现在不是唯一一个） PHP 核心开发者。
一个可以自称“ I write PHP ”的人 |
|
16
lsylsy2 2018-02-05 17:43:39 +08:00 1
|
 |
17
wingoo 2018-02-05 17:45:11 +08:00
Yii 作者不是鸟哥, 鸟哥搞的是 yaf
|
 |
18
benosn 2018-02-05 18:43:48 +08:00 via Android
两个都用过，其实差不多，但还是用 yii
|
 |
19
Enochyun 2018-02-05 19:08:54 +08:00
公司 yii 没得选
|
 |
20
oswuhan 2018-02-05 19:32:04 +08:00 1
Yii 相对于 Laraval，类似自助餐与方便面的关系，从健康（相对于方便面）、分量、口味、厌倦周期等角度来说，推荐 Yii，从就餐时间角度来说，推荐 Laraval
|
|
21
AlwaysBehave OP @oswuhan 可以具体说一下吗
|
|
22
AlwaysBehave OP @torbrowserbridge 从目前回复结果来看似乎是的（样本少承认）
今天也是遇到用 yii 然后完全没用过 laravel 的企业，所以很好奇原因是什么 |
 |
23
takashiki 2018-02-05 19:45:51 +08:00 1
我个人觉得吧，对于商用项目来说，用 laravel 虽然比用 yii 在开发阶段要更快更轻松，但是维护起来的话，还是用 yii 的项目维护起来舒服。
|
|
24
AlwaysBehave OP @not4jerk 话说 laravel 的 blade 是不是有一样的问题？
目前用 laravel 也遇到类似的问题（ |
|
25
AlwaysBehave OP @takashiki 是因为 ide 无法追踪 facade 之类的吗？
似乎有解决方案？ |
|
26
AlwaysBehave OP @owenliang 可以问一下设计模式具体是指什么？
|
|
27
takashiki 2018-02-05 19:52:45 +08:00 1
@AlwaysBehave #25 并不是 facade 的原因，主要是维护 laravel 项目的时候经常需要在业务之外的地方花费精力。
|
|
28
AlwaysBehave OP @takashiki 业务之外？例如？
似乎没遇到类似的情况… |
|
29
takashiki 2018-02-05 21:14:43 +08:00 1
@AlwaysBehave #28 主要原因就是 laravel 太重了，比如流量稍微大一点，服务就可能会挂，比如更新版本时如果每个服务都跟着更新 laravel 的版本成本会比较高，比如很多非必要的东西可能会增加系统的不稳定因素 之类
|
|
30
owenliang 2018-02-05 21:31:49 +08:00 via Android 1
@AlwaysBehave 作者面向对象的抽象能力很强 合适的地方合适的模式 。 所谓设计模式，一个是设计，一个是模式，所谓 mvc 模式，activerecord 模式。
|
 |
31
1762628386 2018-02-05 21:39:04 +08:00 1
yii2 框架就是配置文件太多了 而且自带的 BootstrapAsset 很鸡肋的 安装的第一件事情就是从布局中把这个删了 而且 Model 类是纯面向对象形式的 会有很多人不适应
|
 |
32
loginv2 2018-02-05 21:43:08 +08:00 via Android
yii 对于我开始，足够好用了，不想换一个更新的来增加学习成本，有限的精力可以用来学别的
|
 |
34
caola 2018-02-05 23:07:07 +08:00
天天说 Laravel 很重很重，但你有没有用过 Laravel 的精简版 Lumen ？
以速度著称的 Lumen 都不知道要甩其他框架几条街，用做 API 和前后端分离的最佳框架之一。 当哪天你不想用 Lumen，还可以无痛升级到 Laravel |
 |
35
dobelee 2018-02-05 23:10:15 +08:00 via Android
yii2 簡直巧奪天工。
|
|
36
AlwaysBehave OP @loginv2 我也是这么想的，所以也在考虑是否要接触一下 yii
|
|
37
AlwaysBehave OP @takashiki 感觉实际上 laravel 要求的都算是很主流的配置？
5.6 和 7 之间的差距也不小，这种升级应当是需要的考虑的吧 当然业务求稳定可能是首要，但是 Laravel 的 LTS 周期也不短？锁死依赖应该问题不大 |
|
38
AlwaysBehave OP @caola 目前是自己定制了一下 lumen 做前后端分离
感觉 laravel 的 make command 加上以后就很很完美了，lumen 阉割了这个感觉很难受 还有就是很多配置文件没有显式给出开有点困扰 |
 |
39
shuimugan 2018-02-06 00:50:50 +08:00 17
刚接触 PHP 时喜欢框架之争,到处看框架和学习,接触过的框架可以说是非常多了
时至今日,接触过的 Web 框架有 CodeIgniter Yii CakePHP Laravel ThinkPHP FuelPHP Kohana Zend Symfony Swoole Workerman Rails Tornado Django Struts Koa Egg.js ThinkJS 有一些是深度使用的,有一些是技术选型时通读文档,有一些是阅读了部分源码来看下一些设计和实现以及理念的 看到的东西多了,眼界也开阔了一些 Laravel 在我看来有几点无法接受 1. 都说 Laravel 模仿 Rails,但是 Rails 的哲学里"约定优于配置"却没抄过来,起码路由没有. 没有自动路由,每加一个 action 就要去配置文件里写一次,简直恶心死了. 最恶心的是你接手别人项目时候,路由还有几种风格的,分析时在 html 或者 js 里找到个接口,接着想找 php 的具体实现,必须先去看路由的配置文件 2. 全局函数以及 Facade 众多语言 /框架都是先引入,再使用,到 Laravel 这里就不是了 从文档上下文来看,并没有显式引入某个函数 /类,为什么从天而降给了个函数 /类给我用,你到底还偷偷引入了多少东西? 3.文档 文档太简陋了,一堆细节没说,具体实现太绕,经常要看源码 4.view 层 PHP 本身就是个强大的模板语言,非要再往上加个模板引擎,这就算了 不能忍的是 view 文件的路径分隔居然是用"."而不是"/" 当出现了像 view('activities.index')这样的代码,我要去找具体的 view 文件时,就要手工把"."转换成"/",然后在编辑器 /IDE 里跳过去 如果是 view('activities/index')的话,我只需要复制 activities/index 出来,然后使用编辑器 /IDE 的任意文件跳转功能,瞬间就转过去了 如果你非要说装个插件就能解决的话,当我没说过这一条 5.性能 大部分 Laravel 的性能优化文章都是千篇一律,无非就是升 php7,开 opcache,关闭 debug,开路由 /配置缓存,生成 composer 安装的所有依赖的 class map 废话,这些基础谁不会 在没做上述优化之前,我压测 hello world 的结果,qps 只有 5~7 在做完上述这些之后,qps 到了 13~15,哇,性能是原来的 2 倍,开心吗 这个 qps,我按住 F5 都能把网站给刷爆 同样的环境下,也做了上述的优化后,CodeIgniter,Yii,ThinkPHP 这几个框架的 qps 都在 200~400 之间 别说加了 db 操作之后大家都差不多,不少页面能命中缓存的情况下,io 的耗时比 Laravel 的耗时都要低 6.其他 Laravel 自带的队列 去年帮别人改代码时碰到的,消息是经过 PHP 的序列化放进队列的,可改造性差 队列为空就退出进程,官方还教你用 supervisor 去守护,喵喵喵? 神经病一样的存在 Laravel 的诞生并没有解决太多的痛点,或者说他解决的问题在我这里根本就不痛,还带我来了更多的坑,换我在 PHP 框架上选型我也选 Yii Yii 文档丰富,细节到位,安全指南也够用,没那么多花哨的概念,代码规范又符合直觉,层次清晰,性能虽然没有常驻内存的框架好,但也够用,只需要专心处理业务就是 而且 PHP 不适合玩常驻内存,毕竟没有多少对 GC 的讨论,官方也没有什么指南给你去调优,因为本身设计就是请求完就销毁的 玩异步的话,除了 Swoole 框架有异步文件 IO 函数,其它框架都没有,除非自己用多线程模拟,否则一处阻塞处处阻塞,可选型方案太少,还不如换语言 |
 |
40
e9e499d78f 2018-02-06 01:09:51 +08:00
@shuimugan #39 同意，特别是文档和队列。
|
 |
42
choulinlin 2018-02-06 04:49:15 +08:00 via Android
9 年前搞过 yii 还把 zend 项目无痛转成了 yii
现在它自带后台了吗 像 laravel voyager 现在鄙人再也不关注性能 只在乎开发速度 和现场的东西 |
 |
43
zqcolor 2018-02-06 06:01:26 +08:00
yii2-starter-kit 自带后, rest-api， 通一遍之后，开发很快
|
|
44
zqcolor 2018-02-06 06:02:19 +08:00
|
|
45
AlwaysBehave OP @shuimugan 有几点补充的
1.路由不自动绑定这个我觉得没太多好喷的，这一层解耦方便定义很多，有的时候需求要改起来也方便，直接甩 routes 过去前端就可以先开发了。感觉像是一个 overview 4.插件本身也算是辅助的功能，dot 这个习惯了感觉也很方便，至少个人觉得比 /更清晰 5.目前不再使用 dump clasamap 来优化，optimize 这个选项已经 deprecated （然而性能还是很糟就是） Laravel 也有 swoole 常驻的（一些组件），但是没有用过 ---- 不过 ac 之类的概念还是第一次接触，感觉可以去了解一下 |
 |
46
assad 2018-02-06 08:30:19 +08:00 via Android
Yii2，Yaf，CI。大型用 Yii2，中小型 CI，要效率，Yaf。
|
 |
47
mclxly 2018-02-06 08:51:20 +08:00
Laravel 用习惯了觉得挺好的，要效率换 Go 系列
|
|
48
bryanly 2018-02-06 09:23:21 +08:00 1
可能是我见识浅薄，看到楼上这么多说性能的，真的有这么多项目需要到 PHP 的框架层面去优化性能的地步吗，大项目加机器，小项目真能活到优化性能那一天吗
|
|
49
bryanly 2018-02-06 09:25:29 +08:00
选了 PHP 不就是因为开发高效吗，在 PHP 里面选框架不就是为了更高效的开发吗？真纠结性能，换 Java，Go 这些不比 PHP 好？
|
 |
50
zhouxuchen 2018-02-06 09:45:24 +08:00
@bryanly #48 [小项目真能活到优化性能那一天吗] +1
|
|
51
wingoo 2018-02-06 09:46:05 +08:00 1
高效开发, 没觉得 laravel 比 Yii 强啊
都做了这么多年, 谁没积累点类库最佳实践之类的 |
|
52
bryanly 2018-02-06 09:50:36 +08:00
@wingoo #51 我觉得框架选择，主要还是熟悉度，一个非常熟悉踩过很多坑的框架，和一个熟悉但是没怎么用过的框架，谁都知道选哪个吧，前者可以是 Yii 可以是 Laravel，取决于选择框架的人
|
 |
53
slince 2018-02-06 09:53:55 +08:00 1
我现在比较关注设计理念，工作用 CakePHP,自己写东西用 Symfony ；看过 laravel 与 yii，只能说 laravel 的优雅我没有 get 到
|
|
54
tabris17 2018-02-06 10:01:12 +08:00
@shuimugan 非常同意！ PHP 想往 JAVA 上靠，然而自己的先天缺陷是无法弥补的。当作高级的模板语言或者 DSL 来用还差不多
|
|
55
shuimugan 2018-02-06 10:03:50 +08:00 1
@AlwaysBehave #45
基于 Swoole 魔改的框架不单单有 Laravel,也有 Yii,但是真的会把它纳入选型么? 这些魔改的框架,测试覆盖率多少?有无质量保证?能否及时合并原框架? 再看看自身项目中引入了多少个第三方包? PHP 的内置的 IO 相关函数全是阻塞的,在整个异步流程里,一处阻塞处处阻塞 多少第三方包用了内置的 IO 相关函数,你要修改多少代码,这又是一个新的坑 而且在常驻内存的环境下,你无法担保你的业务代码以及引入的第三方包能正常运行,毕竟生命周期也不同了 抛开人力成本,在一个已经跑起来的项目里不敢这么做 新项目这么选型还不如换语言 |
|
56
AlwaysBehave OP @shuimugan 所以主要还是性能问题？
那除了 yii，可以问一下上面列出的框架还有哪些平时处于深度使用的情况？ |
|
57
shuimugan 2018-02-06 10:27:39 +08:00 1
@AlwaysBehave #56
CodeIgniter 刚工作时深度使用,当时那家公司用 2 台服务器撑起了千万级 PV 的业务 ThinkJS 作为个人 Node 项目的 api 接口 Web 框架看多了,会发现它们基本都是大同小异,无论是流程上还是功能上,到后面无非就是找一些符合自己理念 /哲学 /信仰的工具而已 还是多研究些架构更实在 |
 |
58
free9fw 2018-02-06 10:33:41 +08:00
yii 其实也挺慢的，轻量级框架还是优选
|
|
59
choulinlin 2018-02-06 11:21:40 +08:00 via Android
还有人为了提高自己知名度 自己去开发一套 mvc 傻 X
哎 因为这样的事我也做过 遗憾 |
 |
60
lwbjing 2018-02-06 11:29:57 +08:00
学习了，感谢各位大佬。。
|
 |
61
MeteorCat 2018-02-06 13:57:48 +08:00 via Android
@bryanly 不好意思，以前遗留下来上个开发留得 Laravel 坑，我们是做游戏开发的，登录接口用的 Laravel，实在话每次更新版本之后用户登录 Laravel 是必定崩一段时间，因为我们登录接口牵扯很多数据上报和渠道更新，Laravel 性能奇差无比，每次都是因为这样出问题，从此对于 Laravel，我都是完全性不看好的；话说回来，一般 PHP 都是很少有性能问题，但是一旦出现性能问题都是灾难性的
|
 |
63
NeverSmile 2018-02-06 15:09:40 +08:00 2
两个框架都用过 2 年以上。 更倾向于 Yii。说一下自己的感受吧
1. 性能方面， 上面有大佬说过了，我自己也测试过，laravel 要慢一些，但这并不会成为一般项目的瓶颈，一般不用考虑这个。 2. laravel 的队列一直在用，driver 是 rabbitmq， 仅仅从队列里读数据不做任何处理，laravel 的队列 3.8 条 /s ,原生 php 3000+/s （一台普通的 Mac 上做的测试 laravel5.2 php7.0 ） 3. laravel 没有自动路由，一开始也是很蛋疼， 习惯了也还好， 看看 restful，命名起来也快。 4. laravel 的 orm 用起来没有 yii 舒服 不举例了， 自己用起来就能感觉出来。 5. IDE 支持方面，laravel 差一些，虽然有 ide_helper 但还是不够完善，相反 Yii2 能完美被 phpstorm 支持。 6. laravel 的帮助方法有很多很多，config env array 系列等等，开箱机用非常方便。 7. 我看有大佬吐槽 Yii 用 php 的方式管理前端资源，这会让人有些不爽（我比较喜欢，js 之间的依赖都可以完美解决），但是这并不能成为槽点，它只是比别的框架提供了更多的方法而已，你完全可以不用 AssetManager 来管理 js 和 css，自己写页面就行了。 8. laravel 的 blade 模板用起来比较爽。artisan 非常棒 9. yii 的小组件用起来比较爽 写的比较乱.... 总结一下： 用 go |
 |
64
cokyhe 2018-02-06 15:09:51 +08:00
从 yii 1 转到 laravel 的飘过
|
 |
65
studentht 2018-02-06 15:26:26 +08:00
@NeverSmile 我也觉得 AssetManager 是目前比较实用的功能，写起后台系统不要太爽。
|
|
66
MeteorCat 2018-02-06 18:27:59 +08:00 via Android
@bryanly 尽量少引用第三方工具，能用到缓存地方尽可能用 redis，几年架构我不敢说改就改，只能从一步一步入手，主要是引入第三方时候一访问 API 加载那一坨
|
 |
67
YingJie 2018-02-06 18:49:04 +08:00 via Android
感觉 CodeIgniter 挺好用的，为什么没人讨论它？
|
|
68
loginv2 2018-02-06 21:09:12 +08:00
@YingJie 和这两个比 CodeIgniter 太简陋了，除非你对自己的水平有自信，能深度把控每个细节 否则 CodeIgniter 还是差一些，相反如果会用的话 ，性能比这俩都好。
|
|
69
AlwaysBehave OP @slince 话说工作用 cakephp 可以问一下是好在哪里吗
|
 |
70
gouchaoer 2018-02-07 16:10:18 +08:00
php 框架中的 mongo，而 mongo 是数据库的 laravel
|
|
71
slince 2018-02-07 18:14:01 +08:00 1
@AlwaysBehave
如果跟 Symfony 相比的话，CakePHP 自然是比不上的；但 cakephp 有个天生的优势，设计的相比较直白简单，可以快速开发，因为 cake 一直模仿的是 ror，所以你可以找到很多 ror 的影子；比如说约定大于配置，这一点是我最喜欢的； 在 cake 里没有太多高深的概念；应付灵活多变的业务是最合适不过的；但如果你追求完善的设计理念和实现的美感，symfony 是你唯一的选择； |
|
72
slince 2018-02-07 18:19:43 +08:00
补充一点：
cake 一直强调的约定大于配置这；所以不会非要用户写一些东西，比如说楼上们吐槽的显示路由的问题，在 cake 里是不存在，cake 给你自由，如果你不愿意自己定义，会有一套约定的规则来帮你做这个事；初次之外，数据库，缓存，控制器都有约定大于配置的影子； |
Select Language