Composer没有aliases机制解决依赖冲突，所谓“alias”实为replace/provide声明或框架自定义类名别名，不参与依赖解析；replace是硬性替代，不消除冲突反而可能掩盖问题；定位冲突应使用composer why-not，临时干预仅限--with-dependencies或--with-all-dependencies。
Composer 没有 aliases 机制来“解决”依赖冲突——这是个常见误解。所谓 “Composer aliases”，实际指的只是 composer.json 中 "replace" 字段或 "provide" 字段的声明行为，或者某些框架（如旧版 ThinkPHP）自定义的类名别名（alias），它们**不参与依赖解析过程，也不影响版本约束求解**。
为什么 replace 不是“绕过冲突”的开关
"replace" 是硬性替代规则：它告诉 Composer “当这个包被安装时，等价于已满足对另一些包的依赖”。但它不会让冲突消失，反而可能掩盖真实问题：
- 如果
package-a在"replace": {"monolog/monolog": "1.25.0"}，而你的项目 require^2.0，Composer 仍会报错——因为replace不等于“我装了 monolog/monolog ^2.0”，它只表示“我假装提供了 1.25.0 的契约” - 运行时若代码真调用了
Monolog\Logger::withContext()（v2 新增方法），但你用replace强行塞进 v1 实现，就会直接 fatal error -
replace声明一旦写入composer.json，所有依赖它的包都会信任该声明，后续composer update可能跳过真正需要的包，导致 autoload 失败或功能缺失
composer why-not 才是定位冲突的起点
依赖冲突不是靠“ alias ”或“替换”糊弄过去的，而是必须显性识别阻断链：
- 运行
composer why-not vendor/package:desired-version（例如composer why-not monolog/monolog:2.9.0），输出里每一行都代表一个正在封杀该版本的包及其约束 - 注意看输出中是否包含
require-dev下的包——比如phpunit/phpunit拉来了sebastian/exporter，而后者又硬依赖phpunit/php-code-coverage的某个旧版，间接锁死symfony/yaml - 不要只信报错里的 “Root package requires…”，要查
composer show -t | grep package-name看实际依赖树中哪个路径在压低版本
真正可行的临时干预方式只有两种
想“临时”推进开发，不是加 alias，而是控制依赖图的生成逻辑：
- 用
composer require vendor/package:new-version --with-all-dependencies：强制 Composer 重算整棵树，升级/降级已有包来腾出空间。适合你确认新包可信、且愿意接受关联变更 - 用
composer update vendor/package --with-dependencies：比全量更新更收敛，只动目标包及其子依赖，避免波及无关模块。例如composer update guzzlehttp/guzzle --with-dependencies - 若仅需测试兼容性，加
--dry-run -v先看日志里是否出现Trying+ 回退循环——那是 SAT 求解器在暴力试探，说明约束交集极窄，此时硬上replace只会让问题延后到运行时
把 replace 当作“别名”来用，等于把依赖解析权交给手动猜测。真正的临时方案，是让 Composer 显式告诉你哪里卡住了，然后用 --with-dependencies 或 --with-all-dependencies 控制重算范围——其它都是掩耳盗铃。
