“source path does not exist”主因是路径基准错位：composer始终以项目根目录（含composer.json处）为基准解析../my-package，而非当前shell工作目录；需在项目根目录执行ls -ld ../my-package验证路径真实存在且大小写精确匹配。
path仓库里写../my-package却报“Source path does not exist”
不是路径写错了，是当前工作目录和composer.json所在位置不一致。Composer 解析 url 字段时，始终以项目根目录（即含 composer.json 的目录）为基准点计算相对路径。
常见误操作：
- 你在
src/子目录下执行composer install，但composer.json在上层，此时../my-package实际指向的是src/../my-package→ 即项目根目录同级，而非你“以为”的 src 上级 - 路径大小写不匹配：Linux/macOS 下
My-Package≠my-package，Windows 默认不敏感但 WSL 或 CI 环境会暴露问题 - 用了绝对路径如
/home/user/myapp/packages/my-package，跨机器或 CI 时必然失效
验证方式：在项目根目录运行 ls -ld ../my-package（Linux/macOS）或 dir ..\my-package（Windows），输出必须是有效目录。否则就不是 Composer 的问题，是路径本身不存在。
想让多个本地包自动被识别，怎么配通配符
"url": "../packages/*" 是合法写法，但有硬性前提：目标目录必须存在，且每个子目录都包含有效的 composer.json。
容易踩的坑：
-
../packages/目录本身不存在 → 报错 “Source path does not exist” -
../packages/foo/里没composer.json→ Composer 跳过它，不报错也不警告 - 子目录名含空格或特殊字符（如
my plugin）→ 大概率解析失败，建议用短横线命名
安全做法：先手动确认 ls ../packages/*/composer.json 能列出所有预期文件，再写配置。
符号链接失败导致路径仓库加载异常
Composer 默认对 path 类型仓库尝试创建 symlink，但 Windows（尤其非开发者模式）、Docker 容器、CI runner 常禁止软链，此时会静默回退或报错。
解决方法只有两个明确选项：
- 显式禁用 symlink：
"options": { "symlink": false }，强制复制文件。适合 Windows 或容器环境 - 确保系统支持并启用 symlink：Windows 需开启“开发者模式”，Docker 需加
--cap-add=SYS_ADMIN（不推荐用于生产）
注意："symlink": false 必须嵌套在 repository 对象内，不能放在 config 或 extra 下，否则无效。
CI/CD 中 path 仓库总失效，是不是该换方案
是。path 仓库本质是开发期便利机制，依赖本地文件系统结构，在 CI/CD、Kubernetes 或部署到远程服务器时天然不可靠。
上线前务必切换：
- 本地开发用
path - 测试/预发/生产环境统一走 VCS（如
"type": "vcs", "url": "git@github.com:vendor/package.git"）或私有 Packagist
最易忽略的一点：composer.lock 里会固化 path 仓库的绝对路径（如 "source": { "type": "path", "url": "/home/dev/myapp/packages/foo" }）。一旦提交到 Git，其他人在不同机器上 composer install 就会失败。所以，不要把含 path 的 lock 文件提交进版本库。
