composer why-not 能直接定位阻塞依赖，需带完整版本号（如 guzzlehttp/guzzle:^8.0.0），输出为从底向上的反向链，最后一行是根声明，逐行向上找 required by 的互斥约束即冲突源头。
composer why-not 能直接定位谁在拦路
报错里出现 don’t install xxx 别猜，用 composer why-not 查阻塞链。命令必须带完整版本号，比如 composer why-not guzzlehttp/guzzle:^8.0.0，输出是从底往上读的反向链：最后一行是你 composer.json 的根声明，往上逐行看哪条 required by 提出了互斥约束——那就是冲突源头。
常见误判点：
- 输出为空？先检查
require-dev——很多冲突来自phpunit/phpunit或mockery/mockery拖着老版sebastian/exporter，间接锁死symfony/console - 写
^8可能匹配不到元数据，必须写guzzlehttp/guzzle:^8.0.0或guzzlehttp/guzzle:8.0.0 - 加
--dry-run验证改动是否真能解出路径，例如composer require laravel/framework:11.0.0 --dry-run，不改任何文件就提前看到结果
composer show --tree 揭露真实依赖结构
composer.json 是你写的“愿望清单”，composer show --tree 才是 vendor/ 和 composer.lock 里的真实快照。它能暴露你根本没意识到的间接路径，比如某个包标着 (locked to 5.4.42) 或 (replaced)。
实操建议：
- 查某个包被谁引入：
composer show --tree | grep "symfony/console" - 过滤关键段：
composer show --tree monolog/monolog | grep -A5 -B5 "guzzlehttp/guzzle" - 看到
(provided)或(replaced)，得去那个包自己的composer.json里确认它到底替代了什么、是否真能覆盖
定点更新必须带 --with-dependencies
全量 composer update 容易触发 SAT 求解器卡死，尤其依赖多的项目。升级单个包必须带 --with-dependencies，否则 Composer 默认拒绝更新其子依赖，哪怕新版本根本跑不起来。
正确写法：composer update monolog/monolog --with-dependencies —— 只动它和直系依赖
错误写法：composer update "monolog/monolog:^3" —— 引号 + ^ 会让 Composer 自己找“最新兼容版”，不是你要的 3.0.0
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
降级跨主版本（如从 guzzlehttp/guzzle:^8.0 切回 7.4.5），必须在 composer.json 里写死："guzzlehttp/guzzle": "7.4.5"，不能只写 "^7.0"
执行后立刻 git diff composer.lock，确认只有目标包及其直系依赖被改，没波及其他
私有仓库配置不当会隐性屏蔽 Packagist
Composer 2.x 默认启用 canonical 模式：一旦在某个仓库（比如你配的私有源）找到包名匹配项，就完全跳过后续所有仓库，包括 Packagist。如果私有仓库返回的包信息里没有满足你版本约束的版本，Composer 不会“退而求其次”去 Packagist 找，而是直接报错或装一个低版本——这容易被误认为是“冲突”，其实是查找链提前中断。
验证方法：
- 运行
composer show vendor/package-name，看输出里的source字段指向哪个仓库 - 再用
composer repo:list确认仓库声明顺序 - 若私有仓库只托管部分包，必须显式设
"canonical": false，否则它“挡”住了 Packagist
错误写法："repositories": [{"type": "composer", "url": "https://my-priv.repo"}] → 默认 canonical: true，哪怕你的私有源只提供 myorg/utils，它也会阻断 monolog/monolog 去 Packagist 查找
正确写法："repositories": [{"type": "composer", "url": "https://my-priv.repo", "canonical": false}] → 私有源查不到时，自动继续查 Packagist
复杂点在于：冲突往往不是单一原因，而是平台要求、私有源优先级、conflict 字段、锁文件残留四者叠加。最容易被忽略的是 require-dev 里的间接约束，以及 composer.json 中写了 repositories 字段却忘了关 canonical —— 这两者不会报错，但会让 Composer 在你完全没察觉的情况下绕过本该可用的版本。
