直接运行 composer update vendor/package-name 即可安全升级单个包，无需删 composer.lock 或加 flag；它会自动升级该包及其必要子依赖（如 psr/log），但不会无故升级无关包，真正风险在于关键子依赖（如 symfony/console）被意外升大版本。
想只升一个包又怕连带崩掉其他依赖？直接 composer update vendor/package-name 就行，不用删 composer.lock，也不用加任何 flag。
为什么 composer update monolog/monolog 会升级别的包？
它确实会升级 monolog/monolog 的子依赖（比如 psr/log），但这是 Composer 求解器在履约：必须让整个依赖图仍满足所有 composer.json 中的约束。这不是失控，是必要行为。
- 如果
monolog/monolog新版要求psr/log ^2.0，而你锁的是1.1.4，那psr/log就得升 - 真正危险的是关键子依赖被推高小版本，比如
symfony/console从5.4升到6.0，导致 Artisan 命令异常 - 想预判影响？先跑
composer show monolog/monolog看它的依赖树，再决定是否手动在composer.json中锁定关键子依赖（如"symfony/console": "^5.4"）
升级失败时，composer why-not 比删 vendor 有用十倍
报错 “Conclusion: don't install laravel/sanctum:^3.0” 只是结果，composer why-not laravel/sanctum:^3.0 才告诉你谁在联合阻断。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 输出里第一行通常是你的项目根依赖（
myapp/myproject dev-main）在 require 某个旧版 - 若某行末尾标着
conflict with guzzlehttp/guzzle (>=7.0)，说明是那个包自己声明了互斥规则，不是 Composer 胡来 - 如果输出为空或只写
nothing，大概率是目标版本根本没发布，别再猜约束问题了
--with-dependencies 和 --with-all-dependencies 到底差在哪？
前者只重算目标包及其直系依赖，后者会主动升降整棵树里的已有包来腾出空间——风险等级完全不同。
- 要升
monolog/monolog并允许它所需的最小依赖集变动，用composer update monolog/monolog --with-dependencies - 用
--with-all-dependencies前必须确认你信任新包生态，且接受symfony/http-foundation之类可能从 v5 升到 v6 - 这两个参数都不解决 PHP 版本不匹配问题；如果提示 “requires php ^8.1”，请先检查
php -v和composer config platform.php是否一致
最容易被忽略的三个“静默陷阱”
它们不会报错，但会让你以为更新成功，实际什么都没变，或者埋下运行时雷。
- 漏写 vendor 名（如敲成
composer update monolog）→ 报错；但拼错包名（如monolg/monolog）→ 静默成功，什么也不做 -
composer.json里重复声明同一包不同版本（如两次写"monolog/monolog"），Composer 只认最后一个，但composer show输出可能误导你 - 用了
"some/package": "dev-main"却没加#commit-hash→ 下次composer update可能拉进 break change，而composer outdated根本不提醒
