升级前必须确保测试套件稳定运行，否则八成是本地测试未通过而非新包问题；应先验证phpunit等能clean exit、检查autoloader与bootstrap路径、设置APP_ENV=testing、用--with-dependencies最小化更新、对比composer.lock变更行数、通过git回退与composer show -t定位问题、CI中强制--no-cache并记录--outdated输出、对关键逻辑做快照断言。
升级前先确认测试套件能稳定运行
依赖升级出问题，八成不是新包有问题，而是你本地的测试压根没跑通过。别跳这步——composer update 前必须确保 vendor/bin/phpunit（或 php artisan test、./vendor/bin/phpspec 等）能 clean exit，且覆盖率关键路径有覆盖。
常见错误现象：Class 'Tests\TestCase' not found、ReflectionException: Class App\Models\User does not exist，本质是 autoloader 没刷新或测试 bootstrap 错误。
- 运行
composer dump-autoload再试一次测试命令 - 检查
phpunit.xml中的bootstrap路径是否指向vendor/autoload.php或项目自定义入口 - 若用 Laravel，确认
APP_ENV=testing已设，且config/database.php的 testing 连接可用
用 --with-dependencies 配合最小范围更新
直接 composer update 全量升，等于把所有依赖的兼容性风险一次性引爆。应该先锁死主依赖，只动它声明的直接子依赖，再逐个验证。
比如你只想升级 guzzlehttp/guzzle，但它的新版本要求 psr/http-client ≥ 1.0，而你的项目还依赖旧版 symfony/http-client，就会触发连锁变更。
- 先执行
composer update guzzlehttp/guzzle --with-dependencies，让 Composer 自动拉起必要关联包，但不碰其他分支 - 对比
composer.lock变更行数：理想情况应 ≤ 5 行；若上百行，说明影响面过大，暂停，改用--dry-run查看预估变更 - 避免用
composer update --lock，它只重算 lock 文件，不装包，无法暴露运行时类加载或接口变更问题
测试失败时快速定位是哪层依赖导致的
测试报错堆栈里出现 Call to undefined method 或 ArgumentCountError，大概率是某个依赖升级后改了方法签名或删了类——但你不需要手动翻 changelog。
Composer 本身不提供“这个测试失败对应哪个包变更”的映射，得靠隔离手段快速归因。
- 用
git checkout composer.lock回退，再composer install，确认测试恢复 green - 用
composer show -t guzzlehttp/guzzle查看它依赖树，重点盯psr/*、ralouphie/getallheaders这类常被连带升级的轻量包 - 临时在
composer.json中硬加约束，例如"psr/http-message": "^1.0"，再composer update，看是否止住失败
CI 流程里必须跑全量测试 + 差异快照
本地跑过不等于线上安全。很多问题只在特定 PHP 版本、扩展组合或环境变量下暴露，比如 ext-intl 缺失导致 symfony/translation 升级后 fallback 失败。
CI 不只是“跑 test”，还要捕获依赖变更带来的隐性行为漂移。
- 在 GitHub Actions / GitLab CI 的 job 中，强制
composer install --no-cache，避免缓存掩盖 autoload 冲突 - 加一行
composer show --outdated --direct输出到日志，方便回溯哪些包实际被升了 - 对关键业务逻辑，用
php -r "var_dump((new YourService())->handle(...));"做简易快照断言，比纯单元测试更能捕获返回结构变化
最麻烦的永远不是升级动作本身，而是某些包把 @internal 方法暴露成 public，又在小版本里悄悄改了行为——这种事不会报错，只会让你某天发现分页数据少了一半。
