@ss098 Laravel Octane 很早跑过 demo ，那时候还只支持 RoadRunner
Laravel Octane 针对 Laravel 做得更加多应该是 service 的自动处理，例如 service 的自动 reset 、依赖的清除等等，各个框架如果要兼容非 fpm 运行模式，应该都是做类似的处理。
因为实际没怎么用过 Laravel ，而且对 swoole 有偏见，所以没怎么考虑。

一般这种需求，淘个 thinkpad x1 就好

@usapla 自己造数据，造一个 20-30 个字段的千万大表，这个表跟三个表有关联，然后写 curd ，多少会有点收获

@Wenco 八股文都不会，写什么文章，靠 csdn copy ？
规范就是项目实践的总结，搞不懂 psr 为什么出现，怎么实践，那就是不及格。

你没必要拿某个点跟我杠，只要是有收过简历的人，都能得出跟我或者楼主类似的结论，你最好自己收下简历，各个薪酬层（ 5-7 ，9-12 ，15-20 ）的都收下，面下，自然会有这种结论。
PHPer 目前人才像断层了一样，新手普遍垃圾，上升期的开发者没机会，已出头的开始转其他语言。

我挺楼主，目前 phper 平均素质十分差，这点只要有过 php 相关招聘工作的人都能感受到。

就算不拿全才全栈来要求 phper ，对于一个开发者、一个 phper ，输出控制能否了解下、fpm/cli 模式能否了解、单次请求从 nginx 到 fpm 到 php 的执行和响应流程、psr 若干个规范的理解，做不到都应按照实习、应届生处理。

再退一步讲，作为一个 curd boy ，怎么做好 curd 工作也是个可以研究的问题。超大表的 curd 实现、ActiveRecord 与 Repository 的区别、curd 的缓存怎么管理。哎。

但就目前来看，能满足要求的 phper 真的不多，php 从业者质量下降十分严重，新人十分烂，上升期的 phper 也被其他开发者挤压，哎。

如果能跟 swoole 解耦的话，可能用的人会多点。。。

考虑开发速度的话，yii2 / laravel
两者的启动成本都比较可控。

gregwar/captcha

我使用腾讯云的 redis 时，遇过这个问题，会导致部分 redis 读写请求失败，整体很诡异。

比较接近你要求的，应该是 ThinkPad X1E 。
如果要省事和性价比，就直接 mbp 吧。

楼主不像是走几个大厂的人，真有那么多厂的经历，不太应该有“有能力的人挣扎挣扎走了，剩下能力平庸的用一套固定的东西实现傻逼的需求”这种感觉。一般来说，大厂就需要平均甚至平庸的生产人员来确保输出是稳定的，小厂才需要高比例的攻坚型人才。

LowCode 其实很符合大厂需求，也能有效降低小公司的开发成本（至少，理论上可以），收到青睐很正常。

我错了。已经有了 https://github.com/walkor/psr7 那你再搞一套就没意义了。

我也搞过这个事情，后来意识到其实是做了歪路。有个更加好的路可以选：在 workerman 实现一个标准的 psr request / response 的输入输出层。这就足够了，剩余的事情让框架自己去适配和改造。

大包大揽想解决 fpm/workerman 的兼容问题是不可能的，最终都是要倒逼框架、应用开发者去改造。随便举几个例子：
1. 全局变量的管理（如微擎很傻缺的 $_W，CI 古老的$_CFG ）
2. 静态变量的管理（如类中的静态变量计数器，我记得 Yii 和 Laravel 都有类似的地方这样做）
3. 改常驻后，include_once/require_once 的逻辑变化（配置文件等的加载都可能有问题）

我看你项目都已经用了 workerman4，搞这个不如看看怎么哄下 workerman 作者放弃迷之执念的兼容要求，直接内置个 psr request / response 更加好。。。

差不多十年前，我有个朋友就是做这种项目的，wap 浏览器，wml to html 部分还是我写的。。。
挺好玩的，深入搞这个项目对于 HTTP 的细节了解程度应该会提升很大。

简单说，就是优秀，但是不足够优秀。

看终端的样式，应该是本地压远程。。。这样得来的压测结果都是错的。

没那么难，跟框架也无关。没意识到要写、不愿意写是素质问题。

https://s1.ax1x.com/2020/08/08/a5nR0O.png

纯 http 解决的话，可以试试 sse