@gouchaoer 我觉得 Laravel 的理念并不差，在 URL mapping 上很主流，如果 php 也有 annotation 的话 API 可以设计的更美。 functional 式的 controller ，可以去掉一个无意义的方法命名，即将发布的 Java 框架事实标准 Spring 5.0 ，也引入了这个方式。

性能绝大部分情况下都不是首要考虑的问题， Laravel 支撑个 300 万的日 pv 毫无压力。

hello world 式的微评测没有意义，那并不能体现真正的业务复杂度。假设每个 HTTP 请求， A 框架开销是 1ms ， B 框架是 10ms ， rps 是 1000 vs 100 ， 10 倍的差距看起来很大。但是一旦融入业务逻辑，比如耗时 10ms 的 db 和 cache 访问，那么就变成 11ms 和 20ms ， rps 变成 90 vs 50 。把宝马 i8 和奇瑞 QQ 放到高峰期的堵路上，速度不会有太大的差别的。

拿针筒射几滴盐水进去

@gouchaoer 其实绝大部分项目日 pv 连 1000 万都不到， php5 性能也够使了。 7 以后特性越来越多，语言越来越复杂，也许不太适合 PHP 的定位了。

Java6 升 8 ， spring3 升 4 ，只花了半个小时样子，测试环境运行良好，准备下周往集群里扔一台试试

curl 足够好了，虽然有时啰嗦了点

url 转义， html 转义， xml 转义， sql 转义，正则转义，需要转义的地方很多，如果入库前就过滤，跟为了不得性病把自己阉了有什么区别？

@gouchaoer yaf 是 C 写的，框架本身是常驻内存的， swoole 框架只有底层核心部分是 C 写的，上层还有 php ，所以两者性能上面差距不大。而 yii 是纯 php 框架里最快的之一，它却比那两个慢好几倍，这正是常驻内存的价值体现。

除了框架自身开销，我们还会有一堆业务上的初始化逻辑，这是 fpm 的梦靥，除非你业务逻辑初始化也用 C 做成扩展。

cli 也不一定是单进程，比如 swoole 可以开多进程，充分利用多核性能。 qps 过万的时候，甚至连同机房 redis 的访问都嫌慢。

至于 cli 常驻靠不靠谱，我觉得可能不如 python/Java 这样经过十年以上检验的可靠，但是 php 不也一直在改善么?

@mywaiting 用 sqlalchemy 可以不用它的 orm ，只用 core 部分也不错，而且它也支持 raw sql ，自己封装的优势是什么呢？我封装过 php 的， python 的， java 的， C++的，除了自己比较熟悉实现细节可以做比较奇葩的定制，并没有额外收益。

@Gauin 没见过工作 3 年的组长被校招新人倒挂? 不过早个三年买房能少花几百万，一年差个几万是小事。

@gouchaoer cli 起的服务，相比 fpm 这种更容易实现 php 层面的持久化，比如说你框架有 200 行 php 的初始化逻辑， fpm 方式下每个 http 请求都要初始化一下， cli 起的只要初始化一次。未来的 PHP 或许会渐渐淘汰 fpm 这种方式，每个请求都简单粗暴重来一次已经越来越跟不上时代了。

Sqlalchemy 或者 peewee 二选一，都封装的很好了

rpc 作为经典的 KPI 项目，而且难度小容易实现，轮子必须非常多

@yjxjn 这个是批发价，就像钟点工很容易时薪 50 ，全职做同样的事情可能 25 都不到

自从有了空调和地暖这好东西，长三角的冬天也不冷了

光猫不是自带千兆路由吗？

就算是每年发一次，房东们涨两次租就把这补贴给抵消了，涨三次...

@yanzixuan IP 池的确是个大问题，我们弄了几百个才勉强够用。除了网络资源外，真正的门槛是 APP 包的破解和验证码的破解，其它都是体力活。

我这有大量长得很像但又并不完全一样的代码，一个方法写 500 行以上很普遍，几个开发者都离职了，我一边加功能的同时还要一边梳理重构。测试人员都没有，老代码单元测试覆盖率为零。这可是每天 pv 过亿，每天净利润六位数的项目。