composer的path仓库是严格按repositories声明匹配的显式机制，需满足url为目录、本地composer.json含一致name和version；改代码后须运行composer update vendor/name刷新符号链接，install不更新已有链接。
Composer 的 path 仓库不是“自动发现本地包”的捷径，而是严格按配置路径 + composer.json 元数据匹配的显式绑定机制；改了本地代码不生效，不是缓存问题，是没运行 composer update vendor/name。
path 仓库怎么被 composer install 识别到
它完全依赖根项目 composer.json 中 repositories 字段的声明，且只认目录，不认文件。你写 "url": "../my-package"，Composer 就去这个路径下找一个存在且合法的 composer.json 文件。
必须满足三个硬性条件：
-
url指向的是一个目录，不能是../my-package/composer.json这种文件路径 - 该目录下必须有
composer.json，且其中name字段（如"name": "acme/utils"）必须和你在require里写的完全一致（包括大小写、斜杠位置） -
composer.json里至少要有name和version（哪怕写"dev-main"或"1.0.x-dev"）
常见错误：Could not find a matching version of package acme/utils——八成是 repositories 没配、路径拼错、name 不一致，或本地目录压根没放 composer.json。
为什么 vendor 里是符号链接而不是复制文件
这是 Composer 默认行为，但仅在满足两个前提时才启用：操作系统支持 symlink()（Linux/macOS 默认 OK；Windows 需开发者模式 + 管理员权限），且该包未被标记为 "dist" 类型。
你可以用命令验证是否真链接成功：
- Linux/macOS：
ls -la vendor/acme/utils，输出含->表示是软链 - Windows：
dir vendor\acme\utils，看到<symlinkd></symlinkd>才对
想强制复制？在 config 里加："preferred-install": {"acme/utils": "dist"}。但注意：CI/CD 环境中符号链接必然失败（路径不存在），上线前必须删掉 repositories 里的 path 条目。
本地包改了代码，为什么 composer install 不更新链接
composer install 只重建缺失的链接，不会刷新已有链接的目标路径。它读取 composer.lock 里已记录的解析结果，而这个结果是在 composer require 或 composer update 时固化下来的。
也就是说：改完 ../my-package 里的代码，composer install 什么也不做。必须执行：
-
composer update acme/utils—— 安全、精准，只重解析这个包 - 避免
composer update不带参数 —— 全量重算慢，还可能意外升级其他包
别指望 composer dump-autoload 能刷新链接，它只更新类映射，和 symlink 无关。
多个仓库共存时，path 仓库的优先级怎么起作用
Composer 2.x 默认按 repositories 数组顺序查找，一旦在某个仓库命中 acme/utils，后续仓库（包括 Packagist）就完全跳过。所以 path 仓库要放在数组靠前位置，才能确保本地开发版本优先生效。
典型配置：
"repositories": [
{
"type": "path",
"url": "../my-package"
},
{
"type": "packagist",
"url": "https://packagist.org"
}
]
如果把 path 放在后面，而 Packagist 上恰好有同名包，Composer 就永远找不到你的本地版本——这不是 bug，是设计如此。Composer 1.x 会合并所有仓库元数据，容易引发版本混乱，升级到 2.x 后务必检查顺序。
