path仓库引发隐性冲突，因Composer默认仅提取其composer.json的name和version字段，忽略require/conflict等约束参与依赖求解；需写死version、用精确版本引用，并删path包内composer.lock后执行composer update --with-dependencies。
直接结论：path 仓库的版本约束冲突，本质是 Composer 把本地路径当成了“可变源”，但没按你预期解析其 composer.json 中的 require 和 conflict 字段——它默认只认 version 字段，且会忽略 dev-main 等分支名的语义。
为什么 path 仓库会引发隐性冲突？
当你在 repositories 里配了 "type": "path"，比如：
"repositories": [
{
"type": "path",
"url": "../my-private-package"
}
]
Composer 不会自动读取该目录下 composer.json 的全部约束逻辑。它只做两件事：
- 把
../my-private-package/composer.json当作元数据源，但仅提取name、version、dist（如果有的话） - 对
require、conflict、replace等字段，**默认不参与依赖求解**，除非你显式启用"options": {"symlink": true}或手动触发重载
结果就是：你本地包明明写了 "conflict": {"guzzlehttp/guzzle": "^8.0"}，但 Composer 安装时完全无视，直到运行时报错才暴露。
composer why-not 对 path 包基本无效
执行 composer why-not myorg/private:1.2.3 很可能返回空，不是没冲突，而是 Composer 没把 path 包的约束纳入 SAT 求解范围。真正起作用的是：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer show myorg/private—— 看它当前被识别出的version是什么（注意：不是你composer.json里写的，而是 Composer 根据目录结构推断的，比如dev-main或1.x-dev） -
composer show --tree | grep myorg/private—— 确认它是否真被拉入依赖树，以及是以什么版本号出现的 -
ls -la ../my-private-package/—— 检查有没有composer.lock或vendor/残留，它们会让 Composer 错误复用旧元数据
怎么让 path 仓库的约束真正生效？
必须显式干预，不能依赖自动发现：
- 在
path包自己的composer.json里，**写死version字段**，例如"version": "1.2.3"（别用dev-main或1.x-dev） - 在主项目的
composer.json的require中，**用完整版本号引用**："myorg/private": "1.2.3"，而不是"^1.2"或"dev-main" - 删掉
path包目录下的composer.lock和vendor/（它们会干扰主项目的解析） - 运行
composer update myorg/private --with-dependencies，强制重算，而非install
否则 Composer 会把 path 包当作“开发快照”，跳过所有版本兼容性校验。
常见踩坑点
这些操作看似微小，但一个不对就会让冲突藏得更深：
-
"repositories": [{"type": "path", "url": "../pkg"}]配置后，又在require里写"myorg/pkg": "dev-main"——dev-main不是版本，是分支别名，Composer 会 fallback 到宽松匹配，绕过你写的conflict - 主项目用了
"minimum-stability": "stable"，但path包没设"stability": "stable"，导致它被降级为dev稳定性，进而忽略所有conflict规则 - 误以为
composer clear-cache能清掉path元数据 —— 实际上path是实时读取文件系统，缓存清理无效，必须手动删目标目录下的composer.lock
最稳妥的做法：把 path 仓库当成“已发布包”来对待——版本号写死、约束写全、不依赖分支别名，否则 Composer 就只把它当软链接，不走任何依赖检查流程。
