PHP 的问题不在语言本身，而在我们怎么写它

PHP 的问题不在语言本身，而在我们怎么写它

代码库烂了不是语言的锅，是赶工和惯性。
PHP 的口碑，几乎在每次技术讨论中都会被拎出来。应用慢、乱、不安全、改起来痛苦？总有人耸耸肩说："嗯……毕竟是 PHP 嘛。"
这话很少出于技术判断，更像是一种习惯性甩锅。
事实比这简单，也更扎心：大多数 PHP 系统之所以难维护，是我们自己放任的结果。PHP 不会一上来就逼你做架构设计、划边界、守规矩。它很宽容，很务实，特别擅长让你把一个“能跑就行”的东西赶出来。
但今天能跑的代码库，明天可能就是灾难。
一个 PHP 项目沦为恐怖故事，很少是因为 PHP 做不到更好，而是团队从来没养成那些能让项目越做越大还不崩的习惯——结构、测试、约定、关注点分离。
现代 PHP 完全有能力做到：

• 严格类型（是的，真正的类型）
  
• 整洁架构
  
• 依赖注入
  
• 表达力强的领域模型
  
• 规范的错误处理
  
• 可靠的测试
  
• 高性能（OPcache/JIT、缓存、合理的 I/O）
  
• 成熟的工具链
  

如果你对 PHP 的印象还停留在"到处 include 文件"和"在视图里写 SQL"，那你骂的不是 PHP 这门语言，而是一种早该被淘汰的 PHP 写法。
这篇文章不是在给 PHP 洗地，只是想说清楚一件事：PHP 是一面镜子，照出来的是你的工程文化。照出来不好看，换面镜子也没用。
PHP 很宽容——宽容的语言会放大你的习惯

有些语言生态从一开始就逼你把结构搭好。想做稍微复杂一点的东西，就绕不开包、模块、接口、依赖注入这些概念，哪怕你没主动要求，约束也自动就在那了。
PHP 的玩法不一样：

• 可以从一个文件起步
  
• 可以毫无阻力地混合各层
  
• 可以在任何地方访问全局变量
  
• 可以在控制器里直接查数据库
  
• 可以忽略类型照样上线
  

这种灵活性本身不是坏事，PHP 靠它当了多年 Web 开发的默认选择。但它也埋了一个坑：结构显得可有可无，而可有可无的东西在赶工时一定会被砍掉。
很多“PHP 太烂了”的故事，背后的真实剧情是“赶工期上了线，然后重构的债一直没还”。
PHP 没有造成这个问题，它只是没有阻止。
"都怪 PHP"往往是在逃避责任

系统让人痛苦的时候，甩锅给语言最省事，因为语言最容易看到。真正的原因往往藏得更深：

• 没有统一的编码规范
  
• 没有架构负责人
  
• 没有测试
  
• 没有为重构分配时间
  
• 代码评审时松时紧
  
• "先交付再说"的激励机制
  

这些问题哪个技术栈都有。区别在于 PHP 能让你在几乎没有约束的情况下把项目推得很远，技术债悄悄攒着——然后在某一天集中爆发。
PHP 成了替罪羊，因为承认流程烂了，比甩锅给语言难多了。
现代 PHP 不是你记忆中的 PHP

如果你对 PHP 的认知还停在"HP 5 加一堆随意 include"的年代，那你错过的东西太多了：

• declare(strict_types=1);
  
• 标量类型和返回类型
  
• 类型化属性
  
• 联合类型
  
• 枚举
  
• 属性注解（Attributes）
  
• 更好的错误语义
  
• Composer 成为标配
  
• PSR 标准
  
• 优秀的框架（Laravel、Symfony）和组件
  
• 静态分析工具（PHPStan/Psalm）
  
• 代码格式化工具（PHP-CS-Fixer）
  
• 容器化 / CI 工作流
  

语言进化了，但很多团队没有。
所以真正的问题是：你写 PHP 的时候，是把它当成一门现代后端语言，还是当成赶工时凑合用的脚本？
经典 PHP 反模式："什么都塞进控制器"

下面这套流程，在很多项目里都能看到：

• 控制器接收请求
  
• 控制器做验证
  
• 控制器拼查询
  
• 控制器处理业务规则
  
• 控制器更新数据库
  
• 控制器格式化响应
  
• 控制器触发副作用（邮件、队列）
  

能跑，能上线，功能还能往上堆。然后就开始变脆——因为控制器已经变成了一个揽了业务规则、数据持久化和 I/O 的上帝对象。
看一个简化版的例子。
❌ 反模式：所有逻辑塞在控制器里

[code]