答案是运行 composer why-not vendor/package:version 定位阻塞链——它从根依赖逆推，逐层显示谁锁定了冲突版本，最上面一行通常是 composer.json 中过窄的手动约束或不兼容的中间包。
报错 “Conclusion: don’t install xxx” 怎么定位真正卡点
这不是网络或权限问题，是 Composer 在依赖图里找不到满足所有约束的版本组合。关键不是看报错文字本身，而是立刻查谁在阻止那个版本。
运行 composer why-not vendor/package:version（比如 composer why-not monolog/monolog:2.9.0），它会列出完整阻塞链：从你直接写的 require 条目开始，逐层显示哪个包锁死了哪个版本范围。
- 输出里最上面一行通常是“Root package requires”，说明是你
composer.json里手动写的约束太窄（比如写了"php": "7.4"，但新包已放弃支持） - 如果阻塞源是某个插件（如
spatie/laravel-backup），别急着删它——先查它的 GitHub 或 Packagist 页面，确认是否已有兼容新版 Laravel 的 release - 避免用
composer depends替代why-not，前者只告诉你“谁依赖它”，不体现版本限制，无法用于冲突诊断
执行 composer update 时怎么避免把整个依赖树带崩
默认 composer update 会重算全部依赖，容易把线上稳定的子依赖也升到不兼容大版本（比如 guzzlehttp/guzzle 从 7.x 升到 8.x，导致 new GuzzleHttp\Client() 报错）。
真要更新，必须定点 + 带依赖链：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 写死包名，不加引号、不加波浪号：
composer update monolog/monolog，不是composer update "monolog/monolog:^3" - 加上
--with-dependencies：它只允许 Composer 升级该包及其直系依赖，不会碰phpunit这类无关项 - 加
--dry-run先预览：composer update monolog/monolog --with-dependencies --dry-run，确认改动范围再执行 - 升级后立刻
git diff composer.lock，只接受预期变更；如果多了十几个包，说明约束没控住，得回退
PHP 版本不匹配导致 install 失败怎么办
报错 requires php ^8.1 but your PHP version (7.4.33) does not satisfy that requirement，根源是 Composer 用当前 shell 的 php -v 结果去校验，不是配置文件写错了。
- 不要加
--ignore-platform-reqs硬过——vendor 里会混入 PHP 8.1 语法（如match表达式），本地一跑就ParseError - Linux/macOS 下明确调用目标 PHP 二进制：
/usr/bin/php8.1 composer install - Windows 下用完整路径：
"C:\php\php81\php.exe" composer install -
config platform.php是个陷阱：只应在打包部署场景用（比如 PHP 7.4 机器上生成适配 PHP 8.2 的 vendor），且必须跟composer update --lock同步生效；日常开发禁用
删 vendor 和 composer.lock 后还是装不上？别白忙
缓存不是根源。删了再 install，只是用当前 php -v 和 composer.json 重跑一遍解析逻辑——如果环境或约束没变，报错原样重现。
- 先确认
php -v、which php、composer config platform.php三者一致，否则 Composer 自己都搞不清该按哪个版本算 - 检查
composer.json里有没有互斥约束（比如同时写了"laravel/framework": "^9.0"和"barryvdh/laravel-debugbar": "^3.0"，而后者 3.x 还不支持 Laravel 9） - 临时换国内镜像源（如阿里云）能解决卡住，但不能绕过语义版本冲突；
composer clear-cache只对下载失败有效，对解析失败无用
依赖冲突本质是约束交集为空，不是缓存脏了或命令敲错了。最常被忽略的是：你以为在调 Composer，其实它全程在忠实执行你 composer.json 里写的每一行 require，以及你本地 php -v 暴露的真实能力。
