Composer报“Could not find package”主因是repositories未生效或name不匹配：repositories须置于composer.json根级、首项为{"packagist.org": false}，path须为相对路径且指向含composer.json的目录，name必须与require逐字一致。
本地 Composer 包报 Could not find package，不是路径不存在，而是 Composer 根本没去读那个目录——90% 的问题出在 name 字段不匹配或 repositories 配置未生效。
为什么 composer install 完全无视你的 path 仓库
Composer 默认只查 packagist.org，你加的 repositories 不会自动启用，必须显式禁用默认源并确保配置位置正确。
-
repositories必须写在项目根目录composer.json的**最外层根对象里**，不能塞进config、require或其他嵌套字段中 - 第一项必须是
{"packagist.org": false}，否则你的本地源永远排第二，形同虚设 -
url值只接受相对路径（如"../my-pkg"），绝对路径（/home/user/my-pkg）和file://前缀会被静默跳过 - 运行
composer show --all | grep vendor/name，如果无输出，说明仓库根本没加载成功
name 字段大小写/符号不一致就失败
Composer 不模糊匹配、不忽略大小写、不转换短横线，name 必须与 require 中的字符串逐字完全一致。
- 执行
cat ../my-pkg/composer.json | grep name（Linux/macOS）或findstr name ../my-pkg/composer.json（Windows），确认输出是"name": "vendor/name"，不是"Vendor/Name"、"vendor_name"或带空格 -
url必须指向**含composer.json的目录**，"../packages"错，"../packages/my-pkg"对 - 路径末尾不能带
/："../my-pkg/"会被静默忽略 - 删掉
vendor/和composer.lock，再跑composer install --verbose，看日志里有没有Reading ../my-pkg/composer.json
路径存在却报 “Source path does not exist”
这个错误名不副实——它不是说路径写错了，而是文件系统拒绝访问：目录不可见、不可读，或被环境隔离（尤其在 Windows、Docker、WSL、CI 中）。
- 检查目录是否真存在且可读：
ls -la ../my-pkg（Linux/macOS）或dir ..\my-pkg（Windows） - Windows 用户注意中文用户名路径（如
C:\Users\张三\...）在部分终端里解析失败，优先用%USERPROFILE% - Docker 或 WSL 环境下，确保挂载路径正确，且宿主机上的
composer.json已实际存在于容器内对应路径 - 软链接（
ln -s）可能导致 realpath 失败，某些 CI 环境禁止跨挂载点访问，此时用绝对路径传给-d更可靠
真正卡住的地方往往不是“怎么配”，而是“配了但没生效”——比如 repositories 被项目级配置覆盖、name 字段差一个字母、或路径在 WSL 里看似存在实则无法被 realpath 解析。验证必须靠命令输出，而不是“我觉得应该对”。
