Composer依赖冲突是多个包对同一依赖提出互斥版本要求导致解析器穷举失败的明确拒绝，需用composer why-not向上追溯阻断链、show --tree查真实路径、update --with-dependencies定点升级，并通过config.platform锚定目标环境版本。
Composer 依赖冲突不是配置错误，而是多个包对同一依赖提出互斥版本要求后，解析器穷举失败的明确拒绝信号——它不报错才反常。
composer why-not vendor/package:version 看清谁在联合封杀
报错只说“无法解析”，但真正卡住你的往往不是目标包本身，而是某个上游依赖把它死锁在旧版。比如 composer why-not monolog/monolog:^2.9 输出：
laravel/framework v10.30.0 requires monolog/monolog ^1.25myapp/utils v2.1 requires monolog/monolog ^1.25
最后一行才是你的根 composer.json，往上读才能定位“谁先动的手”。注意：每行末尾的 (required by ...) 是向上追溯起点，不是因果终点。
常见误判：看到 phpunit/phpunit 出现在阻断链里，就以为是测试工具惹的祸——其实它只是被 orchestra/testbench 拉进来，而后者又硬绑了 laravel/framework:^9.0，这才是真源头。
composer show --tree | grep package 查真实依赖路径
composer show --tree 展开整棵树，比报错信息更直观。重点看三点：
- 同名包是否在不同路径下被引入多个版本（如
symfony/console同时出现在laravel/framework和phpunit/phpunit下） - 冲突包是否来自
require-dev—— 它默认参与解析，哪怕你部署时加了--no-dev - 有没有包用
replace声明替代了某个依赖（如symfony/polyfill-mbstring替代ext-mbstring），但实际运行时没装扩展，导致假性通过
如果发现 guzzlehttp/guzzle 被 firebase/php-jwt 和 spatie/laravel-backup 分别拉入 ^7.0 和 ^8.0，说明问题不在 Guzzle 本身，而在那两个包的版本兼容性。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer update vendor/package --with-dependencies 定点升级不牵连
盲目 composer update 会触发全量重算，SAT 求解器可能卡住 5 分钟以上；删 composer.lock 更是掩盖问题。正确做法是缩小作用域：
- 先锁定冲突包，例如
monolog/monolog - 查 Packagist，找一个同时被上下游接受的中间版本（如
v2.9.3既满足^2.0又满足>=2.8.0） - 执行
composer update monolog/monolog --with-dependencies，让 Composer 同时考虑它的直接依赖 - 若仍失败，加
--dry-run -v看日志里反复回退的节点，那里就是约束最紧的瓶颈
注意：--with-dependencies 不等于全量更新，它只放开当前包及其子依赖的版本选择空间，其他路径保持锁定。
config.platform 防止本地环境干扰解析
你在 PHP 8.1 本地开发，但 CI/CD 跑在 PHP 8.2 上？composer update 可能因平台差异报错，比如提示 require php ^8.2。这时别改代码，用 config.platform 做虚拟锚点：
"config": {
"platform": {
"php": "8.2.0"
}
}
它让 Composer 忽略你本地的 PHP 版本，按目标环境解析依赖。同样适用于扩展缺失（如 ext-redis）——只要生产环境有，就配 "ext-redis": "*" ，避免本地开发时被拦。
真正难处理的，是那些没写清楚 conflict 或 provide 的私有包：它们不报错，但会在运行时炸开。这类包一旦混进依赖树，就得靠 composer prohibits 和 composer depends 反复交叉验证，而不是指望一次 update 解决。
