composer outdated 不可直接信任，因其仅标注版本更新类型（如 ! major），不提示破坏性变更、弃用或行为差异；需结合语义化版本、调用链分析（composer depends --tree）、CHANGELOG 中 Breaking Changes 小节综合评估风险。
composer outdated 为什么不能直接信
它只告诉你哪些包有新版本，但不说明变更是否涉及 break、deprecation 或行为差异。比如 monolog/monolog 从 v2.9.0 升到 v3.0.0 是重大变更（PHP 8.1+ only，接口重写），但 composer outdated 只标个 ! major，没上下文。
真正要评估风险，得结合三件事：版本语义、实际调用链、运行时兼容性。
-
composer show vendor/package查当前安装版本的依赖树和 require 约束 -
composer depends vendor/package找出哪些你自己的代码或第三方包直依赖它（尤其注意--tree参数） - 重点看 CHANGELOG.md 或 GitHub Releases 页面里
Breaking Changes和Migrating from vX to vY小节，别只扫一眼composer.json的require行
怎么模拟升级又不污染当前环境
别在开发分支直接 composer update —— 一次升级可能触发几十个间接依赖更新，很难归因问题。
推荐用 composer update --dry-run 配合精准包名：
composer update symfony/http-kernel --dry-run --with-dependencies
它会列出所有将被更新的包及其版本，且不写入 composer.lock。加上 --with-dependencies 是关键，否则可能漏掉 symfony/http-kernel 依赖的 psr/cache 等底层变更。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 想测多个包组合？用
composer update vendor/a vendor/b --dry-run，避免全量更新干扰判断 - 如果项目用了
config.platform（比如锁定"php": "8.0"），确保--dry-run结果里没有违反该平台的版本（例如出现要求php:^8.2的包） -
--dry-run不执行autoload-dump，所以不会暴露自动加载冲突，这一步得后续手动验证
升级后哪些测试能快速暴露风险
不是所有测试都同等有效。优先跑这几类：
- 类型检查：
vendor/bin/phpstan analyse src/—— 很多 v3 升级会改返回类型（如array→list），PHPStan 能立刻报错 - 单元测试里显式 new 了被升级类的地方：
grep -r "new HttpKernel" tests/，这些最可能因构造函数参数变化而崩 - HTTP 功能测试中涉及中间件、事件监听器、序列化逻辑的用例 —— 比如升级
symfony/event-dispatcher后，EventSubscriberInterface的方法签名变动会导致监听器静默失效 - 检查
composer.lock差异：对比升级前后文件，用git diff --no-index old.lock new.lock | grep 'version|source'快速定位哪些包跳了主版本
为什么 vendor/autoload.php 重生成有时会失败
这不是 Composer 自身报错，而是升级后某些包的自动加载规则和你的 composer.json 中 autoload / autoload-dev 冲突。典型现象是 Class not found，但类文件明明存在。
常见原因：
- 被升级包改了 PSR-4 命名空间映射（比如从
"MyLib\": "src/"改成"MyLib\V2\": "src/v2/"），而你代码里还用旧命名空间引用 - 你的项目用了
classmapautoload 方式，但升级后某依赖删掉了某个老路径下的类文件，composer dump-autoload仍试图加载已不存在的路径 -
composer install时用了--no-autoloader选项（CI 场景常见），但后续忘了补composer dump-autoload
解决办法：先 rm -rf vendor/autoload.php，再 composer dump-autoload -o 强制重建；若失败，加 -v 看具体哪个包的 autoload 配置解析异常。
最麻烦的是混合了静态分析工具和运行时加载的场景 —— 比如 PHPStan 认为类存在，但 class_exists() 返回 false，这时候得查 composer show -s vendor/package 看它的 autoload 配置是否被其他包覆盖。
