90%的invalid repository错误源于repositories配置不合法：URL协议被拒、type与url不匹配或服务端未返回预期JSON；需逐条检查type和url是否符合Composer硬性规则，并用curl或git ls-remote验证真实可达性。
直接告诉你结论：报 invalid repository 或 Repository not found 时，90% 不是网络问题，而是 composer.json 里某条 repositories 配置本身不合法——要么 URL 协议被拒绝，要么 type 和 url 对不上，要么服务端根本没返回预期 JSON。
检查 repositories 中每条配置的 type 和 url 是否匹配
Composer 对不同 type 的仓库有硬性校验规则，不满足就直接判“无效”，连请求都不会发。
-
type: "vcs"必须配 Git/SVN/Hg 地址，例如"https://gitlab.example.com/group/pkg.git"；写成网页地址"https://gitlab.example.com/group/pkg"就会失败 -
type: "composer"要求 URL 可访问且返回合法packages.json，比如"https://packages.example.com/"（注意末尾必须有/）；少个.json后缀或路径错一层（如/api/packages.json）都会 404 -
type: "package"不需要url字段，但必须提供完整package对象，含name、version、dist或source - 运行
composer diagnose，它会明确指出哪一条 repository “failed to parse”，比盲猜快得多
验证私有仓库 URL 是否真能返回有效响应
别信 Composer 报错信息里的模糊提示，直接用底层命令测试真实可达性。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 对
type: "composer"仓库：执行curl -I https://your-repo.com/packages.json，看是否返回HTTP/2 200，且响应体是合法 JSON（含顶层packages键） - 对
type: "vcs"仓库：执行git ls-remote -h https://your-git.com/user/repo.git，能列出 ref 才算通；若报fatal: unable to access，就是证书、代理或 DNS 问题 - 注意：Composer 默认不走系统
.gitconfig的 proxy 设置；公司有代理时，得单独设COMPOSER_HTTP_PROXY环境变量 - Docker 场景下，
localhost指的是容器自身——想连宿主机服务，URL 得写成http://host.docker.internal:8080（Linux 需加--add-host=host.docker.internal:host-gateway启动）
确认 Composer 版本与仓库协议兼容
老仓库服务（如旧版 Satis）和新 Composer 版本之间常有字段兼容性断裂，不是 URL 写错了，而是返回结构不被认可。
- Composer ≥ 2.2 已废弃
repo.packagist键名，必须用repositories.packagist.org.type+repositories.packagist.org.url两行设置 - Satis 用户请升级到 v2.0+ 并用
satis build重建索引；SatisPress 插件需确认已启用且重写了packages.json输出格式 - 某些自建镜像（如腾讯云、华为云旧镜像）已于 2023 年底下线，仍配置在
composer config -g里就会持续触发Repository not found - 运行
composer -V确认版本，再查对应文档中支持的仓库字段列表，别拿 Composer 2.9 的配置去跑 1.x 环境
临时禁用部分 repositories 快速定位问题源
错误提示从不告诉你具体是第几个仓库出问题，而 repositories 是数组，顺序敏感——逐条注释是最稳的排查法。
- 打开
composer.json，把repositories数组里除第一条外全部用//注释掉，再运行composer update --dry-run - 如果成功，说明问题在被注释的某条；否则问题就在第一条，继续细分
- 特别注意：项目级
repositories字段会完全屏蔽全局镜像配置，哪怕你全局设了阿里云，只要项目composer.json里有"repositories": []，就等于关掉了所有镜像 - 清缓存没用：
composer clear-cache只删 ZIP 和旧packages.json，不会刷新当前生效源的元数据；要强制重拉，得用composer update --refresh
最容易被忽略的是：你看到的报错发生在解析阶段，不是下载阶段——URL 拼写正确、网络通畅、权限也够，但只要返回的 JSON 缺一个逗号、多一个空格、或者顶层没 packages 键，Composer 就直接扔 invalid repository，连日志都不会记。
