换镜像不解决超时，仅加速下载；真正卡住主因是http.timeout未调够（需设300～600）且缓存未彻底清理（需手动删除磁盘缓存目录并执行clear-cache），验证镜像生效须运行composer config -g repo.packagist输出完整json对象。
换镜像本身不解决超时，只解决下载慢；真正卡住时，90% 是 http.timeout 没调够 + 缓存没清干净。
怎么确认当前生效的是哪个镜像源
别靠猜或重装，直接查配置：
- 运行
composer config -g repo.packagist，输出必须是{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}才算成功 - 如果返回空、报错，或仍是
https://packagist.org，说明全局配置未写入或被覆盖 - 再跑一次
composer config -g -l | grep repo，看有没有残留的repos.packagist（旧版写法，v2 不认）
为什么改了镜像还卡在 Downloading
镜像地址能 curl -I https://mirrors.aliyun.com/composer/packages.json 通 ≠ Composer 能用——它还受本地网络路径中 TLS 握手、DNS 解析、代理中间人等环节影响。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
http.timeout默认只有 60 秒，阿里云首字节延迟高时极易触发失败 - 必须设为 300～600：
composer config -g http.timeout 600 - 若项目
composer.json里硬写了"repositories"字段，它会优先级高于全局镜像，得手动删掉或改成阿里云地址 - 公司内网走代理时，
composer config -g http-proxy必须显式设置，否则请求直连且被限速
清缓存不是 run composer clear-cache 就完事
composer clear-cache 只清内存级缓存，元数据（如 packages.json）仍留在磁盘，下次请求还会加载过期内容。
- Linux/macOS：删掉
~/.composer/cache/repo/https---packagist.org/ - Windows：删掉
%APPDATA%\Composer\Cache\repo\https---packagist.org\ - 再补一句
composer clear-cache，确保全清 - 验证是否真生效：运行
composer install -vvv，日志里出现mirrors.aliyun.com才算落地
CI/CD 中镜像配置容易失效的点
容器每次启动都是干净环境，靠 -g 写全局配置会丢失，必须用环境变量兜底。
- 镜像地址必须用
COMPOSER_REPO_PACKAGIST=https://mirrors.aliyun.com/composer/，比命令行更可靠 -
COMPOSER_PROCESS_TIMEOUT=1200要配，它能覆盖插件启动的子进程（比如 post-install-cmd 脚本） - 加
--prefer-dist强制走 zip 包，避免卡在git clone - 别信
composer install --no-plugins能绕过问题——很多私有包 installer 本身就是插件，禁用后反而报错
最常被忽略的是：镜像只加速 public 包，对 git@、https://github.com/xxx 这类 VCS 源完全无效。如果你的 composer.json 里混着私有仓库，得单独处理它们的超时和代理，不能指望一个镜像全包圆。
