Composer依赖升级后的破坏性变更测试

真实破坏性变更需通过测试失败与运行时异常识别，而非仅看composer update版本号

先明确一个核心原则：composer update 输出的版本号变化，充其量只是个“预告片”。真正的“剧情反转”——那些接口、行为或返回值的实质性变动——往往藏在运行时异常和测试失败的细节里，尤其是那些单元测试覆盖不到的边界路径。

所以，标准操作流程应该是：升级前，先完整跑一遍测试套件（比如 vendor/bin/phpunit），建立一个基准。接着执行 composer update，然后立刻再跑一遍测试。前后两次失败用例的差异，才是破坏性变更最直接的证据。

• 重点关注 TypeError、ArgumentCountError 这类类型错误，以及 Deprecated 警告（在 PHP 8.1+ 环境下，默认会转为异常）。
• 仔细检查日志，看是否有新的 InvalidArgumentException 或 LogicException 被抛出，特别是那些源自依赖包内部构造函数或工厂方法的异常。
• 特别留意返回值类型的隐形变化。比如，某个方法原来返回 array，新版却改成了 Collection 或 Tra versable。如果你的下游代码还在用 count() 或 array_key_exists() 处理，问题就来了。

为什么 vendor/autoload.php 重载后行为会变

这里有个常见的认知误区：认为 Composer 的自动加载是份“静态地图”。其实不然，它是根据 composer.json 里的 autoload 和 autoload-dev 配置动态生成的。升级依赖很可能触发 autoload 机制的重建，导致类加载顺序、命名空间解析路径，甚至 PSR-4 的映射规则发生微妙偏移。

典型症状就是：代码在本地测试一切正常，一到 CI 环境就失败；或者，某个类在 Web 请求中能正常找到，在 CLI 命令行下却报 Class not found。

• 执行 composer dump-autoload --optimize 后，务必记得清空 OPCache（调用 opcache_reset() 或直接重启 PHP-FPM）。
• 检查项目是否混用了 classmap 和 psr-4 来映射同一个命名空间——新版本的 Composer 对这类冲突的校验可能更严格。
• 如果使用了 exclude-from-classmap 排除文件，要确认这些被排除的文件，没有被其他包通过 require_once 直接引入。

mock 依赖时容易忽略的底层协议变更

测试环节是重灾区。很多团队习惯用 Mockery 或 PHPUnit::createMock() 来模拟第三方服务客户端（比如 GuzzleHttp\Client、Aws\S3\S3Client）。问题在于，升级之后，这些被模拟类的构造参数、方法签名或内部调用链可能已经改变，导致 mock 对象行为失效，或者抛出意料之外的异常。

举个例子：monolog/monolog 从 v2 升级到 v3 时，移除了 Monolog\Handler\StreamHandler::__construct() 构造函数的第三个参数 $useLocking。如果你的 mock 还在按旧版传4个参数，ArgumentCountError 就会立刻找上门。

• 最佳实践是：尽量不要 mock 具体的实现类，优先 mock 它们实现的接口（例如 Psr\Log\LoggerInterface）。
• 对于不得不 mock 的具体客户端类，可以考虑用 getMockForAbstractClass() 替代 createMock()，这能在一定程度上规避构造函数参数不匹配的问题。
• 一个务实的策略：在 composer.json 的 require-dev 部分，锁定那些被频繁 mock 的依赖包版本，直到测试用例完成适配。

CI 环境里最常漏掉的兼容性检查点

环境差异是破坏性变更的“隐身衣”。本地开发用 PHP 8.2，CI 却跑在 PHP 7.4 上？或者本地开了 Xdebug，CI 环境关闭了？这些不一致会让某些变更彻底“隐形”。特别是涉及 ReturnTypeWillChange 属性、或者 __serialize()/__unserialize() 魔术方法的改动，在低版本 PHP 下根本不会触发任何警告或错误。

更隐蔽的坑在于扩展依赖。例如，ext-intl 扩展在旧版 symfony/intl 里是可选的，但新版可能变成了强制要求。composer install 时可能风平浪静，一到运行时才会突然崩溃。

• 在 CI 流水线中，加入 composer check-platform-reqs 步骤，确保所有 PHP 扩展和版本都满足新依赖的要求。
• 使用 composer show --tree 对比升级前后的依赖树，重点扫一眼 ext-*（扩展）和 php 版本约束这两行，看是否被收紧了。
• 将 vendor/bin/phpunit --fail-on-warning 加入 CI 步骤，不让任何 Deprecated 警告悄悄溜过去。

话说回来，最棘手的破坏性变更，往往藏在“没有报错，但结果就是不对”的灰色地带。比如：缓存键的生成逻辑悄无声息地变了；JSON 序列化时对 null 值的处理策略不同了；甚至只是日志的时间格式多了一个微秒字段。这些都不会导致测试失败，却足以让下游系统行为异常。因此，在上线前，至少拿一两条真实的业务数据，完整地走一遍端到端的核心流程，这往往是最后一道，也是最有效的安全网。