composer config -g repo.packagist 总不生效的根本原因是未同时满足三个硬性条件：键名必须为单数 repo.packagist、第二个参数必须显式指定 composer 作为 type 值、URL 必须是 HTTPS 且以 / 结尾；任一缺失即静默回退至 https://packagist.org，不报错也不提示。
composer config -g repo.packagist 命令为什么总不生效
它不报错，但流量没走镜像，根本原因不是网络问题，而是命令漏了三个硬性条件：键名必须是 repo.packagist（单数、小写、无 s），中间的 composer 是必填的 type 值（不是注释或可选参数），URL 必须是 HTTPS 且末尾带 /。漏掉任意一个，Composer 2.x 就会静默 fallback 到 https://packagist.org。
常见错误现象：
-
composer config -g repo.packagist https://mirrors.aliyun.com/composer/—— 缺composertype，结构非法，部分版本直接丢弃 -
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer—— 少末尾/，请求路径变成/composerpackages.json，返回 404 后自动切回官方源 -
composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/—— 键名多一个s，完全不识别
验证是否真写入成功，只看这一条命令输出：composer config -g repo.packagist 必须返回完整 JSON 对象，形如：{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}。空、null、"https://packagist.org" 或只返回字符串，都说明没配对。
项目级配置比全局更可靠，但写法有陷阱
全局配置写在 ~/.config/composer/config.json（Linux/macOS）或 %APPDATA%\Composer\config.json（Windows），但 CI 流水线、Docker 容器、宝塔面板等环境往往用的是其他用户身份，根本读不到你的全局配置。
正确做法是在项目根目录执行（不加 -g）：composer config repo.packagist composer https://mirrors.aliyun.com/composer/。但它不会“添加”，而是按 composer.json 中 repositories 的当前结构做不同处理：
- 如果
"repositories": {}（空对象），会安全写入"packagist"子项 - 如果
"repositories": []（数组），该命令会直接覆盖整个字段，导致已有的私有 Git 源丢失 - 如果
"repositories": {"my-private": {}}（已有对象），会 merge 进去，保留原有内容
更重要的是：光配 packagist 不够，必须显式禁用默认源。否则 Composer 仍会先尝试 packagist.org，卡在 “Loading composer repositories” 或报 404。需确保 composer.json 的 repositories 对象里有："packagist.org": false，且与 "packagist" 同级。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
换镜像后 composer install 还卡在 0 B/s
镜像配置本身没问题，卡顿往往来自缓存或残留元数据：
- 先清缓存：
composer clear-cache - 删掉项目下的
vendor/和composer.lock - 加
-vvv重试：composer install -vvv，看日志里请求域名是不是mirrors.aliyun.com - 旧版 Composer 1.x 不识别
repo.packagist，得用composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/（注意是repos复数）
临时参数优先级最高，但会完全覆盖项目里已有的 repositories 配置——如果项目用了私有 Git 包，这次命令会找不到它们。
Jenkins 或 GitHub Actions 中镜像失效的根本原因
Jenkins agent 每次启动都是干净容器，composer config -g 写入的是当前 shell 进程下的 ~/.composer/config.json，但这个路径在下次构建时可能被重置或根本不在挂载卷里。更麻烦的是：只要项目根目录存在 composer.json 且含 "repositories" 字段，全局配置就会被完全忽略。
正确做法是 Pipeline 中动态探测镜像可用性，写入项目级 composer.json 的 repositories 首项，清理 vendor 与 lock 文件，并保留私有源：
- 用
curl -I -s -o /dev/null -w "%{http_code}" https://mirrors.aliyun.com/composer/packages.json检查 HTTP 状态码 - 返回非 200 时，改设为
https://packagist.org，并确保"packagist.org": false被移除或设为true - 执行前删掉
vendor/和composer.lock，否则 Composer 仍会沿用旧 lock 里的 dist URL - 私有仓库和中文镜像共存时，手动编辑
composer.json，把镜像源作为repositories数组第一个元素，私有源跟在后面，例如：{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}、{"type":"vcs","url":"https://git.internal/pkg"}
最常被忽略的一点：即使镜像地址写对了，如果 composer.json 里没有显式声明 "packagist.org": false，Composer 仍会并行请求官方源，一旦其中某次请求超时或失败，整个流程就卡住——这不是镜像不可用，而是默认行为没关掉。
