直接换阿里云镜像源可解决90%的composer install卡顿问题，需验证配置生效、清理缓存、注意项目级覆盖及镜像同步延迟等细节。
直接换阿里云镜像源就能解决 90% 的 composer install 卡在 downloading 的问题，不用调参数、不用改 hosts、更不用科学上网——前提是确认配置真生效了。
怎么确认镜像源真的生效了
很多人跑了 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就以为完事，结果还是卡。关键得验证输出是否对：
- 运行
composer config -g repo.packagist，正确输出应是{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}或纯 URL 字符串（新版 Composer）；如果为空、是https://packagist.org或旧格式{"packagist.org": {...}}，说明没写进去 - 项目级配置会覆盖全局：检查当前目录下
composer.json是否有repositories字段，有的话优先用它，-g配的就无效 - 临时加
-vvv看日志里实际请求的域名——比如出现GET https://mirrors.aliyun.com/composer/p2/monolog/monolog.json才算真正走镜像
换源后还卡？先清缓存再试
镜像换了但缓存还是旧的，Composer 可能继续从本地缓存里找元数据，而缓存索引本身可能指向 packagist.org。不清理，等于白换：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（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，避免残留逻辑干扰 - 某些 CI 环境或 Docker 构建中，缓存路径可能被挂载或复用，需确认
cache-dir是否被持久化
为什么用了镜像，某些包还是从 packagist.org 下载
不是所有包都走你配的镜像源，以下情况会绕过镜像：
- 项目
composer.json里显式写了repositories（比如私有 Git 源、Satis 服务），Composer 会按顺序查，镜像只负责packagist这一项 - 用了
path类型仓库（如"../my-local-package"），完全不走网络，自然也不走镜像 - 包刚发布不到 5–10 分钟，阿里云/腾讯云镜像还没同步，会触发 Composer 2.2+ 默认的 fallback 机制，自动切回
packagist.org查一次——这是正常行为，不是配置失败 - 某些废弃包（
abandoned）会被 Composer 主动回源拉取原始信息，用于兼容提示
别碰 packagist.phpcomposer.com
这个地址早在 2022 年就已停用，现在访问会 404 或跳转失败。很多老教程还在提，但实际执行只会让 composer config -g 写入一个无效源，后续所有操作都卡在 DNS 解析或连接超时阶段：
- 只用阿里云：
https://mirrors.aliyun.com/composer/（同步快、稳定） - 或腾讯云：
https://mirrors.cloud.tencent.com/composer/（CDN 覆盖好，适合南方网络） - 中科大源也行，但日常开发中阿里云出问题的概率最低
- 如果发现某个新包在阿里云镜像里找不到，先等 10 分钟再试，别急着换源或关 fallback
