composer why-not laravel/framework:11.0.0 能精准定位阻断链，输出从根依赖到目标版本的完整冲突路径，末尾带 (for xxx) 的行即需调整的真实拦路包。
composer why-not 能直接定位谁在封杀目标版本
报错里只写 Conclusion: don't install laravel/framework:^11.0，但没说谁拦的。别猜，直接执行 composer why-not laravel/framework:11.0.0——必须带完整版本号，否则报 [InvalidArgumentException] Package not found。
输出会是一条阻断链，例如：
myapp/myproject dev-main requires spatie/laravel-backup (^7.2) spatie/laravel-backup v7.2.0 requires symfony/console (^5.4) laravel/framework 11.0.0 requires symfony/console (^6.4)
最后一行才是你要升级的目标，往上每行末尾的 (for spatie/laravel-backup v7.2.0) 就是真正需要调整的包。它不一定是你写的，很可能是 require-dev 里的测试工具或私有 SDK 拉进来的。
-
why-not查的是“你想装但装不了”的版本，不是“谁依赖了它”——别用depends替代 - 如果输出为空，说明冲突不在已安装包，而是
require-dev中某个包在解析时悄悄引入了不兼容约束 - 看到
conflict with foo/bar (>=2.0)，说明那个包自己写了conflict字段，这是硬拦截，不是 Composer 主动拒绝
composer show -t 展示的是 lock 文件里真实锁定的结构
composer show -t 输出的不是你 composer.json 里写的理想状态，而是 composer.lock 里最终落定的依赖快照。比如你写了 "guzzlehttp/guzzle": "^7.0"，但树里显示 v6.5.8，说明已有其他包强制要求 v6，Composer 已妥协降级。
关键看每行末尾的 (locked to 5.4.42)——这个版本已被锁死，想松动必须删 composer.lock 或改上游约束后重跑 update。如果同一包出现两次且版本不同（如 monolog/monolog 一次是 ^1.25、一次是 ^2.10），说明上游存在不兼容分支，得往上翻是谁引入的。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 遇到
(replaced)或(provided)标记，立刻查对应包的composer.json，确认是否真能等价替代 -
show -t在 Composer 2.5+ 才稳定可用；低于 2.2 的需先升级 Composer - 用
composer show -t | grep "symfony/console"快速定位路径和锁定版本
composer update --dry-run -v 是唯一看清“谁在拉扯谁”的方式
全量 composer update 容易让 SAT 求解器卡住几分钟，还可能引发连锁降级。而 composer update --dry-run -v 不改任何文件，却会把求解过程完整打印出来：哪些包被升级/降级、主版本号是否变化、有没有触发新的 conflict 提示。
尤其注意日志里反复出现的 Trying 和回退记录——那是求解器在暴力试错。当项目有 conflict、replace 或 30+ 包时，复杂度指数上升，这时候盲目重试只会浪费时间。
- 优先对单个包执行
composer update vendor/package --dry-run，缩小排查范围 - 若要测试兼容性，用
composer update --with=monolog/monolog:^2.0临时调整，但别提交到composer.json - 慎用
--with-all-dependencies：它会让 Composer 主动重算整棵树，适合你明确信任新包、且接受关联变更的场景
不要删 vendor 或 composer.lock 来“解决”冲突
删 vendor 和 composer.lock 看似干净，实则是掩盖问题。它丢失了精确版本锁定，下次 install 可能拉到不一致的新版本，冲突只是延迟爆发。
真正该做的是：先用 composer show -t 看清当前实际结构，再用 composer prohibits 或 why-not 反向定位卡死点。如果冲突来自 require-dev，比如 phpunit/phpunit 拖进旧版 symfony/console，就该隔离处理——加 --no-dev 先验证生产环境是否可装，再单独处理测试依赖。
- 锁文件损坏或长期未更新？用
composer update --lock重建，不改依赖版本 - Git 合并导致
composer.lock冲突？别手动编辑，运行composer update --lock让 Composer 自动修复哈希 - 看到
Root requires X but Y is installed，先跑composer install --dry-run，不是直接update
依赖树的“最小解”往往藏在第二、三层间接依赖里，而不是你亲手写的那几行 require。真正难的不是命令怎么敲，而是读懂 show -t 每行末尾括号里的信息，以及分辨出哪一行的 (for ...) 才是你该动手改的地方。
