必须换国内镜像源，因默认连packagist.org导致DNS解析慢、TLS握手卡、首字节延迟高；配置需严格满足键名repo.packagist、type值composer、URL末尾带/三要素，且须执行composer clear-cache并删vendor和composer.lock后重装。
composer 下载慢不是网络差，是默认连 packagist.org——DNS 解析慢、TLS 握手卡、首字节延迟高，甚至直接超时。换镜像不是“试试看”，而是必须做的第一步，且必须配对、配全、配准。
composer config -g repo.packagist 命令为什么总不生效
这条命令不报错，但实际配置被忽略，常见原因就三个：
-
repo.packagist键名写成了repos.packagist（多一个 s）——Composer 2.x+ 直接跳过，不提示也不警告 - 漏掉中间的
composer这个 type 参数：composer config -g repo.packagist https://mirrors.aliyun.com/composer/❌，必须是composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/✅ - URL 末尾缺
/：https://mirrors.aliyun.com/composer❌，会拼出/composerpackages.json导致 404；正确是https://mirrors.aliyun.com/composer/✅
验证是否真写进去了：运行 composer config -g repo.packagist。输出必须是完整 URL 字符串或类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 的 JSON。如果为空、null 或仍是 https://packagist.org，说明压根没写成功。
换源后仍卡在 Downloading？先清缓存再重装
镜像只加速下载，但旧缓存里存着 packagist.org 的元数据，composer 会优先读缓存并尝试从旧地址校验——结果就是卡在 DNS 或 TLS 握手，根本没发请求过去。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 必须执行：
composer clear-cache - 删掉
vendor/和composer.lock - 再跑：
composer install --no-cache（禁用缓存强制走新源） - 别试图保留旧
composer.lock——它记录的是旧源的包哈希，和镜像返回的元数据不兼容，必然报hash does not match
项目级配置比全局更可靠，尤其适合 CI/CD 和团队协作
全局配置（-g）在宝塔、Docker、CI 构建中极易因用户权限错位而失效——比如你在终端用 root 配了，但构建脚本以 www-data 或 runner 用户运行，根本读不到 /root/.composer/config.json。
- 进项目根目录后运行（不加
-g）：composer config repo.packagist composer https://mirrors.aliyun.com/composer/ - 该命令自动向
composer.json的repositories字段追加packagist条目，不覆盖已有私有源 - 配置随代码提交，新人拉完即用，行为一致
- CI 构建时不用额外 setup，每次读取最新设置
- 如果项目已有
"repositories": {}，别手动编辑 JSON——格式错一个逗号就导致composer install报错
验证是否真走镜像，不能只看 config 输出
光跑 composer config -g repo.packagist 显示 URL 没用，得看到网络请求实际打到镜像域名才算数。
- 实测命令：
composer show monolog/monolog -vvv 2>&1 | grep "Downloading" - 日志里必须出现
mirrors.aliyun.com或对应镜像域名 - 如果还看到
packagist.org，说明 fallback 了，配置被覆盖或未生效 - 项目级
repositories字段会直接覆盖全局配置，可用composer config --list和composer config --list --global对比确认实际生效的是哪个
最常被忽略的是缓存残留和权限错位——哪怕镜像 URL 写对了，clear-cache 没跑，或者 www 用户下没配，照样卡在 downloading。
