软关联问题本质是replace或conflict字段隐式改写依赖规则，导致Composer无声封杀版本；需用composer show、prohibits和--dry-run三步定位，而非仅看报错。
软关联问题不是版本号写错了，而是某个包通过 replace 或 conflict 字段悄悄改写了依赖规则，导致 Composer 在你没察觉时就封杀了目标版本。
为什么 replace 会引发“看不见”的冲突
当一个包在 composer.json 中声明 "replace": {"ext-mbstring": "*"}（如 symfony/polyfill-mbstring），它不是“提供功能”，而是告诉 Composer：“只要装了我，就等于满足了对 ext-mbstring 的所有 require”。但如果你项目里同时 require 了另一个也声明 replace 同一扩展的包，或者某包用 conflict 明确排斥该 polyfill，Composer 就会拒绝共存——而报错里根本不会提 replace 这个词。
- 运行
composer show vendor/package，重点看输出里的replaces和conflicts字段，不是只扫require - 检查私有包或测试工具（如
orchestra/testbench）是否在replace里覆盖了核心扩展，却没真正实现全部 API -
replace是硬性替换，不是可选兼容层；一旦启用，Composer 就不会再检查被替代项是否存在或是否启用
conflict 字段的全局生效特性常被误用
conflict 不是注释，也不只作用于直接 require 的包。只要任何已安装的包（哪怕是间接拉进来的 dev 依赖）触发了 conflict 规则，整个 install/update 就会失败。比如你在私有组件里写了 "conflict": {"laravel/framework": ">=11.0"}，即使主项目还没升级 Laravel，只要 phpunit/phpunit 某个子依赖偷偷拉进了 laravel/pint v1.12（它 require laravel/framework:^11.0），冲突就立刻爆发。
- 用
composer prohibits vendor/package:version查谁在主动封杀，比why-not更贴近conflict场景 - 临时诊断可注释掉
conflict块再composer update --dry-run，确认是否真由它导致 - 别用
conflict做版本提醒——那是文档和 CI 的事；它只该用于强互斥（如两个包提供完全相同命名空间且无法共存）
dev 依赖如何通过软关联污染生产环境
require-dev 里的包虽然不进生产 autoload，但它们的 replace/conflict 依然参与依赖求解。典型例子：mockery/mockery v1.6.x 曾 replace phpunit/phpunit 的 mock 功能，结果卡死 sebastian/exporter 的升级路径，间接锁死 symfony/console —— 而你的 composer.json 根本没写一行关于 console 的 require。
- 运行
composer show --tree | grep -E "(replace|conflict)"，快速筛出所有软关联声明 - 执行
composer update --dry-run --with-dependencies phpunit/phpunit，观察是否因 dev 包的软规则被拒 - 升级前先清理 dev 依赖：用
composer remove --dev package/name临时移除可疑包，再重试
软关联的问题不在版本数字本身，而在语义层面的隐式契约。它让依赖图不再是“谁 require 谁”的线性关系，而变成一张带条件跳转的逻辑网——查 show、prohibits、--dry-run 这三步，比盯着报错末尾的 don't install 有用得多。
