path仓库是本地开发临时链接机制，非私有Packagist替代方案；它依赖本地路径存在且含合法composer.json，不支持跨环境复现、无远程校验、版本由本地version字段决定，仅适用于原型验证。
Composer 的 path 仓库类型不是“私有包托管方案”，而是本地开发阶段的临时链接机制——它不解决分发、权限、CI/CD 或版本收敛问题，但能绕过发布流程快速验证包逻辑。
为什么 path 仓库不能替代私有 Packagist
它本质是 symlink（Linux/macOS）或 junction（Windows）的封装，Composer 只在 install 或 update 时读取目标目录下的 composer.json，然后硬链接源码。这意味着：
- 目标路径必须存在且含有效
composer.json，否则报错Could not parse version constraint ... Invalid version string - 没有远程校验：改了本地代码，
composer update不会自动感知，得手动composer dump-autoload或删vendor重装 - 无法被其他机器复现：
path路径是绝对或相对的，CI 环境或队友机器上路径不同就直接失败 - 版本号由本地
composer.json的version字段决定，不是 Git tag；设成"dev-main"才能匹配"^1.0"这类约束
如何正确配置 path 类型仓库
必须在项目根目录的 composer.json 中声明仓库，并确保包名与路径下 composer.json 的 name 严格一致：
{
"repositories": [
{
"type": "path",
"url": "../my-utils"
}
],
"require": {
"acme/my-utils": "*"
}
}
关键点：
-
url支持相对路径（推荐），也支持绝对路径如/Users/me/projects/my-utils，但后者不可移植 - 若
../my-utils下composer.json的name是acme/my-utils，才能被正常 require；名字不匹配会报Package acme/my-utils not found - 想强制走 path 源而非 Packagist，加
"options": {"symlink": true}（默认已启用），但 Windows 上需管理员权限建 junction
path 仓库 + autoload-dev 的典型误用场景
很多开发者把测试工具包（如自定义 PHPUnit 断言）用 path 引入后，发现 vendor/autoload.php 加载不到新类——根本原因是没在包自身的 composer.json 里配好自动加载：
- 包内
composer.json必须含"autoload"（非autoload-dev），例如："autoload": {"psr-4": {"Acme\Utils\": "src/"}} -
autoload-dev只影响包自身开发时的加载，对引用方无效 - 改完
autoload后，必须运行composer dump-autoload（在主项目执行），否则新映射不生效 - 如果包里用了
__DIR__计算路径（比如加载配置文件），要注意 symlink 后__DIR__指向的是 vendor 下的链接位置，不是原路径
什么时候该停用 path 并切到真实私有源
当出现以下任一情况，说明已超出 path 的适用边界：
- 需要让 QA 或测试环境跑相同的依赖树，但他们的机器没有对应本地路径
- 多个包互相依赖，且都用
path，Composer 会因循环解析失败（如 A → B → A） - CI 流程中要跑
composer install --no-dev，但path包里有require-dev依赖未满足，导致安装中断 - 开始打 Git tag（如
v1.2.0），却仍用"*"或"dev-main"require，版本无法锁定
这时应立即迁移到 Satis、Private Packagist 或 GitHub Packages —— path 只是原型验证的拐杖，不是拐杖本身。
