composer update不是升级而是重算依赖树，会忽略composer.lock按composer.json重装全部依赖，可能引入不兼容变更；包仍为旧版是因版本约束（如"^2.0"）禁止升至3.0，需手动改约束再更新并提交新composer.lock。
composer update 不是“升级项目”，而是按 composer.json 重装整个依赖树——它会忽略 composer.lock，重新解析所有依赖，可能引入不兼容变更。
为什么 composer update 后包还是旧版？
不是命令失效，是 composer.json 里的版本约束卡死了。比如写的是 "monolog/monolog": "^2.0"，哪怕 3.0 已发布，Composer 绝对不会装，因为它不敢破坏兼容性。
- 查当前装的版本：
composer show monolog/monolog - 查哪些包有主版本可升（带 ! 标记）：
composer outdated - 想升主版本（如 2→3）：必须手动改
composer.json中对应行，比如把"^2.0"改成"^3.0"，再执行composer update monolog/monolog - 改完后
composer.lock一定会变，记得提交，否则队友composer install还是旧版
只更新一个包，子依赖为什么没动？
这是默认行为：composer update vendor/package-name 只更新该包本身，不碰它的子依赖（比如 guzzlehttp/guzzle 依赖的 psr/http-message 还卡在 1.0.1）。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 修一个安全漏洞又不想牵连整个依赖树 → 用
composer update guzzlehttp/guzzle - 要连带更新直系依赖 → 加
--with，例如composer update guzzlehttp/guzzle --with psr/http-message - 要彻底更新整棵依赖树（含子依赖的子依赖） → 用
--with-all-dependencies，例如composer update guzzlehttp/guzzle --with-all-dependencies -
--with-dependencies在 Composer 2.2+ 已被彻底移除，执行会直接报错Unrecognized option: --with-dependencies
什么时候真该用 composer update？
它不是日常操作，而是特定场景下的“重决策”动作。95% 的日常开发根本不需要它。
- 你刚接手老项目，
composer.lock丢失或严重过时，且无法从 Git 恢复 - 你想测试某依赖（如
symfony/console）的下一个主版本是否兼容，用composer update symfony/console单独验证 - 你修改了
composer.json中的版本约束（例如把"php": "^7.4"改成"^8.1"），需要让 Composer 重新计算兼容组合 - CI 环境跑集成测试前，需确保使用的是当前
composer.json下能解析出的最新合法依赖组合（但更推荐用composer install+ 提交 lock 文件） - 永远先
git status确认没未提交变更；运行前加--dry-run预览：composer update --dry-run
composer update 和 composer install 的本质区别
composer install 是“按锁安装”：读 composer.lock，下载其中记录的**确切版本**（包括哈希校验），确保所有人、所有环境行为一致；composer update 是“按需重算”：忽略锁文件，按 composer.json 重新求解最优解，本质是一次新的依赖决策过程。
CI/CD 流水线里禁止无参数 composer update，否则每次构建都可能得到不同依赖，破坏构建稳定性。真正麻烦的从来不是命令敲得对不对，而是版本约束是否合理、上下游兼容性有没有被隐式破坏、以及那些没写进文档的间接依赖变更。
