composer update 不等于安全升级，因其强制重算依赖图、忽略 lock 文件锁定版本、不校验语义化兼容性，易引入破坏性变更；应改用 composer outdated + 手动逐个升级并验证。
直接升级所有依赖包不可靠，composer update 默认行为不是“安全批量更新”，而是强制重算整个依赖图——稍有不慎就会引入不兼容变更或破坏生产环境。
为什么 composer update 不等于“安全升级”
它会忽略 composer.lock 中已锁定的版本，重新从 composer.json 的约束（如 "^2.0"）出发，拉取满足条件的最新小版本甚至次版本。如果某包刚发布了不兼容的 2.5.0，而你本地锁的是 2.4.3，composer update 就可能直接跳到 2.5.0 并静默失败。
- 错误现象：
Class not found、Method does not exist、测试全挂，但composer update命令本身没报错 - 根本原因：Composer 不做语义化版本兼容性校验，只做约束匹配
- 真实场景：CI 流水线里执行
composer update导致部署后 500，回滚才发现是guzzlehttp/guzzle升到了7.9.0，而代码还用着Promise::then()（已在8.0移除）
想批量升级？先明确目标类型
“升级所有包”本身是个模糊需求，实际只有三种合理路径，选错就踩坑：
-
仅升补丁版（最安全）：用
composer update --with-dependencies配合^或~约束，但必须确认所有包都严格遵守 semver -
升指定包及其子依赖：比如只动
laravel/framework，运行composer update laravel/framework，它会连带更新其要求的symfony/*版本，但不动monolog/monolog -
强制刷新 lock 文件（慎用）：
composer update --lock只重写composer.lock，不改 vendor，适合修复 lock 文件损坏，但不会真正升级任何包
替代方案：用 composer outdated + 手动控制
这才是稳定项目该用的方式——看清再动，而不是赌运气。
- 先运行
composer outdated --direct，只看composer.json里直写的包，过滤掉传递依赖干扰 - 对每个待升级包，查它的 CHANGELOG（尤其注意
Breaking changes小节），比如phpunit/phpunit从9.6升10.0要求 PHP 8.1+ - 逐个升级：
composer update symfony/console:^6.4，加^6.4明确范围，比空跑update少一半风险 - 升级后立刻跑
git diff composer.lock，确认只改了预期的几行，没连带把doctrine/dbal从3.6推到4.0
CI/CD 里绝对不要用裸 composer update
很多团队在 GitHub Actions 里写 run: composer update，结果每次 PR 都触发全量重算，vendor 目录漂移、缓存失效、构建变慢——更危险的是，它绕过了本地验证流程。
- 正确做法：CI 只运行
composer install --no-interaction --prefer-dist，确保和composer.lock完全一致 - 升级操作必须由人发起，在本地完成测试、提交新
composer.lock后，CI 才照单安装 - 如果真要自动化升级，用
composer require --update-with-dependencies加具体包名，或者上dependabot这类专注语义化版本边界的工具
真正难的不是命令怎么敲，而是判断哪个包能升、升到哪一位、要不要先改代码适配——composer.lock 是契约，不是障碍；把它当黑盒去绕开，迟早被反噬。
