运行 composer config repos 是验证自定义仓库配置是否生效的首要步骤，它仅显示项目级 composer.json 根级 repositories 数组内容，不包含全局或默认源；若未出现，说明配置位置错误、语法非法、路径含环境变量或未禁用 packagist.org。
运行 composer config repos 看是否出现在列表里
这是最直接的第一步：它只显示项目级 composer.json 中显式声明的 repositories 数组内容，不混入全局配置或默认源。如果刚加了 path 或 composer 类型仓库却没出现，说明配置位置错了——repositories 必须是根级字段，不能塞进 config、scripts 或 require 里。
常见错误包括：
- 把
repositories写在本地包自己的composer.json中（主项目完全看不到） - 用了缩进错误或 JSON 语法非法（比如多了一个逗号），Composer 会静默跳过整条配置，不报错
- 路径写成
~/my-pkg或$HOME/my-pkg（Composer 不解析环境变量）
执行 composer update vendor/name 并检查输出关键词
composer install 完全不读 repositories，所以必须用 update 才能触发自定义源逻辑。观察终端输出是否有以下任一提示：
-
Installing vendor/name (dev-main): Symlinking from ../my-pkg（path 类型成功软链） -
Downloading https://pkg.myorg.com/packs/vendor-name.json（composer 类型命中私有源） -
Cloning（vcs 类型开始克隆）https://gitlab.example.com/vendor/name.git
注意：Symlinking 日志可能只是缓存提示，不代表真建了链接；关键得看 vendor/ 下是不是符号链接。
检查 vendor/vendor-name/package-name 是否为符号链接
这才是最终验证标准，比日志可靠得多：
- macOS / Linux：
ls -la vendor/acme/utils，输出中含->才算 path 仓库生效 - Windows：
dir vendor\acme\utils，看到 - 如果显示普通目录，说明 fallback 成 ZIP 解压拷贝了——回头重点查三件事：
name字段大小写是否一致、url路径是否可访问、本地包composer.json里version是否写了dev-main或*
确认 packagist.org 已被禁用（尤其混用镜像时）
即使你配了私有源，只要 repositories 数组里没加 {"packagist.org": false}，Composer 就永远优先查官方源，你的配置形同虚设。这个对象必须：
- 作为
repositories数组里的**独立项**，不能嵌套在其他仓库对象里 - 放在数组末尾（不是开头），否则可能被前面的源拦截掉
- 键名严格为
packagist.org（带点、小写、无复数 s） - 别用
composer config --global repos.packagist false，那是全局污染，其他项目会崩
真正复杂的点在于：镜像源（如阿里云）和自定义仓库共存时，元数据刷新是两套机制。镜像卡住 ≠ 自定义源失效，但很多人会误判方向。先确保 packagist.org 关了，再单独验证私有源路径是否可 curl 通、packages.json 是否能返回有效 JSON。
