本文目录导读：
在 PHP 项目的复盘中，提到的最大争议往往不是技术选型（比如用 Laravel 还是 ThinkPHP），而是“历史债务”与“现代标准”之间的激烈冲突。
根据我接触过的众多 PHP 项目复盘案例，最大且最频繁出现的争议点主要集中在以下三个维度，其中第一个维度通常是引爆点：
最大的“雷”：存量代码的维护 vs 彻底重构
这是绝大多数 PHP 项目（尤其是老项目）复盘中绕不开的死结。
- 争议焦点：项目跑了 5 年以上，积累了大量的
MySQL_*函数、混乱的全局变量、甚至是没有命名空间的旧代码，部分开发认为应该“推倒重来”，引入 PHP 8.x + Laravel/Symfony，一步到位；另一部分开发则坚持“能跑就别动”，因为业务逻辑庞大且测试覆盖率为零，重构极易导致资金流水或核心业务崩溃。 - 复盘结论：最终往往陷入“焦油坑”——即无法彻底重写，也无法彻底维护，争议的终点通常是妥协：在新模块使用新框架，老模块通过“防腐层”进行适配，但这个过程极其痛苦，且容易引发团队士气问题。
性能瓶颈的归因：是 PHP 慢，还是你的 SQL 烂？
- 争议焦点：复盘时，只要页面打开超过 2 秒，PM（产品经理）就会把锅甩给“PHP 就是慢”，但技术团队内部知道，大部分性能瓶颈源自于N+1 查询问题、缺乏 Redis 缓存或根本没有索引。
- 复盘真相：这里的争议在于“技术背锅”还是“代码背锅”，PHP 作为脚本语言，本身并不慢（尤其是 PHP 8 的 JIT 编译），慢的是开发者写出的低效代码，如果在复盘时用 PHP 框架的 ORM 却没有开启 SQL 日志，你会发现执行了上千条冗余查询，这才是真正的争议核心。
安全漏洞的“原生缺陷” vs “开发惰性”
- 争议焦点：项目上线后被脱库，或存在 XSS（跨站脚本攻击）、CSRF（跨站请求伪造）漏洞，大部分开发者在复盘时会辩解说：“PHP 是弱类型语言，容易导致注入。”
- 复盘真相：其实最核心的争议在于——框架已经提供了防护机制（如 PDO 预处理、Laravel 的中间件），但开发者为了省事，用了字符串拼接 SQL，或者直接
echo $_GET['id']而没有转义。 复盘中最大的情绪冲突在于：是怪 PHP 不安全，还是怪开发者没有遵循安全规范？这在团队中往往引发激烈争吵。
如果要回答“最尖锐的那一个争议”，我认为是：
“当初为了快速上线而牺牲代码质量，现在是否应该花 3 个月时间补上技术债？”
这个问题之所以争议最大,是因为它牵扯到业务方（要迭代新需求）、开发方（不想维护屎山）和管理层（怕停服出事故）三方的利益博弈，无论复盘会开多久，只要这个决定没有达成一致，未来的开发流程依然会充满摩擦。
如果你们也正在做 PHP 复盘，建议将“重构”与“新功能”完全隔离，并强制引入 CI/CD（持续集成/持续部署）和自动化测试——这是唯一能平息这场争议的硬通货。 你们项目里遇到的是哪种情况呢？
