换镜像源不能自动解决下载中断，必须确保配置正确（repo.packagist单数、URL末尾带/、显式指定type）、清除缓存与vendor目录，并注意CI/宝塔用户权限问题。
换镜像源能大幅降低 Composer 下载中断概率，但不是所有“换源”操作都真正生效——多数失败源于配置写错、缓存污染或项目级设置覆盖全局。
为什么换镜像后 still 中断？关键看是否真走镜像
很多人执行了 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，但 composer install -vvv 日志里仍出现 packagist.org 或卡在 provider-2023-07.json，说明镜像根本没生效。
-
repo.packagist必须是单数，写成repos.packagist（多一个 s）就完全无效 - URL 末尾必须带
/：正确是https://mirrors.aliyun.com/composer/，错误是https://mirrors.aliyun.com/composer（少斜杠会拼成/composerpackages.json，404） - 必须显式传
composer作为 type 值：漏掉这个参数，Composer 2.x 会 fallback 到官方源 - 项目根目录下
composer.json若存在"repositories"字段，会直接覆盖全局配置——删掉它或确认里面没写死packagist.phpcomposer.com等已下线域名
中断后重试前必须清理的三个东西
Composer 没有断点续传能力，中断后残留的破损文件会让后续安装反复失败。以下错误出现时，别 retry，先清：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
Failed to extract vendor/package-name: unable to open archive→ 缓存 ZIP 已损坏，rm -rf vendor+composer clear-cache -
Invalid argument supplied for foreach()→vendor/composer/installed.json被截断，删vendor/后自动重建 - 进度条卡在同一个百分比超 2 分钟，且
-vvv显示刚下载完就报错 → 临时 ZIP 文件（vendor/composer/tmp-*.zip）已破损，必须删vendor/
CI 和宝塔环境最容易踩的坑
全局配置在 CI 或宝塔面板中大概率不生效，因为执行用户和配置写入用户不一致：
- 宝塔「一键部署」通常以
www用户运行，而composer config -g默认写入的是root的~/.composer/config.json—— 应改用sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - GitHub Actions / GitLab CI 推荐项目级配置：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g），它会安全写入composer.json的repositories字段，不受用户权限影响 - CI 流水线中务必加
composer clear-cache作为预处理步骤，否则旧缓存可能干扰镜像探测逻辑
真正起作用的从来不是“镜像支持断点续传”，而是它绕过了 packagist.org 和 GitHub 的不稳定链路：DNS 卡顿、TLS 握手失败、中间设备主动断连。配对、清缓、删 vendor，三步缺一不可——少做一步，下次中断还是照常发生。
