结论是composer why-not vendor/package:version可精准定位阻塞链，必须用完整版本号（如guzzlehttp/guzzle:8.0.0），输出为空说明未声明该包或被conflict全局屏蔽；它不依赖lock或缓存，直接逆向追踪约束冲突源头。
直接结论：不是包没下载完，也不是网络问题，是 Composer 在本地穷举版本组合时发现无解——必须定位阻塞链，不能删 vendor 或 composer.lock 重试。
用 composer why-not 定位真实阻塞点
报错里出现 Conclusion: don't install xxx 时，composer why-not vendor/package:version 是唯一能看清谁在卡住的命令。它输出的是反向依赖链，从最后一行（你的 composer.json 根声明）往上读，看到第一个带 (required by) 的行，就是冲突源头。
- 必须写完整版本号，比如
composer why-not guzzlehttp/guzzle:^7.5，写成^7或7可能返回空 - 如果输出为空，先检查
require-dev—— 很多冲突来自phpunit/phpunit或mockery/mockery拖着老版sebastian/exporter，间接锁死symfony/console - 别信
composer depends，它只显示“谁依赖我”，不体现版本约束，无法用于冲突排查
看真实依赖树，别信 composer.json 里的“愿望清单”
composer show --tree 显示的是 vendor/ 和 composer.lock 的真实快照，不是你 composer.json 里写的理想状态。它能暴露你根本没意识到的间接路径。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 查某个包被谁引入：
composer show --tree | grep "symfony/console"，看是否标着(locked to 5.4.42) - 过滤关键段：
composer show --tree monolog/monolog | grep -A5 -B5 "guzzlehttp/guzzle"，确认是否某处用了(replaced)或(provided)，得去那个包自己的composer.json里核实 - 如果
composer show --tree输出极长，说明依赖图已复杂到接近 SAT 求解瓶颈，此时应优先收缩minimum-stability或收紧 PHP 版本约束
定点更新，避免全量 composer update 触发求解器卡死
全量 composer update 在大型项目中极易让 SAT 求解器陷入穷举，CPU 跑满、长时间停在 Resolving dependencies。升级单个包必须带 --with-dependencies，否则 Composer 默认拒绝更新其子依赖，哪怕新版本根本跑不起来。
- 正确写法：
composer update monolog/monolog --with-dependencies - 错误写法：
composer update "monolog/monolog:^3"—— 引号 +^会让 Composer 自己找“最新兼容版”，不是你要的3.0.0 - 降级跨主版本（如从
guzzlehttp/guzzle:^8.0切回7.4.5），必须在composer.json里写死："guzzlehttp/guzzle": "7.4.5"，不能只写"^7.0" - 执行后立刻
git diff composer.lock，确认只有目标包及其直系依赖被改，没波及其他
注意 conflict 字段和 repositories 配置的隐性影响
conflict 不是提示，是硬性拦截规则；repositories 数组一旦存在，全局镜像配置就彻底失效——这两点最容易被忽略，却常导致“明明换了镜像还装不上”的假象。
- 私有包加了
"conflict": {"laravel/framework": ">=11.0"}，哪怕你没requireL11，只要其他已装包间接拉进来，就会触发 - 只要
composer.json里有"repositories"字段（哪怕空数组），全局镜像就被丢弃，不是合并，是直接忽略 - 验证镜像是否生效：
composer config -g repo.packagist应输出完整 URL；composer show packagist/support的source.url应含mirrors.aliyun.com - 换镜像后仍卡住，90% 是缓存没清干净：
composer clear-cache必须执行，Windows 用户还得手动删%LOCALAPPDATA%\Composer\cache
真正难处理的从来不是版本号本身，而是那些藏在 autoload-dev 里的隐式依赖、conflict 字段的全局拦截、以及 repositories 配置对镜像的静默覆盖——这些地方一动，整个依赖图就可能无声崩塌。
