定位 path 依赖冲突需先运行 composer update --dry-run -v 查看 SAT 解析日志，再逐个检查各 path 包的 composer.json 中 require/conflict 字段，临时注释仓库配置缩小范围，并用 composer update --lock --no-install 后 composer show -t 验证依赖树。
composer install 时提示 “could not resolve packages” 怎么定位 path 依赖冲突
Composer 的 path 仓库类型（本地路径映射）不走语义化版本解析，而是直接软链接或硬拷贝，但它的 require 声明仍参与全局依赖图计算。一旦多个 path 包声明了互斥的同一包版本（比如 A 要 "monolog/monolog": "^2.0"，B 要 "monolog/monolog": "^3.0"），composer install 就会卡在依赖解析阶段，报错类似 Root composer.json requires monolog/monolog ^2.0 and ^3.0 -> found monolog/monolog[2.0.0, ..., 2.10.0] but it does not match the constraint.
真正的问题往往不是版本写错，而是你没意识到某个 path 包的 composer.json 里写了隐式约束 —— 比如它自己 require 了某个包的特定范围，而这个范围和另一个 path 包或主项目冲突。
- 先运行
composer update --dry-run -v，加-v看详细解析日志，关键线索藏在 “Resolving dependencies through SAT” 后面的冲突行 - 检查所有
path包根目录下的composer.json，重点看require和conflict字段，不要只盯着主项目的composer.json - 临时注释掉部分
path仓库配置（在主composer.json的repositories里），逐个启用，缩小冲突范围
用 composer show -t 查看 path 包的真实依赖树
composer show -t 默认只显示已安装包的树，对未安装的 path 依赖无效；但如果你已经成功 install 过一次（哪怕失败后残留了 vendor），就可以用它验证当前解析结果是否合理。
更可靠的做法是：确保所有 path 包的 composer.json 都已提交（尤其是 version 字段），然后运行：
composer update --lock --no-install
这会强制重新计算锁文件但不写入 vendor，之后再执行 composer show -t <package-name></package-name> 就能看清该 path 包被解析成哪个版本、它拉进来的子依赖是否与其它 path 包重叠。
- 注意：
path包若没设"version"，Composer 会默认用dev-main或dev-master，这可能导致意外匹配到其它分支约束 - 如果某个
path包依赖了"php": ">=8.1"，而主项目是 PHP 8.0，冲突不会直接报“版本不兼容”，而是表现为“无法找到满足条件的版本”
为什么 composer why-not 不总能查出 path 冲突
composer why-not 是基于已解析成功的依赖图反查，而 path 冲突常常导致整个图无法构建，所以命令直接报错退出，或者返回空结果。
这时候得换思路：把冲突目标当成“假设已安装”，手动构造最小验证场景。
- 新建一个空目录，仅放主项目的
composer.json，删掉所有非必要的repositories，只保留一个path仓库，运行composer require安装它 - 再逐步添加第二个
path仓库，每次跑composer update --dry-run，观察第一次失败的位置 - 如果两个
path包都 require 同一包但版本不交集，错误信息里会出现类似... has requirements incompatible with your constraint...，这时要对比它们各自的composer.json中该包的约束字符串
避免 path 冲突的三个实操习惯
很多冲突其实源于开发流程松散，而不是 Composer 本身难用。
- 所有
path包必须显式声明"version"（如"dev-feat/auth"），禁止依赖默认分支推断；否则不同人本地 checkout 分支不同，composer.lock就会不一致 - 主项目中对
path包的require版本建议用"dev-main as 1.0.0"这种 alias 写法，既锁定路径又明确语义版本，方便其它包引用时做兼容判断 - CI 流程里加一步：
composer validate --strict+composer update --dry-run，提前拦截本地能过但 CI 失败的路径冲突
最麻烦的情况是：某个 path 包自己又依赖另一个 path 包，形成嵌套。这时候必须确保所有中间层的 composer.json 里，对下游 path 的 require 版本和实际路径配置完全对应，少一个字母都会让 Composer 认为那是两个不同包。
