composer update 不等于安全升级，而是重算整棵依赖树，可能引发版本跃迁、PHP扩展行为变更、CI失败等高风险问题；应优先用 composer outdated 评估，再谨慎操作并提交 composer.lock。
直接运行 composer update 升级所有包是高风险操作，不是“更新”，而是重算整棵依赖树——它可能悄悄升级 Symfony、PHPUnit 或 PHP 扩展要求，导致 CI 构建失败或线上命令静默报错。
为什么 composer update 不等于“安全升级”
Composer 的 update 本质是丢弃当前 composer.lock，重新基于 composer.json 中的版本约束解析整个依赖图。它不区分“补丁修复”和“API 破坏”，也不管你有没有跑过测试。
- 默认会升级
require-dev下的所有工具包（比如phpunit/phpunit从 10.5 升到 11.0），而新版 PHPUnit 可能已移除--colors参数，CI 脚本直接挂掉 - 如果
config.platform.php设为8.1.0，但本地 PHP 是 8.2，update仍会按平台配置选包，装完才发现某些扩展（如ext-gd）在 8.2 下行为已变 -
composer update不检查安全漏洞，也不会跳过已知高危版本（除非你开了audit.block-insecure）
composer outdated 才是你该先敲的命令
它不改任何文件，只告诉你哪些包有新版本、是否含主版本跃迁、有没有标 [security]：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 加
--direct：只看composer.json显式声明的包，过滤掉子依赖噪音 - 加
--minor-only或--patch-only（Composer 2.5+）：聚焦小修小补，避开次版本风险 - 看到带
!标记的行（如laravel/framework 9.52 → 10.38 !），别急着 update，先composer why-not laravel/framework:10.*查谁在拦路
真要全量升级，必须用 --with-all-dependencies
只写 composer update 会留下大量“半升不升”的子依赖：比如你升级了 guzzlehttp/guzzle，但它依赖的 psr/http-client 还卡在旧版，运行时抛 Class not found。
-
composer update --with-all-dependencies强制递归更新整棵依赖图中所有可匹配的包 - 但注意：它仍受
composer.json约束限制，不会跨主版本——想升monolog/monolog到 3.x，必须先手动把"^2.0"改成"^3.0" - 执行前务必
git add composer.lock && git commit -m "save lock before bulk update"，否则出问题没法回滚
升级后类找不到？大概率是 autoload 没刷新
90% 的 “Class not found” 不是包没装对，而是自动加载映射没重建：
- 运行
composer dump-autoload -o生成优化后的静态映射（开发环境也建议加-o） - 如果项目用了自定义 PSR-4 命名空间，检查
composer.json的autoload段是否被升级脚本意外覆盖或缩进错乱 - 别删
vendor/再install——这绕过了lock文件校验，可能拉来不兼容的版本
最常被忽略的一点：composer.lock 是契约，不是缓存。它记录的不只是版本号，还有每个包的 exact commit hash、PHP 平台要求、甚至安装时的 config.platform 配置。一次没提交的 update，就等于撕毁了团队间的依赖约定。
