根本原因是repositories未在主项目composer.json中正确配置path源，且本地包缺少合法composer.json或name不匹配；require仅声明需求，不指定来源，Composer不会自动发现本地目录。
path 仓库不是“多仓库”的替代方案，而是本地协同开发的专用通道；它不参与包发现，只响应明确 require 的包名，且必须配 symlink 才能实时生效。
为什么 composer require vendor/name:dev-main 总是报 “Could not find package”
根本原因不是网络或权限，而是 Composer 根本没“看见”你的本地目录。它只在 repositories 数组里找源，require 字段只声明“我要哪个包”，不负责“去哪找”。
-
repositories必须写在主项目（即你正在开发的那个项目的）composer.json里，不能写在本地包自己的composer.json中 -
url必须是相对路径（如"../my-package"），绝对路径在 Windows 上极易静默失败（盘符、反斜杠、空格都会中断） - 本地包目录下必须有合法的
composer.json，且其中name字段（如"acme/utils"）要和require里写的完全一致（大小写敏感） - 版本约束必须用
dev-main、dev-develop这类分支名，不能写1.0.0——path源下 Composer 忽略version字段，只认当前 Git HEAD 所在分支
path 仓库必须加 "options": {"symlink": true} 吗
必须加，否则改了本地代码不会反映到主项目中。默认行为是复制（copy），不是链接（symlink）。
- 不加
symlink：执行composer update acme/utils后，vendor/acme/utils是一份静态副本，后续修改本地源文件无效 - 加了
symlink：执行composer update acme/utils后，vendor/acme/utils是指向源目录的符号链接，改源码立刻生效 - 验证是否成功：
ls -la vendor/acme/utils应显示箭头指向源目录；Windows 用户用dir vendor\acme\utils看是否为“快捷方式”类型 - Windows 需开启开发者模式或以管理员权限运行命令行，否则
symlink创建会失败且无提示
多个 path 仓库共存时，怎么避免命名冲突
path 类型本身不提供包索引，也不做全局匹配，它只响应 require 中**完全匹配**的包名。冲突不是由 Composer 自动解决的，而是靠你手动控制路由。
- 每个
path条目对应一个独立的本地包，url路径必须唯一，且各自composer.json中的name字段不能重复 - 如果两个本地包都声明了
"name": "acme/utils"，Composer 只会使用repositories数组中靠前的那个，后一个被完全忽略 - 推荐做法：把模块拆成子目录（如
modules/payment、modules/user），每个子目录有独立composer.json和唯一name（如"myapp/payment"） - CI 构建时
path会失效——上线前必须切回真实远程源（如私有 Satis 或 Git），否则构建机上没有../my-package就直接中断
最易被忽略的一点：path 仓库跳过所有元数据请求，不连 Packagist、不查 packages.json，因此它天然离线、极快，但也更脆弱——一旦本地路径不存在、composer.json 缺失或 name 不匹配，错误往往静默或表现为“包找不到”，而不是清晰的路径错误提示。
