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 的认知还停在"PHP 5 加一堆随意 include"的年代，那你错过的东西太多了：
[*]declare(strict_types=1);
[*]标量类型和返回类型
[*]类型化属性
[*]联合类型
[*]枚举
[*]属性注解（Attributes）
[*]更好的错误语义
[*]Composer 成为标配
[*]PSR 标准
[*]优秀的框架（Laravel、Symfony）和组件
[*]静态分析工具（PHPStan/Psalm）
[*]代码格式化工具（PHP-CS-Fixer）
[*]容器化 / CI 工作流
语言进化了，但很多团队没有。
所以真正的问题是：你写 PHP 的时候，是把它当成一门现代后端语言，还是当成赶工时凑合用的脚本？
经典 PHP 反模式："什么都塞进控制器"
下面这套流程，在很多项目里都能看到：
[*]控制器接收请求
[*]控制器做验证
[*]控制器拼查询
[*]控制器处理业务规则
[*]控制器更新数据库
[*]控制器格式化响应
[*]控制器触发副作用（邮件、队列）
能跑，能上线，功能还能往上堆。然后就开始变脆——因为控制器已经变成了一个揽了业务规则、数据持久化和 I/O 的上帝对象。
看一个简化版的例子。
❌ 反模式：所有逻辑塞在控制器里
热心回复！ 收藏一下 不知道什么时候能用到 感谢分享，下载保存了，貌似很强大 这个好，看起来很实用 这个好，看起来很实用 喜欢鼓捣这些软件，现在用得少，谢谢分享！
页:
[1]