Composer的path仓库本质是符号链接而非文件复制，修改本地代码立即生效，但需确保PSR-4规范、合法composer.json及name字段匹配；支持相对/绝对路径，Windows需管理员权限；配置分全局repositories声明与require内联两种方式；更新失效时需检查allow-plugins、清缓存并重删vendor目录；严禁用于生产环境，CI中须自动移除path配置。
本地 path 仓库的本质是软链接，不是复制文件
Composer 的 path 类型仓库不会把包源码拷进 vendor/，而是用符号链接（Linux/macOS）或目录联结（Windows）指向你指定的本地路径。这意味着：改本地代码 = 立即生效，无需 composer update；但前提是你的开发目录结构符合 PSR-4 自动加载规范，且 composer.json 中的 autoload 配置正确。
- 必须确保目标目录里有合法的
composer.json，且包含name字段（格式如"myorg/mypackage"），该名称要和主项目require中声明的一致 - 路径支持相对（如
../mypackage）和绝对（如/Users/me/dev/mypackage），但相对路径以主项目根目录为基准 - Windows 用户注意：
mklink /D权限问题可能导致链接失败，可临时用管理员权限运行composer install
在 composer.json 中配置 path 仓库的两种写法
有两种等效方式：全局仓库级声明（推荐用于多包协同），或仅针对某依赖的内联写法（适合快速验证）。关键区别在于作用范围和可维护性。
- 方式一（推荐）：在主项目的
composer.json根级加repositories块，再require对应包名 - 方式二（临时）：直接在
require中用对象语法写路径，不需额外声明repositories - 两者都要求目标包的
composer.json中version字段存在（哪怕写"dev-main"），否则 Composer 会报Could not find a matching version
{
"repositories": [
{
"type": "path",
"url": "../mypackage"
}
],
"require": {
"myorg/mypackage": "*"
}
}
composer update 不触发重链接？检查 allow-plugins 和缓存
常见现象：改了本地包的 composer.json（比如更新了 version 或 autoload），但 composer update myorg/mypackage 没反应，vendor/myorg/mypackage 仍是旧链接甚至变成普通目录。
- 先确认是否启用了
composer-plugin-api兼容插件：Composer 2.2+ 默认禁用未声明的插件，path仓库依赖composer-plugin-api，需在主项目composer.json中显式允许 - 执行
composer clear-cache，否则 Composer 可能复用旧的元数据缓存，忽略路径变更 - 若链接已损坏（变成普通文件夹），手动删掉
vendor/myorg/mypackage再composer update，强制重建链接
生产环境严禁使用 path 仓库，CI/CD 中要自动切换
path 是纯开发期机制，上线部署时若没清理，会导致构建失败（路径不存在）或引用错误代码。不能靠“上线前手动改 composer.json”来规避。
- CI 脚本中应在安装前移除
repositories中的path条目，或用composer config --unset repositories清空 - 更稳妥做法：用
COMPOSER_ROOT_VERSION=1.0.0 composer install强制忽略本地开发分支，走 packagist 正式版本 - 团队协作时，建议把
path配置放在composer.json.dist外，或通过COMPOSER_HOME指向不同配置，避免误提交
路径映射看着简单，但链接状态、缓存行为、环境隔离这三处最容易出 silent fail —— 出问题时先看 ls -la vendor/xxx 是否真为链接，再查 composer show myorg/mypackage 输出里的 source 字段是否含 path。
