composer依赖冲突是多包对同一依赖提出互斥版本要求后解析器必然拒绝的结果；需从composer why-not输出最后一行（根依赖）倒推拒绝链，重点识别conflict声明、require-dev影响及^/~约束差异。
Composer 依赖树冲突不是配置写错了，是多个包对同一依赖提出互斥版本要求后，解析器明确拒绝的必然结果——它不报错才反常。
composer why-not 输出怎么看
它输出的是「拒绝理由链」，不是因果图。每行末尾的 (required by ) 是向上追溯的起点，必须从最后一行倒着读：最后一行才是你的 composer.json 根声明，往上才是层层卡住的包。
常见误判：
- 看到某行写
conflict with foo/bar (>=2.0)，就以为foo/bar在作怪——其实那是它自己声明的conflict规则，Composer 只是照章执行 - 看到
phpunit/phpunit出现在链里，就去卸载它——实际上它可能是被orchestra/testbench拉入，而后者又硬绑了laravel/framework:^9.0，那才是真源头
实操建议：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先确认目标版本是否真被需要：
composer why-not guzzlehttp/guzzle:^8.0，再对比composer show guzzlehttp/guzzle看当前装的是哪个版本 - 若某行显示
laravel/framework v10.32.0 → requires symfony/console ^6.4，另一行是package-x v2.1 → requires symfony/console ^5.4，冲突点就在symfony/console，不是 Guzzle 本身
composer show --tree 怎么查真实依赖路径
它比报错信息更直观，能暴露隐藏的间接依赖链。重点看三点：
- 同名包是否在不同路径下被引入多个版本（如
symfony/console同时出现在laravel/framework和phpunit/phpunit下） - 冲突包是否来自
require-dev——它默认参与解析，哪怕你部署时加了--no-dev - 有没有包用
replace声明替代了某个依赖（如symfony/polyfill-mbstring替代ext-mbstring），但实际运行时没装扩展，导致假性通过
实操建议：
- 树太深时配合
grep：composer show --tree monolog/monolog | grep -A5 -B5 "symfony/.*console" - 输出中某行末尾带
(locked to X.Y.Z)，说明这个版本已在composer.lock固定；删 lock 文件再composer update才可能松动
为什么 composer update 不升级某些包
Composer 默认采用「最小变更」策略：只要已安装版本满足 composer.json 的约束（比如 "monolog/monolog": "^2.8"），就不会主动升级到 2.9 或 2.10，哪怕它们更稳定、有安全修复。
实操建议：
- 想强制升级某个包到最新兼容版？用
composer update vendor/name，不要加--with-dependencies，避免意外连带升级其他包 - 想升级整个依赖树到每个包的最新小版本（如
2.x → 2.latest）？用composer update --minor-only（Composer 2.5+ 支持）；旧版本只能靠composer update+ 手动指定 - 注意
^1.2.3和~1.2.3的差异：^允许1.x内任意小/补丁升级，~只允许1.2.x补丁级升级；写宽松前先查对方是否真做语义化发布
require-dev 怎么把生产环境拖下水
require-dev 默认也会参与依赖解析，尤其当你运行 composer update 无参数时——它会同时满足 require 和 require-dev，哪怕最终部署时用 --no-dev。
某些 dev-only 包（如 phpunit/phpunit）如果和主框架有重叠依赖（比如都依赖 sebastian/exporter），它们的版本要求会反向约束主流程。
实操建议：
- CI/CD 中务必用
composer install --no-dev --optimize-autoloader，否则测试工具可能意外影响主依赖选择 - 若发现某个 dev 包持续引发冲突，考虑移入
config.platform做虚拟约束，例如：{"config": {"platform": {"phpunit/phpunit":"9.6.13"}}}，让它不参与真实安装，只提供版本锚点 - 检查
composer.json中是否写了过于宽松（如*）或过于陈旧（如^1.0）的约束——这些最容易在 dev 包介入后引爆冲突
真正难解的冲突，往往藏在 require-dev 与 config.platform 的交互细节里，而不是根依赖那一行显眼的 ^ 符号上。
