“个人原因”离职有一个好处，就是在就业市场会少受一点歧视。
6 年前端也算是有经验的开发了，到最后才意识到 AI 吹来的风有多冷，能力看不出来好坏，但是职业敏感性的确差。

你是对的，上面大部分观点是错的。
这里应该是技术人员居多，就技术管理来讲，不敢、不能做管理方向，是单纯的能力不足，其他理由都是多余的。

@Kokororin nx 怎么应用到 php 项目？

就服务端开发领域来看，不是 php 下滑，是整体都在下滑，因为市场已经不需要那么多码农。
直白讲，php 用不好的开发，极大概率也用不了 java ，在市场上依然是没竞争优势的。

php 自身因历史包袱有点积重难返了，不过好在 php 生态基本都是开源的，有人看 php-src / laravel / symfony / thinkphp 不爽，可以自己提 PR 去完善的。

我给你一个认真的建议：先老老实实去嫖一阵（一楼一/水疗/MMK 啥都行），不要返食，一直换人，先让你自己对性这事情祛魅，再考虑相亲。

你这是接触异性太少了，才吃这种暗亏。

https://bpc.dev/ 用不了了

第一个建议，把你的备选项删减到 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 就不清晰，甚至部分代码版权也有瑕疵。
上这种野生框架，不如用 syfony + swoole runtime 。

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