windows上path仓库链接失败的典型表现是vendor目录下对应包存在但为空，或报“could not find a matching version”，主因是开发者模式未启用导致symlink静默失败，需启用开发者模式并以管理员权限运行终端。
path仓库链接在Windows上失败的典型表现
你执行 composer install 后，vendor/vendor/name 目录存在但内容为空，或报错 Could not find a matching version of package vendor/name——这通常不是包没写对，而是 Windows 下符号链接未生效。
Windows 默认禁用开发者模式时，symlink() PHP 函数会静默失败，Composer 却仍认为“链接已建”，导致后续 autoload 或 require 失败。PowerShell 或 CMD 中运行 dir vendor\vendor\name 若显示为普通目录而非 <symlink></symlink>，就确认了这点。
- 必须启用 Windows 开发者模式（设置 → 更新与安全 → 针对开发人员 → 开发者模式）
- 以管理员权限启动终端（尤其 PowerShell），否则
mklink系统调用被拒绝 - 避免在 OneDrive、WSL 挂载路径等非本地 NTFS 卷中使用
path仓库
Linux/macOS 与 Windows 的 path 路径写法差异
repositories 字段里写的 url 必须是**目录路径**，且需兼容各系统对路径分隔符和波浪号 ~ 的解析。硬写 ../packages/mylib 在 WSL 和 Git Bash 中可能正常，但在 Windows PowerShell 中会被当作字面字符串处理，找不到目录。
- 统一用相对路径：如
"url": "../packages/mylib"，不带~或$HOME - 避免跨驱动器引用（如
D:\packages\mylib），Windows 下 Composer 不支持 UNC 或盘符绝对路径作为path源 - macOS/Linux 用户若用 Zsh，确保
~未被 shell 展开进composer.json—— JSON 不解析变量，写进去就是字面值
CI/CD 中 path 仓库必须移除的原因
CI 环境（如 GitHub Actions、GitLab CI）通常没有本地 path 对应的目录结构，composer install 会直接报错退出，哪怕你只在本地开发时用它。
- 不要把
path条目提交进主分支的composer.json；改用分支保护 +.gitattributes排除或 CI 前 patch - 推荐做法：在 CI 脚本开头运行
composer config --unset repositories.my-local-path（假设你给它起了名字） - 若必须保留，用
"packagist.org": false配合条件判断无效——Composer 不识别条件逻辑，只会全量加载所有repositories
修改本地 path 包后如何强制刷新链接
composer install 不会重连已存在的 symlink，哪怕你改了本地包的 composer.json 里的 version 或 name。它只检查 composer.lock 记录的解析结果是否匹配当前 repositories 声明。
- 改完本地包代码后，必须运行
composer update vendor/name（指定包名），不能只跑install - 如果本地包的
composer.json新增了依赖，也得update才能同步进根项目的vendor - 想验证链接是否指向最新内容：Linux/macOS 运行
ls -la vendor/vendor/name，输出末尾应有-> ../packages/mylib；Windows 运行dir vendor\vendor\name，应看到<symlinkd></symlinkd>
