根本原因是全局命令只读取~/.composer/config.json和环境变量，忽略项目配置；常见失效包括镜像配置漏写type参数、sudo误写入/root/.composer、php禁用putenv()导致静默失败、缓存未清等。
全局安装超时不是网络慢，而是 Composer 默认不读项目配置，只依赖全局配置和环境变量——没配对、没清缓、没验证，就一定会卡在 downloading。
为什么 composer global require 总是卡住
根本原因在于：全局命令完全忽略当前项目的 composer.json 和 composer.lock，只查 ~/.composer/config.json 和环境变量。常见失效场景包括：
- 执行
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/时漏掉中间的composer类型参数（正确写法必须带），命令静默失败 - 用
sudo执行配置，结果写进了/root/.composer/config.json，但composer global require是以当前用户运行，读的是$HOME/.composer/config.json - PHP 禁用了
putenv()（见php.ini中disable_functions），导致composer config -g写配置失败却不报错 - 没清缓存，旧的
packages.json元数据还在本地，根本不会发网络请求，自然看不到镜像是否生效
怎么确认全局镜像真生效了
别只信 composer config -g repo.packagist 的输出，要实测请求路径：
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 - 再执行带调试的日志命令：
composer global require monolog/monolog -vvv 2>&1 | grep "Downloading\|packages.json" - 如果看到
Downloading https://mirrors.aliyun.com/composer/packages.json，说明镜像已生效；若仍是https://packagist.org/packages.json，说明配置没起作用
process-timeout 和 http-basic-timeout 必须一起调
这两个参数独立生效，只改一个大概率还会超时：
-
process-timeout控制整个命令生命周期（含解压、运行钩子等），默认仅 300 秒。建议设为1800：composer config -g process-timeout 1800 -
http-basic-timeout（Composer 2.2+ 支持）控制单次 HTTP 请求，比如拉 ZIP 包。默认仅 60 秒，大包很容易触发。建议设为300：composer config -g http-basic-timeout 300 - 临时调试可用命令行参数：
composer global require hirak/prestissimo --timeout=1200 --http-basic-timeout=240
容易被忽略的细节
全局安装慢或超时，常被归因于“网络差”，但真正卡点往往藏在更底层：
- 私有 Git 包（如
git@github.com:user/repo.git）不会走镜像，必须改用 HTTPS 克隆，或配 GitHub Token（写进~/.composer/auth.json） - 某些插件（如
composer-require-checker）会触发额外的元数据请求，若未禁用并行下载，连接压力会陡增 —— 可加composer config -g parallel-downloads 5 - Windows 下长路径或符号链接可能拖慢 autoload 生成，但这个阶段不报超时，只表现为卡在
Generating autoload files后无响应
