旧PHP依赖为何常比业务代码更危险?

接手一个运行多年的 PHP 项目时，大部分开发者的注意力会自然落在业务代码上——控制器里的逻辑是否合理、模板里的输出是否正确、数据库查询是否高效。但真正的风险往往不在这些看得见的地方。老旧 PHP 项目的依赖层，通常比业务代码本身更危险，因为它同时具备三个特征：不可见、不可控、不可追溯。

业务代码的问题至少是显性的。一个函数写错了，测试会暴露；一段逻辑有漏洞，审计能发现。但依赖是"别人的代码"，它以二进制或源码形式嵌在项目的 vendor 目录里，既不会在日常 Code Review 中被逐行检查，也不会在功能测试中被刻意覆盖。大多数团队对依赖的态度是"能跑就行"，直到某个安全公告或线上故障把问题推到眼前。

这种危险在旧项目中会被进一步放大。PHP 生态的依赖管理工具 Composer 虽然解决了包安装和版本约束问题，但旧项目的 composer.lock 往往锁定了三五年前甚至更早的版本。这些版本可能已经停止维护，不再接收安全补丁，却仍然运行在支付回调、用户认证、文件上传等核心路径上。一个存在已知反序列化漏洞的旧版库，如果被放在处理用户输入的位置，其危害远超一段写得不好的业务代码——后者出问题影响的通常是功能正确性，前者出问题直接影响的是系统安全性。

更隐蔽的风险在于依赖的传递性。一个项目显式声明了十几个直接依赖，但实际安装的包可能有上百个。这些间接依赖的版本完全由直接依赖的约束决定，开发者很少主动审查它们。一旦某个深层依赖被发现存在高危漏洞，修复路径可能非常漫长：要么等待上游更新后逐层传递，要么自己 fork 并维护一个补丁版本。对于已经无人维护的旧项目，这两条路都可能走不通。

依赖的另一个危险在于"沉默的破坏"。业务代码修改后，行为变化是明确的、可预期的；但一次看似无害的依赖升级——比如从 2.3.1 升到 2.3.2——可能引入类型约束变化、废弃函数移除或错误处理机制调整。这些变化在旧 PHP 项目中尤其致命，因为历史代码大量依赖隐式类型转换、静默错误吞没和未定义行为的"恰好能跑"。升级后的依赖不再容忍这些灰色地带，但它报错的位置往往不在依赖本身，而在业务代码调用依赖的地方。这时开发者面对的是一个看似"突然坏了"的业务功能，却很难第一时间定位到依赖升级这个根因。

因此，接手旧 PHP 项目时，审计优先级应该倒过来：先查依赖，再看代码。确认 composer.lock 中锁定的版本是否有已知 CVE、是否仍在维护周期内、是否存在版本冲突。用 Composer 的 audit 命令扫描安全漏洞，用 PHPStan 建立静态分析基线覆盖依赖调用点。只有把依赖边界摸清楚，后续的业务代码修复才有稳固的基础。否则，你改好了一个登录漏洞，却可能因为一个过期依赖的下一次升级，让整个认证模块再次失控。