Composer不支持断点续传和自动镜像fallback，仅靠配置多个源无法容灾；全局镜像配置为单值，需手动探测、切换并清理缓存才能实现可靠恢复。

Composer 不支持断点续传，也不支持自动 fallback 到备用镜像源——所谓“设置多个镜像源就能容灾”，是常见误解。中断后能否继续，取决于失败阶段和你是否做了确定性清理，而不是靠镜像“智能切换”。

composer config -g repo.packagist 只能设一个 URL

这个配置项是单值字段，不是数组。执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 后，再跑一次设腾讯云地址，前一个就彻底被覆盖。命令不报错，但 composer config -g repo.packagist 查出来永远只有一个 URL。

常见错误现象：composer install 仍卡在 Downloading https://packagist.org/p/... ——说明根本没走你配的镜像，而是因为配置漏了 composer 类型参数、URL 少了末尾 /，或用户权限不对（比如用 sudo 配了 root 的配置，但部署脚本以 www-data 身份运行）。

• 必须带 -g（全局），否则只影响当前项目目录
• 必须写 repo.packagist（单数），写成 repos.packagist 无效
• URL 必须以 / 结尾，否则请求路径拼错，返回 404 却不提示
• 验证是否生效：运行 composer diagnose，看 Repo packagist.org: 行是否显示你的镜像地址

repositories 数组不是“备用”，是“顺序匹配”

在 composer.json 里写多个 repositories，不会让 Composer 在第一个源超时后自动切到第二个。它只对 404 做 fallback；遇到 502、503、超时、DNS 失败，直接中断报错。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

更关键的是：一旦你写了 repositories 数组，Composer 默认就禁用隐式 packagist.org 源。如果你没显式把它加回数组末尾并设 "packagist": true，连元数据都拉不到。

• 错误写法："packagist.org": false 单独放在对象顶层 → 配置非法，composer validate 都过不了
• 正确兜底写法：在 repositories 数组末尾加 {"type": "composer", "url": "https://packagist.org/", "packagist": true}
• 但注意：这个兜底只用于拉 packages.json，ZIP 下载仍走你排第一的镜像，不会换
• 项目级 repositories 会完全屏蔽全局 repo.packagist 配置，二者不合并

真·容灾必须靠外部脚本探测 + 切换

稳定上线或 CI 构建不能依赖“运气好”。可行方案是：每次 composer install 前，用 curl -I -s -w "%{http_code}" -o /dev/null https://mirrors.aliyun.com/composer/packages.json 探活；失败则切到腾讯云或官方源，并清缓存确保元数据刷新。

• 探测必须查 packages.json 路径，不是根 URL（有些镜像根路径返回 200，但 packages.json 404）
• 切换后必须运行 composer clear-cache，否则旧缓存可能指向已失效的 dist URL
• 切换命令要用 composer config repositories.packagist url https://xxx（项目级）或 composer config -g repo.packagist composer https://xxx（全局）
• 别用 composer config --unset 清旧配置——某些老版本会因此丢失默认 fallback 行为

中断后别等“自动续传”，要手动清理重试

网络中断后，composer install 不会接着下一半 ZIP，也不会跳过已解压的包。它只会比对 vendor/ 和 composer.lock，然后从第一个不一致的地方重来——而这个“不一致”常是损坏的 installed.json 或截断的 ZIP 文件。

• 删掉整个 vendor/ 目录（或只删失败包子目录，如 vendor/monolog/monolog）
• 删掉 vendor/composer/installed.json（若 vendor/ 已清空，这步自动生效）
• 运行 composer clear-cache，避免复用损坏的 ZIP 缓存
• 加 --no-scripts --no-plugins --prefer-dist 重试，降低失败面
• 确保 composer.lock 完整未被修改，否则触发全量重新解析，耗时更长

真正容易被忽略的点，不是镜像地址写没写对，而是：**Composer 的“稳定性”不来自多源切换，而来自每次操作的可预测性——删干净、换确定源、跳非必要步骤、靠 composer.lock 锁死行为**。任何试图让它“智能恢复”的想法，都会在某个凌晨三点的线上发布里被证伪。