答案是：composer的path仓库类型通过在主项目composer.json的repositories中配置{"type":"path","url":"../my-package"}，直接读取本地目录下合法composer.json（name与require一致、含version或dev-main分支），跳过网络和git克隆，实现本地联调；需配"options":{"symlink":true}并执行composer update才能使代码修改实时生效。
Composer 的 path 仓库类型能直接映射本地目录，跳过 packagist 和 Git 克隆
它不是“发布线上”的替代方案，而是本地开发阶段快速联动多个项目源码的机制。只要 Composer 能读取到目标目录下的 composer.json，就能把它当作一个包来 require，连 git clone 都省了。
关键前提是：目标目录必须已存在、有合法的 composer.json（含 name 和 version），且 name 与你 require 时写的完全一致。
常见错误现象：Could not find package xxx/yyy at version dev-main —— 很可能是因为本地目录里 composer.json 缺 version，或 name 拼错，或路径没写对。
怎么配 path 仓库？重点在根 composer.json 的 repositories 字段
在主项目的 composer.json 里加一段仓库声明，位置在顶层（和 require 同级）：
{
"repositories": [
{
"type": "path",
"url": "../my-package"
}
],
"require": {
"my-vendor/my-package": "dev-main"
}
}
注意几个硬性条件：
-
url是相对于当前composer.json文件的路径，不能是绝对路径（Windows 下也别用C:/...） -
my-vendor/my-package必须和被引用目录中composer.json的name完全一致（包括大小写） -
dev-main这类开发版版本号，要求被引用目录里composer.json有对应version字段，比如"version": "dev-main"；如果没写version，Composer 会尝试从 Git 分支推断，但本地无 Git 仓库时就会失败
为什么有时 composer install 不生效？检查这三处
path 类型仓库容易被缓存或忽略，尤其在已有 lock 文件时：
- 删掉
vendor/和composer.lock再运行composer install—— 否则 Composer 可能沿用旧的 dist 包信息 - 确认目标目录里没有
.git且没被git init过；否则 Composer 会误判为 VCS 包，走 Git 逻辑而非 path 映射 - 执行
composer config --list | grep repositories，看是否真加载了你写的repositories块；某些全局配置或插件可能覆盖它
依赖更新后不自动同步？path 不触发重安装，要手动刷新
这是 path 仓库最常被忽略的行为：它只是软链接式引用，不监听文件变更。改了被引用包的代码，主项目不会自动感知。
正确做法是：
- 每次改完
../my-package的源码，回到主项目执行composer update my-vendor/my-package（不是install） - 或者加
--with-dependencies确保其子依赖也一并更新 - 如果想让 IDE 或调试器实时识别改动，建议把
../my-package直接作为 IDE 项目根目录打开，而不是只靠 Composer 加载
复杂点在于：一旦你 push 了这个包到 Git 并准备上线，就得把 repositories 块删掉、改回正常的 packagist 或 VCS 仓库，否则线上环境找不到 ../my-package。
