执行 composer update --dry-run -v 查看详细回溯链，重点关注末尾「Conclusion」段，它会明确指出哪个包在哪个版本被强制排除，从而精准定位冲突源头。
composer install 时提示 “Your requirements could not be resolved” 怎么快速定位冲突点
这个报错不是 Composer 在甩锅，而是它已经算完了所有可能的版本组合，发现没有一条路径能同时满足你 composer.json 里写的约束、所有 require 的包及其子依赖的约束。关键不在“不能装”，而在“哪一层卡住了”。
执行 composer update --dry-run -v，加 -v（verbose）才能看到真实回溯链。注意输出末尾的「Conclusion」段——那里会指出具体哪个包在哪个版本被强制排除，比如：Root composer.json requires package-a ^2.0, but package-b v1.5.0 requires package-a 1.2.0 -> satisfiable by package-a[1.2.0].
- 别直接改
composer.lock手动删行，那只是掩耳盗铃，下次composer update还会崩 - 如果项目已上线，优先用
composer install而非update，避免触发新解题逻辑 -
composer prohibits vendor/package version是个冷门但极有用的命令，可直接查某个版本被谁拦了
require-dev 里的包意外污染生产依赖链
很多人以为 require-dev 只影响本地开发，但只要某个 dev 包在 require 中也存在（哪怕版本不同），Composer 就必须把两条链一起解出来。更隐蔽的是：某个 dev 包的子依赖，可能和线上包有不兼容的传递依赖。
典型现象是：删掉 phpunit 后 composer update 突然成功了。这不是巧合，是因为 phpunit 依赖了老版 sebastian/exporter，而你的主业务包需要新版 symfony/console，后者又要求 sebastian/exporter ≥4.0。
- 运行
composer show --tree vendor/package查看某包的完整依赖树，重点扫require-dev引入的分支 - 对纯测试工具类包（如
phpunit,mockery），加"minimum-stability": "stable"和"prefer-stable": true，避免拉到 alpha 版本搅乱主链 - CI 环境中用
composer install --no-dev，但本地调试时要保留--with-all-dependencies来暴露隐藏冲突
使用 replace 或 provide 人为干预依赖解析
当两个包提供相同功能（比如都实现了 PSR-18 HTTP client 接口），但版本约束互斥时，replace 是少有的合法“绕过”手段。它不是欺骗 Composer，而是告诉它：“这个包的存在，等价于另一个包的某些能力已就绪”。
例如你用了轻量 guzzlehttp/psr7，但某个库硬依赖 nyholm/psr7，而两者都符合 PSR-7。可以在 composer.json 中写：
"replace": {
"nyholm/psr7": "self.version"
}，前提是你的代码确实做了适配层。
-
replace不会自动安装被替代的包，你要确保运行时环境真有对应实现 -
provide更安全，用于声明“我实现了某虚拟包”，比如"provide": {"psr/http-client-implementation": "1.0"} - 滥用
replace会导致composer outdated失效，因为被替换的包不会出现在依赖图里
锁定次要版本却忽略 patch 兼容性断裂
写 "monolog/monolog": "^2.8" 看似稳妥，但 Monolog 2.9.0 曾移除一个被广泛使用的内部方法 Monolog\Handler\StreamHandler::setFilename()，而没走 BC-break 流程。这种 patch 级别变更，Composer 照样允许升级，结果运行时报 Call to undefined method。
根本原因在于语义化版本（SemVer）只保证 MAJOR.MINOR 级别的兼容性承诺，patch（第三位）理论上可含修复、微调甚至……不严谨的破坏。Composer 完全信任包作者的版本标注。
- 对核心基础设施类包（
symfony/*,laravel/framework,doctrine/*），显式锁死到2.8.12比用^2.8更可控 - 用
composer why-not vendor/package version快速确认某 patch 版本是否被其他依赖间接拒绝 - 每天 CI 中跑
composer update --dry-run并存档输出，比等到上线前才发现强得多
递归冲突从来不是配置写错了，而是你没看见某条依赖路径上，有人悄悄改了契约。越想靠一行 ^ 符号省事，越容易在第 7 层子依赖里栽跟头。
