Composer依赖冲突是语义版本约束博弈的必然结果，典型“树顶冲突”源于根依赖与composer.lock或已装包不匹配；应优先用--dry-run预演、按lock安装，精准更新单个包，并注意^与~差异。
Composer 依赖冲突不是配置问题，是语义版本约束在真实项目中必然发生的博弈结果——它不报错才奇怪。
composer install 报 Root composer.json requires ... but ... is installed
这是最典型的“树顶冲突”：你声明的根依赖和已锁版本（composer.lock）或当前已装包不匹配。常见于团队协作后拉了新代码但没更新 lock 文件，或手动改过 composer.json 却跳过了 composer update。
- 先运行
composer install --dry-run看预演冲突点，别急着删 lock - 如果只是本地开发环境不一致，优先执行
composer install（它严格按 lock 安装），而不是composer update - 若确定要升级，用
composer update vendor/package-name精准更新单个包，避免全量重算导致意外降级 - 注意
^1.2.3和~1.2.3的差异：^允许1.x内任意小版本，~只允许1.2.x；写宽松约束前先查对方是否真做语义化发布
composer why-not vendor/package:version 显示一堆嵌套依赖
这个命令不是告诉你“谁在拦你”，而是列出所有阻止该版本被选中的直接/间接依赖路径。它输出的是“拒绝理由链”，不是因果图。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 每一行末尾的
(required by ...)是向上追溯的起点，从底往上读才对——最后一行才是你的根composer.json - 如果某行显示
conflict with foo/bar (>=2.0)，说明那个包自己声明了冲突规则，不是 Composer 胡乱拦截 - 别指望靠
why-not直接定位到“哪个包该降级”，它只反映约束快照；真正要解，得结合composer depends vendor/package找出谁在引用旧版
require-dev 里的包把生产环境拖下水
require-dev 默认也会参与依赖解析，尤其当你运行 composer update 无参数时——它会同时满足 require 和 require-dev，哪怕最终部署时用 --no-dev。
- CI/CD 中务必用
composer install --no-dev --optimize-autoloader，否则测试工具可能意外影响主依赖选择 - 某些 dev-only 包（如
phpunit/phpunit）如果和主框架有重叠依赖（比如都依赖sebastian/exporter），它们的版本要求会反向约束主流程 - 若发现某个 dev 包持续引发冲突，考虑移入
config.platform做虚拟约束，例如：{"config": {"platform": {"phpunit/phpunit": "9.6.13"}}}，让它不参与真实安装，只提供版本锚点
composer update --with-all-dependencies 还是解不开
这个选项会让 Composer 尝试升级整个子树（不只是直系），但它不会违背任何 conflict 或硬性 require 规则。所谓“解不开”，往往是两个包之间存在无法调和的底层约束，比如一个要 guzzlehttp/guzzle ^7.0，另一个死锁在 ^6.5 且没提供替代实现。
- 先用
composer prohibits guzzlehttp/guzzle:7.*查谁在明确反对 7.x - 检查是否用了
minimum-stability: dev或prefer-stable: false，这会让 Composer 倾向选不稳定版本，反而放大冲突概率 - 极端情况下，用
composer show --tree导出完整依赖树，人工找“分叉点”：即同一个包在不同路径被要求不同主版本（如symfony/console在 A 路径要 v5，在 B 路径要 v6），这才是真正的死结
依赖树不是静态结构图，它是每次 composer update 时根据当前所有 composer.json + lock + 平台配置实时推演出来的博弈解。没有“一劳永逸”的解决法，只有更清楚谁在提要求、谁在设底线。
