composer依赖冲突本质是约束求解失败，需用composer why-not定位根本原因，结合packagist查兼容版本、合理收放约束、定点升级加--with-dependencies，并警惕conflict/replace的全局硬性作用。
Composer 依赖冲突不是“注入”出来的，也没有框架自动注入这回事——它只是约束求解失败的自然结果。只要你没手动改 composer.lock 或硬塞不兼容的版本号，就不存在“注入冲突”，只有“约束无交集”。
composer why-not 是你第一个该敲的命令
报错里只写 Conclusion: don't install monolog/monolog:3.0.0，但没说谁拦着。这时候别猜，直接运行：
composer why-not monolog/monolog:3.0.0
它会逐级列出所有已安装包中，哪些版本显式或隐式锁死了这个包的可用范围。比如输出：
laravel/framework v10.30.0 requires psr/log ^2.0<br>myapp/utils v2.1 requires psr/log ^3.0
这就清楚表明：Laravel 10 和你的私有工具包对 psr/log 的要求根本没法共存。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 如果输出里出现
dev-main或dev-develop，检查是否漏配了"minimum-stability": "dev" -
why-not不会显示被replace或conflict干预过的包，得额外跑composer show -t看完整树 - 别跳过这步直接删
composer.lock——你可能掩盖了真实依赖链，而不是解决问题
改 composer.json 前先确认版本交集是否存在
盲目把 "monolog/monolog": "^1.25" 改成 "^1.25 || ^2.10" 没用，除非你代码真能兼容两个主版本。更务实的做法是：
- 去 Packagist 查哪个小版本被上下游同时接受（比如
v2.9.3可能既满足 A 的^2.0，又满足 B 的~2.9） - 收紧过宽约束：把
"guzzlehttp/guzzle": "*"锁到已验证稳定的"7.8.1"，避免引入破坏性变更 - 放宽过严约束：把
"aws/aws-sdk-php": "3.240.0"改成"^3.240"，给 Composer 留出调整空间
定点升级必须加 --with-dependencies
想升 monolog/monolog 到 3.0.0，但直接跑 composer update monolog/monolog 常失败——因为 Composer 默认不更新它的子依赖，而 monolog 3.0 可能要求 php >=8.1 或 psr/log ^3.0，这些旧版本还卡在 composer.lock 里。
- 必须加
--with-dependencies：它会让 Composer 同时考虑并升级该包所需的最小依赖集 - 别写
composer update "monolog/monolog:^3"——引号 +^会让 Composer 自行找最新兼容版，不是你要的精确版本 - 升级后立刻
git diff composer.lock，确认只有预期的包和其直系依赖被改动
conflict 和 replace 不是提示，是硬性规则
conflict 字段让 Composer 主动拒绝安装某组合，replace 则让 Composer 把一个包当另一个包的“替身”来处理。它们都全局生效，哪怕你没 require 那个包，只要其他已装包间接拉进来，就会触发。
- 常见错误：自己写的私有包加了
"conflict": {"laravel/framework": ">=11.0"}，但项目里没装 L11，却仍报冲突——原因就是 conflict 全局生效 -
replace后必须确保被替代项真能被完全覆盖，否则运行时出错。比如用mockery/mockery替换phpunit/phpunit的 mock 功能？不行，PHPUnit 的内部调用路径根本绕不开自己的实现 - 别用
conflict来“提醒用户注意版本”，那该用require或文档
最常被忽略的是：Composer 解析依赖时用的是 SAT 求解器，一旦项目里有 conflict、replace 或 30+ 包，复杂度指数上升；卡在 Resolving dependencies 超过 5 分钟，大概率不是网络慢，而是求解器在暴力试错。
