php项目复盘提到的技战术短板在哪？

本文目录导读：

1. 领域模型缺失（贫血模型 vs 充血模型）
2. 隐形状态管理与并发控制
3. 依赖管理混乱（Composer 滥用）
4. 性能瓶颈的“粗暴解法”
5. 胶水代码与过度设计
6. 测试的缺失（尤其是单元测试）
7. 安全编码习惯缺失
8. 环境一致性（Docker 缺失）
9. 复盘总结：如何“对症下药”？

在PHP项目的复盘（Retrospective）中，技术债务和战术短板往往不是“PHP语言本身不行”，而是工程化实践和架构演进的缺失。

结合大量一线开发团队的复盘经验,以下是PHP项目中普遍存在的技战术短板，按严重程度和出现频率排序：

领域模型缺失（贫血模型 vs 充血模型）

这是PHP项目最典型的短板。

• 痛点： 代码中充满了 Controller 直接写 SQL 或直接操作 Array，业务逻辑散落在各个控制器中，形成了“事务脚本”模式。
• 战术短板： 一旦业务规则复杂化，代码会出现大量重复，且无法进行单元测试，缺乏实体（Entity）和值对象（Value Object），导致业务规则的变更成本极高。
• 复盘建议： 检查是否引入了 DDD（领域驱动设计）的轻量级落地，是否使用了 Repository 模式隔离数据源，是否将复杂业务逻辑下沉到 Service 或 Domain 层。

隐形状态管理与并发控制

PHP 传统的无状态特性（每个请求结束即销毁资源）导致在处理长事务或跨请求状态时容易出问题。

• 痛点： 依赖 $_SESSION 存储复杂对象，或使用数据库行锁/表锁解决并发，导致死锁频发。
• 战术短板： 缺乏对幂等性的设计，在支付、扣库存等关键接口中，未考虑请求重试或并发穿透导致的超卖/重复扣款问题。
• 复盘建议： 检查是否引入了Redis分布式锁、消息队列削峰填谷，以及是否对核心接口做了幂等性校验（唯一订单号）。

依赖管理混乱（Composer 滥用）

虽然现在都用 Composer，但“用法”存在巨大差异。

• 痛点： composer update 成为项目上线的“玄学”，依赖锁定不严，导致开发环境与生产环境代码不一致。
• 战术短板： 未区分 require 和 require-dev，或将业务代码写成 Helper 包引入，导致代码升级地狱。
• 复盘建议： 严格提交 composer.lock，并考虑是否使用了 PHPStorm + Deployer 的自动化流程，避免在服务器上直接执行 composer install 后清理缓存导致的间歇性问题。

性能瓶颈的“粗暴解法”

这是最常见的战术性懒惰。

• 痛点： 所有数据都查 MySQL，大量使用 JOIN 关联多张表，导致数据库 CPU 飙升。
• 战术短板： 缓存的使用过于碎片化，比如只知道用 Redis 存字符串，却不知道利用 Hash 结构存储对象；或者缓存击穿、雪崩时无保护措施（没有空值缓存、没有互斥锁）。
• 复盘建议： 检查是否引入了 OpCache 优化（确保已开启），是否在 Nginx 层做了静态资源缓存，以及是否对数据库慢查询日志做了周期性分析。

胶水代码与过度设计

• 痛点： 为了“面向未来”写了大量的抽象类、工厂模式和事件监听，但在实际业务中根本用不到，导致调用链极长，排查问题需要跨越 5-6 层文件。
• 战术短板： 知道要避免用 global 和 new 关键字，但过度依赖 IoC 容器（依赖注入容器）导致静态分析困难，IDE（集成开发环境）无法自动补全。

测试的缺失（尤其是单元测试）

• 痛点： 写 PHP 容易，写测试难，很多项目依赖“手动在浏览器点一遍”来验证。
• 战术短板： 没有引入 PHPUnit 或 Pest；或者写了测试，但只测试了正常路径，从未测试异常分支和边界值。
• 复盘建议： 至少要对核心 Service 层和计算逻辑做单元测试，对核心接口做 Laravel Dusk 或 Selenium 的冒烟测试。没有测试的 PHP 重构，都是拆东墙补西墙。

安全编码习惯缺失

• 痛点： PHP 上手门槛低，导致很多开发者直接拼接 SQL 字符串，虽然用 PDO（PHP数据对象）预编译了但还是用 String + $_GET 拼接表名。
• 战术短板： 忽略了二次注入（转义后的数据再拼接进 SQL）、文件上传绕过（仅检查 Content-Type 不检查文件头）、以及 SSRF（服务端请求伪造）（允许用户输入 URL 让服务器去请求内网）。

环境一致性（Docker 缺失）

• 痛点： “在我电脑上好好的啊！”——这几乎成了 PHP 项目的经典笑话。
• 战术短板： 开发用 Windows/Linux，生产用 CentOS，PHP 版本不一致，扩展（如 swoole、redis）版本不一致，导致上线后行为异常。

复盘总结：如何“对症下药”？

如果复盘时发现上述短板,建议按剪刀差优先级排序：

1. 先止血（Bug类）： 检查并发安全（锁）、SQL 注入、配置漂移。
2. 再优化（性能类）： 开启 OpCache、优化 Nginx FastCGI 配置、Redis 缓存重构。
3. 后补课（工程化）： 引入 CI/CD（持续集成/持续部署），强制代码规范检查（PHP_CodeSniffer）和静态分析（PHPStan）。
4. 最后防再犯： 写测试！写测试！写测试！ 尤其是针对线上出过的 Bug，写回归测试。

一句话核心理念： PHP 项目的技术债，往往不是“写不出新代码”，而是“改不动旧代码”；短板的根源在于缺乏对代码生命周期的敬畏，而非语言本身，复盘时建议重点看数据一致性方案和代码的可测试性。