“invalid repository”错误90%源于repositories配置非法：type与url不匹配、url缺末尾斜杠/、服务端未返回合法json；项目级配置会完全覆盖全局，composer diagnose可精准定位失败项。
Composer安装失败时提示“invalid repository”或“Repository not found”，90%的情况不是网络不通，而是repositories字段中某条配置违反了Composer的硬性校验规则——type与url不匹配、URL末尾缺斜杠、服务端返回非JSON响应，都会直接触发静默拒绝。
确认当前生效的仓库配置层级
Composer按优先级顺序读取配置：项目级 composer.json 中的 repositories → 全局 ~/.composer/config.json → 系统级（极少用）。项目里只要存在 "repositories": [...]，全局配置就完全失效。
运行 composer config --list --global | grep repositories 查看全局是否写入成功；再运行 composer config --list | grep repositories 对比项目级输出。若后者有结果而前者为空，说明问题出在项目配置本身。
执行 composer diagnose，最后一行会明确显示 “Repo packagist is private” 或列出具体哪条 repository “failed to parse”——这是最准的定位依据，不用猜。
验证每条repositories配置的合法性
Composer对不同 type 的仓库有不可绕过的格式要求，错一处即判无效。
方法一：检查 type: "composer" 配置
URL 必须以 https:// 开头且结尾带 /，例如 https://mirrors.aliyun.com/composer/；写成 https://mirrors.aliyun.com/composer（少斜杠）或 https://mirrors.aliyun.com/composer/packages.json（多后缀）都会导致 404 或解析失败。用 curl -I https://your-url.com/packages.json 确认返回 HTTP/2 200 且响应头含 Content-Type: application/json。
方法二：检查 type: "vcs" 配置
URL 必须是可被 Git 直接克隆的地址，例如 https://gitlab.example.com/group/pkg.git；若填的是网页地址 https://gitlab.example.com/group/pkg，Composer 连请求都不会发，直接报 invalid repository。用 git ls-remote -h https://your-git.com/user/repo.git 验证是否能列出 refs。
方法三：检查 type: "package" 配置
这种类型不能写 url 字段，必须提供完整 package 对象，包含 "name"、"version"、"dist"（含 "url" 和 "shasum"）或 "source"（含 "url"、"type"、"reference"）。漏掉 shasum 或 reference 会导致解析中断。
修复镜像配置静默失效问题
第一步：确保键名、type值、URL格式三者全部正确composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ ——注意中间的 composer 是 type 值，不是 URL；键名是 repo.packagist（不是 repos.packagist），URL 必须以 / 结尾。
第二步：清空缓存并删除 lock 文件
换源后不执行 composer clear-cache，旧失败记录仍驻留缓存，重试照样走原地址；同时删掉 composer.lock，否则 Composer 会跳过解析新源直接复用旧锁文件里的下载路径。
第三步：用 -vvv 日志确认真实请求域名
运行 composer install -vvv --no-progress，盯住日志中出现的首个 GET 请求 URL——如果仍是 packagist.org 或 api.github.com，说明镜像根本没接管；只有看到 mirrors.aliyun.com 才算真正生效。
