依赖升级需事件驱动而非定期执行，须结合安全告警、平台升级、功能需求等场景，精准控制升级范围与粒度，并严格审查 composer.lock 变更。
依赖升级不是“定期跑一次 composer update”就能解决的事——它本质是项目稳定性、安全响应和开发节奏的三方博弈。 直接删 composer.lock 或盲目全量升级，等于主动放弃对运行环境的控制权。
为什么不能只靠 composer outdated 做升级决策
这个命令只告诉你“有新版本”，不告诉你“能不能升”。它完全忽略当前依赖树的实际约束关系和冲突链。
- 显示
laravel/framework 9.52.15 → 10.38.1，但composer update laravel/framework可能直接失败：因为spatie/laravel-backup还锁在 v7，而它不兼容 Laravel 10 - 它不会提示你某个包的子依赖（如
symfony/console）已卡在 v5.4，而新版本 Laravel 要求 ≥6.2 - 安全扫描报告的漏洞版本，可能已被你本地
composer.lock中某条间接依赖“冻结”住，outdated根本不显示
升级计划必须绑定到具体场景，而不是时间周期
按“每月一号更新”这种机械节奏升级，大概率在周五下午三点触发线上故障。真正有效的计划由事件驱动：
-
安全告警触发：CI 流水线集成
composer audit，发现高危漏洞后，立即锁定受影响包范围，用composer why-not vendor/package:fixed-version定位阻塞点 -
平台升级触发：PHP 升到 8.3 后，先跑
composer update --dry-run，再重点检查ext-*和php约束不匹配的包 -
功能需求触发：要接入新支付网关，对方 SDK 要求
guzzlehttp/guzzle ^7.8，那就只动这一条，加--with-dependencies确保psr/http-client等配套升级，不碰其他生态
composer update 的三种执行粒度怎么选
命令本身没“智能”，效果取决于你传什么参数、改没改 composer.json、以及 composer.lock 是否干净：
- 只升一个包且保持最小扰动：
composer update monolog/monolog—— 它只更新该包及其直系依赖，不碰其他分支；包名拼错会静默失败，务必先composer show monolog/monolog确认存在 - 升主版本或突破当前约束：必须先改
composer.json，比如把"symfony/console": "^5.4"改成"^6.0"，再执行composer update symfony/console；直接加--ignore-platform-reqs可能装上根本不能运行的版本 - 解决“升了主包但子依赖还是旧的”问题：
composer update laravel/framework --with-all-dependencies—— 它会递归放开所有已安装包的约束重新计算，但不会动 lock 文件里残留的孤儿包；CI 中建议加composer validate --strict预检 lock 文件
最常被忽略的其实是 composer.lock 的状态：它不是缓存，而是契约。每次升级后，git diff composer.lock 必须进 PR review，否则你永远不知道 vendor/ 下实际变了什么。
