ywisax

基于当前的项目基本都依赖 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. 会，应该重复验证不必要避免；

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