第一个建议，把你的备选项删减到 2-3 个

基于当前的项目基本都依赖 HTTP 这个背景，从成本考虑，基本上 php 是最优解的了。
当然从课班出身来看，php 这种东西的确显得很玩具。

修 bug ，修一两个就上手了。

霸王的大陆

@whosphp 哥们，跟学论文一样加个小结啊：基于 xxx 现状，提出 xxx 方案，解决了 xxx 问题。如：
ThinkPHP 组织项目的形式比较落后，整体框架陈旧不容易跟进新特性，同时因框架约束较少导致交付质量无法达到预期，也有安全方面的隐患。
为此提出了使用 Laravel 框架实现的渐进性重构方案，确保现有业务正常运作和交付，新业务使用服务容器/现代 ORM 等技术手段来提质保量，同时准备了 Laravel-Swoole 之类的方案为后续项目扩展提供更加可能性。
通过诸如此类的改进，我们实现了主要 xx%业务迁移到新框架，剩余 xx%可以沿着已定的重构方案渐进地完成重构工作，经压测主要接口知道得到了 xx%的性能提升，交付速度提升了 xxx 。

要看你是什么角色去对待这个业务。
你是安全人员/东厂/网安爱好者，你对业务的要求一定是“更加安全”。
你是业务开发/需求方/老板，你对业务的首要要求一定不是“更加安全”。

网络安全是要靠事故驱动的。既然“使用 HTTPS 用明文传输密码”不是一个明显的安全问题，没出过事，那就没必要投入，你是项目负责人你也会这样选择，没必要的东西为啥要增加成本。

@meshell frankenphp 太新了

有网络协议和纯服务端的要求，比较好的方案是直接用 workerman 自己处理业务。
就单纯处理 tcp/udp 业务，workerman 比其他类似 php 方案舒服太多。
swoole 也行，但是小项目用 swoole 意义不大，协程没优势。

我个人不是很建议 hyperf/easyswoole 之类的框架，因为太乱了。这种乱不是单个代码逻辑的混乱，是整个框架的 roadmap 就不清晰，甚至部分代码版权也有瑕疵。
上这种野生框架，不如用 symfony + swoole runtime 。

1. 不直接操作数据源，不接触界面，就放到 service ；对象；
2. 不是一般 service 要关心的，这个时候应该有独立的 service 去做数据的管理，一般就是 EntityManager 之类的名字；
3. 会，应该重复验证不必要避免；

最近几年，二三线城市政企的信息化预算缩水了不止十倍，你这个想法很危险啊同志。
我个人很不看好，如果要做的话就把预算缩到最低，市场/开发/售后都自己搞，身体力行摸清楚再考虑。

@seth19960929 我看了下，还是不支持啊 https://github.com/laravel/octane/issues/765

octane swoole ，目前能上协程了吗？

最好说明下 /api/welcome 的逻辑。这个结果不符合开发者对 roadrunner 的预期。
另外跟纯用 golang 写网络业务的接口对比也不合适。laravel+roadrunner 对比的应该是 gin+gorm 这类方案。

高中书本已经告诉你题目提问的答案：按劳分配为主的社会分配制度下，多劳多得是正确的，所以你提到的模式肯定是更加先进的。

但是现实操作中，按劳分配的前提都是要求兼顾公平。这里的公平要承认和考虑人民个体之间的差异（体力/智商/原始资本），不追求绝对意义的道德理解上的公平，而是要尽可能“杀富济贫”，实现均劳均得，多劳少得的大同社会，最终生产力才能正循环产生并释放出来。简单说就是不让就业竞争差的人被市场经济秒杀，无形的手会帮忙疏通下留点活路。

所以你是对的，但是社会不喜欢你这种声音，因为你可能在消除相当大部分受这种决策照拂的人民的利益。

如果你没有移动需求，搞个超顶配的黑苹果还是可以的。
如果有移动需求就不用纠结了，果断 M1/M2/M3 吧。