Composer require vendor/name:dev-main报“Could not find package”是因为repositories未在主项目composer.json根级正确配置path类型仓库，且url须为相对路径（如"../my-package"），name须与本地包composer.json中逐字匹配，否则静默失败。
必须用相对路径写 ../ 开头的 url，且本地包的 composer.json 里 name 要和 require 中完全一致——否则 composer require 会静默失败，连报错都看不到。
为什么 composer require vendor/name:dev-main 报 “Could not find package”
根本不是网络或权限问题，而是 Composer 根本没“看见”你上级目录里的包。它只扫描 repositories 数组里声明的路径，不自动向上遍历目录树。
-
repositories必须写在主项目（即你当前运行composer命令的那个项目）的composer.json根级，不能写在上级包自己的composer.json里 -
url必须是相对于主项目composer.json的路径，例如"../my-package"，不能是"../../my-package"或带file://前缀 - 上级目录中必须存在合法的
composer.json，且其中name字段（如"acme/utils"）要和require中写的逐字匹配（大小写、短横线、vendor 名全对齐） - 路径末尾不能加
/，"../my-package/"会导致整个仓库被跳过，无任何提示
repositories 配置怎么写才生效
写错位置或格式，Composer 就当它不存在。常见错误是塞进 require 或 config 字段，或者用了绝对路径。
- 必须是根级数组：
"repositories": [{ "type": "path", "url": "../my-package" }]，哪怕只有一个也要套方括号 -
type必须是"path"，不是"package"或"vcs" -
url推荐用../开头的相对路径，避免换机器后失效；Windows 上绝对路径（如C:/dev/my-package）极易因反斜杠、空格、盘符解析失败 - 上级包目录下不能只有代码文件，必须有可解析的
composer.json（无语法错误、全双引号、无尾逗号）
改了上级包代码，主项目里为啥没更新
默认行为是复制（copy），不是链接（symlink）。你改的是源目录，vendor/ 里还是旧副本——这是最常被忽略的坑。
- 必须在**上级包自己的
composer.json里**加"options": {"symlink": true}，不是主项目的repositories条目里（后者在新版 Composer 中已不生效） - 执行
composer update acme/utils（不是install或dump-autoload）才会重建链接 - 验证是否成功：
ls -la vendor/acme/utils（Linux/macOS）应显示箭头指向../my-package；Windows 上用dir vendorcmeutils看是否为“JUNCTION”类型 - Windows 用户需以管理员身份运行终端，否则
symlink创建失败且静默 fallback 到 copy
autoload 不生效？别怪 Composer，先看路径映射
即使 symlink 成功，new AcmeUtilsHelper() 还是报类找不到，大概率是 autoload 没覆盖真实路径。
- 上级包的
composer.json必须正确定义autoload，例如："psr-4": {"Acme\Utils\": "src/"} - 主项目执行
composer dump-autoload -o才会重新生成映射，但前提是上级包已通过update正确链接进vendor/ - Xdebug 断点失效？检查 IDE 中配置的路径是否和磁盘上真实路径一致（比如是否把
../my-package映射成了/home/user/my-project/../my-package）
真正麻烦的从来不是配对 name 或写对 ../，而是 symlink 失败后毫无提示地 fallback 成 copy——你得手动 ls -la 或 dir 确认链接状态，否则调试半天都在改错地方。
