Composer全局镜像配置失效的三大原因：漏-g、键名错写为repos.packagist或packagist.org、URL末尾缺/；验证需执行composer config -g repo.packagist并确认输出为正确JSON。
composer config -g repo.packagist 命令为什么总不生效
不是网络卡，是命令缺了关键三要素中的任意一个：漏掉 -g、键名写成 repos.packagist 或 packagist.org、URL 末尾没加 /。这三处任一出错，Composer 都静默走官方源，且完全不报错。
Composer 2.x 硬编码只认 repo.packagist（单数、全小写、无 s），composer 是必须显式传入的 type 值，不是注释。验证是否成功，直接运行：composer config -g repo.packagist —— 输出必须是类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 的 JSON 对象；如果为空、null 或报错，说明没配对。
- 漏
-g→ 只改当前项目composer.json，换目录就失效 - 键名错 → 配置存进无效字段，全局配置形同虚设
- URL 少
/→ 请求路径拼成/composerpackages.json，直接404或Invalid repository type
项目级 repositories 数组怎么避免私仓被镜像“抢答”
Composer 不是自动分流，而是按 repositories 数组顺序硬匹配：第一个返回 200 + 有效 JSON 的源就锁定使用，同名包根本不会查后面的源。私仓装不上，90% 是因为顺序或类型写错。
私有仓库必须放在镜像前面，且类型严格对应：
私有 Composer 仓库（如 Satis）用 "type": "composer"；
私有 Git 仓库用 "type": "vcs"，不能混写。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 私仓地址必须置于
repositories数组最前，否则镜像先响应404就直接失败，根本不会走到你的私仓 - Git 类型私仓 require 时得显式加
@dev或指定分支，比如acme/utils:dev-main，否则默认只找stable版本 -
repositories必须是 JSON 数组，不能写成对象；写成{"aliyun": {}}会导致只生效最后一个 - URL 末尾不能带
/packages.json，正确的是"https://mirrors.aliyun.com/composer/"
为什么禁用 packagist.org 要写在 repositories 末尾
哪怕你把阿里云镜像写在 repositories 第一位，只要没显式禁用 packagist.org，Composer 仍会把它当兜底源——不是靠数组位置，而是内置逻辑。一旦镜像对某个包返回 404（比如新包未同步），Composer 立刻切回官方源，看起来像“优先级失效”，其实是兜底行为在起作用。
"packagist.org": false 必须作为独立对象写入 repositories 数组，且放在末尾（不是开头）。它不是塞进某个镜像对象里，也不是写在根节点——放错位置就无效。
- 必须写成：
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}, {"packagist.org": false} - 不加这句，即使配置了镜像，也会先卡 30 秒请求官方源，超时后才 fallback
- 项目级
composer.json中定义了repositories，全局配置（~/.composer/config.json）会被完全忽略 - 删掉旧
vendor/和composer.lock再执行composer install，否则 lock 文件里记录的仍是旧源 hash
CI/CD 中主备镜像容灾不能靠 Composer 自身实现
Composer 不支持多镜像自动 fallback，repo.packagist.org 是单值配置，多次 config 会覆盖而非叠加。所谓“主备切换”必须由外部脚本控制探测 + 切换 + 清缓存。
真实可用的容灾流程只有三步：
1. curl -sI https://mirrors.aliyun.com/composer/ | head -n1 | grep "200 OK" 检查镜像根路径是否可访问
2. 成功则设为当前源，失败则 fallback 并 warn
3. 执行 composer clear-cache，防止元数据缓存污染
- 单纯靠
composer config切换，在 CI 中常失效，因为 Docker 缓存、vendor 复用或 Composer 自身 HTTP 缓存会让旧镜像请求继续发出 - GitHub Actions 中建议用
actions/cache分开缓存不同镜像下的vendor，避免混用导致依赖解析错乱 - 临时调试别动配置，用
-r参数更安全：composer update -vvv --repository=https://mirrors.cloud.tencent.com/composer/，日志第一行会显示实际下载 URL
composer.json 是否已硬编码了 repositories 字段——它会直接屏蔽全局配置，连 composer config -g 都救不回来。 
