path仓库是composer repositories中type为"path"的一种本地包加载机制，需在composer.json的repositories数组中显式声明相对路径，严格校验本地composer.json的name与require一致，不联网、不校验签名，支持符号链接但需手动update刷新。
Path 仓库不是“本地开发捷径”，而是双刃剑：用对了能加速协作和灰度验证，用错了会导致依赖锁定、CI 失败、团队环境不一致。
什么是 path 仓库，它和 repositories 的关系是什么
path 是 Composer repositories 类型的一种，允许你把本地文件系统路径当作一个“伪 Packagist”来加载包。它不走网络，不校验签名，也不受 packagist.org 版本约束——这正是灵活性的来源，也是风险的起点。
-
path必须显式声明在composer.json的repositories数组里，类型为"type": "path" - 路径值支持通配符（如
../packages/*），但每个匹配到的目录必须含合法的composer.json - Composer 不会自动 symlink 或 copy 文件；它只读取该路径下
composer.json中的name和version，再按需安装 - 如果多个
path匹配同一个包名（比如两个同名包都在../packages/下），Composer 会报错：Package ... is ambiguous
如何让 path 只在开发环境生效
硬编码 path 到主项目 composer.json 里，等于把本地路径污染进版本库，CI 构建必然失败。正确做法是分层隔离：
- 在项目根目录新建
composer.dev.json，只放开发专用的repositories块，其他字段继承主文件 - 运行
COMPOSER=composer.dev.json composer install，这样 CI 仍用默认composer.json，而本地可启用 path - 更稳妥的方式是用
config.platform+path组合：在composer.dev.json中设置"config": {"platform": {"ext-xdebug": "3.0.0"}}，避免因扩展缺失导致 dev-only 包被跳过 - 切勿在
require-dev里直接写"myorg/my-pkg": "dev-main"并指望path自动覆盖——必须确保name和version完全匹配，否则 Composer 仍会从远程拉取
path 包更新后为什么没生效
这不是缓存问题，而是 Composer 的“安装快照”机制在起作用：composer.lock 记录的是包的实际来源（type: path 还是 type: vcs）和完整路径。哪怕你改了源码，只要没重新 composer update myorg/my-pkg，它就不会重新解析。
- 修改
path包代码后，必须执行composer update --lock myorg/my-pkg（加--lock可跳过安装，只刷新 lock 文件中的 commit hash 或时间戳） - 如果
path包的composer.json里写了"minimum-stability": "dev"，但主项目设了"minimum-stability": "stable"，则该path包会被忽略——Composer 以主项目配置为准 - Windows 用户注意路径分隔符：
../packages/my-pkg在 Linux/macOS 可用，但在 Windows 的 Git Bash 下可能需写成../packages/my-pkg（保持正斜杠），而 PowerShell 中反斜杠需转义为..\packages\my-pkg
真正难的不是配置 path，而是判断什么时候不该用它——比如跨团队共享、需要语义化版本控制、或包本身要发布到私有 Satis/SatisPress 时，path 就该退场，换成 vcs + 分支别名更可靠。
