最有效的是写死版本号、禁用模糊约束、主动声明conflict；模糊约束如^2.0易致范围不重叠，conflict是硬性拦截而非提示，require-dev中非必要测试依赖会加剧解析难度。
直接写死版本号、禁用模糊约束、主动声明冲突，是减少 Composer 依赖冲突最有效的三件事。其他技巧效果有限，甚至可能掩盖问题。
用精确版本号替代 ^ 或 ~ 约束
模糊版本约束（如 ^2.0、~1.2.3）会让 Composer 在每次 update 时自由选择满足范围的最新小版本，而不同包对同一依赖的模糊范围可能在某次更新后突然不重叠——这是多数“莫名冲突”的源头。
实操建议：
- 生产项目中，把
"monolog/monolog": "^2.9"改成"monolog/monolog": "2.9.1"； - 只在明确需要自动升级的场景（如 CI 测试最新兼容性）才保留
^，且应配合--dry-run验证； - 避免
*和dev-master，它们会让依赖解析完全失控。
在 conflict 字段中主动拦截已知不兼容组合
conflict 不是“提示”，而是硬性拦截开关。它让 Composer 在解析早期就拒绝掉根本不可能共存的组合，而不是等到 SAT 求解失败后才报错。
实操建议：
- 如果你的扩展包只适配
guzzlehttp/guzzle6.x，就在composer.json中写："conflict": { "guzzlehttp/guzzle": "^7.0" }； - 排除已知有安全漏洞或运行时互斥的版本，例如：
"conflict": { "phpunit/phpunit": "=10.0" }； - 注意：
conflict全局生效，哪怕你没require它，只要某个间接依赖拉进了被冲突的包，就会立即中断安装。
删除 require-dev 中的非必要测试依赖
开发依赖（require-dev）常引入大量工具链包（如 phpunit、phpstan、mockery），它们之间版本约束复杂，且与生产代码无直接关系——但会显著增加 SAT 求解难度，拖慢 update，并制造本可避免的冲突。
实操建议：
- 用
composer show --tree查看require-dev是否意外拉入了生产级包（比如laravel/framework）； - 把仅用于本地脚本的工具移到
scripts+composer bin或独立容器中，而非塞进require-dev； - CI 环境中显式使用
composer install --no-dev，避免因require-dev导致的解析失败影响部署。
真正难解的冲突，往往不是版本号没对齐，而是多个包在底层共享同一类名、全局函数或扩展行为。这时候 conflict 和精确版本只是表层控制，得靠 replace 或重构隔离——但那是另一层问题了。
