执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 可解决多数网络问题，但易因参数错误（如多s、缺composer类型、URL末尾无斜杠等）静默失效，需通过 composer config -g、diagnose 和 -vvv 日志三重验证。
直接执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就能解决绝大多数连接超时、404、下载卡死问题——但这条命令极易静默失效，90% 的失败不是网络问题，而是参数写错。
为什么 composer config -g repo.packagist 看似成功却没用
Composer 2.2+ 对配置字段识别极严格，错一个字符就完全忽略，且不报错、不警告。常见失效原因：
-
repo.packagist写成repos.packagist（多一个 s）或packagist.org：字段存进文件但 Composer 根本不读 - 漏掉中间的
composer类型标识：命令必须是composer config -g repo.packagist composer ...，缺它就 fallback 到官方源 - URL 少末尾斜杠：
https://mirrors.aliyun.com/composer❌ 会拼出/composerpackages.json导致 404；✅ 正确是https://mirrors.aliyun.com/composer/ - Windows 下用 Git Bash 执行后没重开终端：配置写入了
%APPDATA%\Composer\config.json，但当前 shell 还在读旧缓存
验证是否真生效，别信“命令跑完了”
光看终端没报错没用，得查三处：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer config -g repo.packagist：输出必须是{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}，空或报错说明没写对 - 运行
composer diagnose：找Repo packagist.org:这一行，后面地址必须是你配的镜像域名 - 运行
composer update -vvv 2>&1 | grep -i "GET\|downloading"：日志里出现的请求 URL 必须含mirrors.aliyun.com，且路径是/packages.json或/p2/开头
项目级配置比全局更可靠，尤其在 CI 和团队协作中
只要项目根目录下 composer.json 有 "repositories" 字段（哪怕只有一行空数组），全局设置就自动失效——这不是 bug，是设计行为。
- 进项目目录后执行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g），它会自动写入composer.json的"repositories"对象中 - 若原
composer.json的"repositories"是数组（如[{"type":"package",...}]），该命令会失败，需先手动改为对象格式："repositories": {"packagist": {}} - 改完务必运行
composer clear-cache，否则旧packages.json缓存仍会干扰版本解析 - 如果
composer.lock是之前用官方源生成的，首次install可能报 hash 不匹配，删掉vendor/和composer.lock重来
真正容易被忽略的是：镜像地址只是元数据加速，实际 zip 包仍可能从 GitHub 拉（尤其当 composer.json 里硬写了 dist-url）。所以验证时一定盯住 -vvv 日志里的 GET 请求，而不是只看“下载快了”。
