Composer报错“Your requirements could not be resolved”本质是SAT求解器严格证明无解，主因是require、require-dev与replace的约束逻辑冲突或平台不兼容；--with-dependencies会强制重协商子树，易加剧收敛失败，require-dev可能通过lock文件或间接依赖泄漏至生产环境，replace仅屏蔽安装需求而不解决运行时类冲突。
复杂项目里 Composer 报错“Your requirements could not be resolved”，不是版本写错了，而是约束逻辑没对齐——得从依赖解析器的视角重新看 require、require-dev 和 replace 的实际作用边界。
composer update --with-dependencies 为什么有时反而加剧冲突
这个参数本意是“更新目标包时，连带更新它直接依赖的包”，但容易被误用为“一键解决所有冲突”的银弹。实际上，它会强制触发整个子树的版本重协商，而 Composer 的求解器在面对多个宽松约束（比如一堆 ^2.0）时，可能收敛到一个局部最优但全局不兼容的组合。
- 只在明确知道某包的某个子依赖是冲突源头时才用，例如
composer update monolog/monolog --with-dependencies - 执行前先跑
composer depends psr/log --tree，确认该包是否真被多个路径引用 - 如果
--with-dependencies后仍失败，说明问题不在子依赖层级，而在顶层约束或平台要求（如 PHP 版本、扩展缺失）
require-dev 依赖泄漏进生产环境的隐蔽路径
require-dev 看似只影响本地开发，但在以下场景会意外进入生产依赖树：
- 你运行了
composer install而没加--no-dev，且composer.lock是由含require-dev的机器生成的——lock 文件会记录全部包，包括 dev 包 - 某个
require包的composer.json里错误地把测试工具写进了自己的require（而非require-dev），你的项目就间接引入了它 -
autoload-dev中定义的类被生产代码意外引用，导致vendor/autoload.php加载时失败
验证方法：部署前执行 composer install --no-dev --dry-run，看是否报错；再检查 composer.lock 中 packages-dev 字段是否为空。
replace 字段的真实行为：它不删除包，只屏蔽声明
"replace": { "old/package": "*" } 不会让 Composer 卸载 old/package，而是告诉求解器：“当其他包 require old/package 时，可以视作已满足，无需再安装”。但它不处理运行时类名冲突。
- 若你 fork 了
old/package并改名为your-vendor/package，必须确保新包的autoload规则覆盖原包的命名空间，否则class not found仍会发生 -
replace对conflict字段无效——如果原包声明了"conflict": { "php": "，你的替换包仍需自行声明兼容性 - 多个
replace声明同一包时，Composer 会选择最先加载的（按repositories顺序），这点常被忽略
依赖树可视化中容易误读的关键节点
composer show --tree 输出里，缩进相同层级的包不一定同级依赖——它只反映安装顺序，不反映约束强度。真正关键的是带 (required by ...) 标注的行。
- 看到
symfony/console v5.4.33 (required by myapp/core)和symfony/console v6.2.12 (required by laravel/framework)并列，说明冲突已发生，求解器没妥协，而是卡住了 -
composer why-not symfony/console:^6.0比单纯看树更有用，它会列出所有阻止升级的直接和间接原因 - 树中出现
[dev-main]或[dev-develop]分支，意味着你用了 VCS 仓库且未打 tag，这会导致版本解析不稳定，应避免在生产环境中使用
最常被跳过的动作：在修改 composer.json 后，不运行 composer validate 就直接 update。很多诡异冲突其实源于 JSON 格式错误、字段拼写错误（比如把 require 写成 requre）或版本约束语法非法（如 ~1.2.3.4）。这些不会报错，但会让求解器静默降级策略，最终给出不可预测的结果。
