Composer path仓库配置后代码“冲突”实为协作错位：本地包未启用符号链接、Git未初始化或name不一致导致修改不生效，而非Git层真冲突。
本地包用 path 仓库配置后，代码冲突基本只发生在 Git 层，Composer 本身不参与、也不解决这类冲突——它只管按路径把代码链进去。真正要防的是“改了本地包却没生效”“多个项目同时改同一份源码却互不知情”这类协作错位。
为什么 path 配置容易引发“伪冲突”
所谓“代码冲突”，90% 不是 Composer 报错，而是你改了本地包的 src/Helper.php，主项目里 new Helper() 却还是旧逻辑。常见原因有：
-
vendor/acme/utils实际是复制（copy）而非符号链接（symlink），改源码不生效 - 本地包目录没执行过
git init && git commit，Composer 拒绝 symlink，静默 fallback 到 dist 模式 - 主项目
composer.json里写了"config": {"symlinks": false}，全局关掉了软链 - Windows 下没以管理员身份运行终端，或未开启“开发者模式”，导致 symlink 创建失败
确保 symlink 生效的实操检查项
别猜，直接验证：
- macOS/Linux 下运行：
ls -l vendor/acme/utils，看到-> ../acme-utils才对；若显示普通目录，说明 fallback 了 - Windows 下运行：
dir vendor\acme-utils，输出含 - 本地包根目录必须有合法
composer.json，且name字段（如"acme/utils"）和主项目require中完全一致 - 本地包的
version设为"dev-main"或"@dev"，避免 Composer 去 Packagist 查 tag
多人共用同一本地包时的隔离策略
如果 A 和 B 同时在改 ../acme-utils，又不想互相覆盖，不能靠 Composer 解决，得靠协作约定：
- 强制所有人在本地包里开功能分支（如
git checkout -b feat/payment-v2），主项目require写成"acme/utils": "dev-feat/payment-v2" - 禁用
@dev这种宽泛约束，改用具体分支名，避免不同人 checkout 到不同 HEAD - CI 流水线中禁止对
path包执行composer install——它只用于本地开发，生产环境应换用私有 VCS 仓库 + tag - 若真需临时隔离，删掉本地包目录即可：Composer 会安静跳过该包，不报错，比手动注释
repositories更干净
全局配置多个本地包时的路径陷阱
用 composer config -g repositories.acme-path '{"type":"path","url":"~/dev/acme/*"}' 是省事，但要注意：
-
*通配符只匹配一级子目录，~/dev/acme/utils/v2不会被识别 - 每个子目录下必须有独立
composer.json，且name不可重复，否则 Composer 加载时会随机选一个 - 全局配置会被项目级
repositories完全覆盖，所以项目里仍需保留"packagist.org": false显式关闭默认源，否则可能漏装
最常被忽略的一点：symlink 生效的前提是本地包目录已由 Git 管理，且至少有一个 commit。空目录、未 git init、甚至只有 .gitignore 没 commit，都会让 Composer 自动退到 copy 模式——它不报错，但你改了代码也不会立刻反映到主项目里。
