composer outdated 默认仅显示语义化版本兼容范围内可升级的包，含当前版、最新稳定版及更新许可状态；加 --all 可查看主版本跃迁，--direct 限根依赖，--minor-only 排除主版本升级，--no-ansi 避免颜色乱码。
composer outdated 能看到哪些包要升级
直接运行 composer outdated 是最轻量的检查方式，它列出所有已安装但有新版可用的包，包括当前版本、最新稳定版、是否允许更新（根据 composer.json 中的版本约束）。注意：它默认只显示「语义化版本兼容范围内」可升的包；如果想看所有可升级项（含主版本跃迁），得加 --all 参数。
常见误判点：看到某包标着 dev-main 或 dev-develop 就以为能随便升——其实这类分支不受语义化约束，outdated 可能不显示，得手动查源码或用 composer show vendor/package 确认提交哈希和更新时间。
- 加
--direct只看根依赖（你手动 require 的那些） - 加
--minor-only排除主版本升级（避免意外 break） - 输出带颜色？终端不支持时加
--no-ansi，否则可能乱码
composer update --dry-run 不真装，但会暴露冲突
composer update --dry-run 是生成“影响报告”的核心动作。它模拟整个依赖解析过程：重算依赖图、检测版本约束冲突、触发插件钩子（比如 composer-plugin-api 兼容性检查），最后告诉你哪些包会被升级/降级/移除——但不写入 vendor/ 或修改 composer.lock。
容易被忽略的是：这个命令受当前 composer.json 和 composer.lock 共同影响。如果 lock 文件里锁了旧版间接依赖，而 json 里又没显式约束，--dry-run 可能仍沿用 lock 中版本，导致你以为“没变化”，实际更新后行为不同。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 想强制重新解析全部依赖？先删
composer.lock再跑--dry-run（慎用，仅用于评估全量变更） - 只测某个包升级影响？用
composer update vendor/package --dry-run - 输出太长看不清？加
--verbose查具体冲突原因，比如Your requirements could not be resolved
用 composer depends 查谁在拖慢升级
当你发现某个包卡在旧版升不了，composer depends vendor/package 能快速定位“阻塞者”。它倒查依赖树，列出所有直接或间接要求该包特定版本的上游包——这才是真实瓶颈所在。
典型场景：你想升 symfony/console 到 v6，但 outdated 显示它被锁在 v5.4。运行 composer depends symfony/console 后发现 laravel/framework 要求 "symfony/console": "^5.4"，而你用的 Laravel 版本尚未适配 Symfony 6。这时候升级路径就明确了：先升 Laravel，再升 console。
- 加
--tree显示完整依赖路径（比如 A → B → C → target） - 加
--recursive追查更深层间接依赖（但输出爆炸，建议先试默认） - 注意：某些包通过
replace或provide声明替代关系，depends不会追踪这类逻辑，得人工核对composer.json
生成可读报告：别只靠终端滚动
把 composer outdated 和 composer update --dry-run --verbose 的输出直接丢给团队，基本等于没报告。真正有用的升级影响报告得结构化：分组（安全更新 / 主版本 / 次版本）、标注风险（如 phpunit/phpunit 升级到 v10 会移除 assertArraySubset）、附上变更日志链接。
没有现成命令一键生成这种报告，但可以用 shell 组合快速提取关键信息。例如导出待升级包列表：composer outdated --format=json | jq -r '.packages[] | select(.latest != .version) | "\(.name) \(.version) → \(.latest)"'。再配合 composer show -s 抓每个包的 source 字段，就能拼出 GitHub Release 链接。
- CI 中自动化？用
composer validate --strict提前拦截composer.json语法或平台配置错误（比如 PHP 版本不匹配） - 安全更新单独处理？
composer audit（Composer 2.5+）能扫描已知漏洞，但它不解决依赖冲突，得结合--dry-run手动验证修复路径 - 最常漏掉的细节：autoload 优化失效。升级后若发现类加载变慢，检查
composer dump-autoload --optimize是否需重跑，尤其当包内psr-4映射有变更时
