答案是先运行composer why-not vendor/package:version定位阻塞链，再结合composer show --tree分析真实依赖结构，避免盲目删除vendor或composer.lock；需检查require-dev等隐形冲突源，并用--with-dependencies定点更新。
composer why-not 能直接告诉你谁在封杀目标版本
报错里出现 Conclusion: don't install vendor/package:2.0.0 时，别急着改 composer.json。先跑 composer why-not vendor/package:2.0.0，它会逐层列出所有阻止该版本的依赖链——最上面那条才是真正的“卡点”。
常见误判是看到某深层包（比如 symfony/console）被某个测试工具拉进来，就以为要动它；其实真正起决定作用的，往往是你的直接依赖（如 laravel/framework 或 spatie/laravel-backup）写的约束太窄。
-
composer why-not输出里带requires的行，说明它主动提了要求；带conflict的行，说明它硬性拒绝某些组合 - 如果输出里出现
Root package requires，问题就在你自己的composer.json里，比如写了"php": "7.4"却想装只支持 PHP 8+ 的新包 - 注意
composer prohibits是补充命令，它只显示“谁不让装”，不体现约束强度，适合交叉验证
用 --no-update + 精准 update 缩小影响范围
想强制降级或锁定一个包，不能直接 composer require vendor/package:1.2.3，否则 Composer 会立刻重算整棵树并大概率失败。正确做法是分两步：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先加
--no-update：例如composer require monolog/monolog:1.25.0 --no-update，只改composer.json，不触发解析 - 再单独更新它：
composer update monolog/monolog，让求解器只围绕这个包及其子依赖重试，避免牵连其他稳定模块 - 如果仍冲突，说明还有别的包强绑了更高版本，这时再跑
composer show -t | grep monolog看完整路径，定位第二个“钉子户”
锁文件冲突或解析卡死时，别删 vendor/ 或 composer.lock
合并分支后 composer install 报错、或者 composer update 卡在 Resolving dependencies 超过 5 分钟，本质是 SAT 求解器在暴力穷举无解空间。删 vendor/ 或 composer.lock 只会让问题更难复现，不是解决路径。
- 锁文件有 git 冲突标记？运行
composer update --lock，它会重新生成一致的composer.lock并修正哈希值 - 解析太慢？先试
composer update --dry-run -v，看日志里是否反复出现Trying+ 回退，确认是求解瓶颈 - 临时提速可加
--minimal-changes（Composer 2.2+），它只更新必要包，跳过语义兼容的微调 - 真要大改，用
composer update vendorA/pkgA vendorB/pkgB --with-dependencies，每次只动一两个关键路径，逐步收敛
conflict 和 replace 字段不是备注，是硬性执行规则
conflict 在 composer.json 里不是“友情提示”，它会让 Composer 主动拒绝安装任何匹配组合——哪怕那个包你根本没 require，只要被其他依赖间接拉入，就会触发拦截。同理，replace 是替代声明，不是功能等价暗示。
- 私有包里写
"conflict": {"laravel/framework": ">=11.0"}，结果项目里没装 L11，却报冲突？大概率是某个已装包（比如orchestra/testbench）悄悄把 L11 拉进来了 -
replace后必须确保被替代项真能覆盖全部行为。例如用symfony/polyfill-mbstring替代ext-mbstring可行；但用mockery/mockery去“替换”phpunit/phpunit的 mock 功能，运行时必崩，因为 PHPUnit 内部调用绕不开自己的实现 - 诊断时可临时注释掉
conflict字段，看能否快速出解——但这只是排查手段，不能留在线上
require、每个间接依赖的 conflict、甚至平台配置里的 platform.php。最容易被忽略的是，require-dev 里的包也会参与主依赖图求解——比如 orchestra/testbench:^7.0 硬绑 Laravel 9，而你主项目用的是 Laravel 10，冲突就藏在这儿。 
