根本原因是各环境镜像配置不一致或被覆盖，统一执行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/并验证-vvv日志中下载域名为mirrors.aliyun.com，再清缓存即可跨平台收敛问题。
不同操作系统下 Composer 下载速度不一致，根本不是系统差异导致的，而是各环境默认没走同一个镜像源，或镜像配置被局部覆盖、缓存未同步 —— 统一用云端镜像能收敛问题，但必须确保配置方式和验证手段跨平台一致。
为什么 macOS / Windows / Linux 表现不同
常见错误现象：同一项目，在 macOS 上 composer install 20 秒完成，Linux CI 里却卡在 Downloading https://api.packagist.org/ 超过 5 分钟；Windows WSL 中偶尔成功，重启后又失败。
这不是“系统慢”，而是各环境的 Composer 配置层级叠加结果：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- macOS 用户常全局配了
repo.packagist，且~/.composer/config.json权限正常 - Linux CI 容器通常无全局配置，或挂载了空
/root/.composer目录，退回到默认源 - Windows（尤其带 WSL）可能同时存在 Git Bash、PowerShell、CMD 三套环境变量和 HOME 路径，
composer config -g实际写入位置不一致 - 所有系统都可能被项目级
composer.json中的repositories字段静默覆盖
统一配置云端镜像的可靠做法
目标是让所有系统都明确、稳定地走同一个镜像，且不依赖本地路径或 shell 环境。
- 用
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（阿里云当前最稳）——注意：-g写入的是用户主目录下的config.json，只要$HOME可写就生效，与终端类型无关 - CI/CD 中避免依赖
-g，改用环境变量 + 显式配置：在构建脚本开头加export COMPOSER_HOME="/tmp/composer"，再运行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，确保路径可控 - 禁止在项目
composer.json里硬编码repositories，除非真需要私有源；若已有，检查是否包含"packagist.org": false，否则 Composer 仍会 fallback 到官方源 - Windows 用户若用 PowerShell，确认未启用
Set-ExecutionPolicy Restricted，否则composer命令可能被拦截或降级执行
跨系统验证是否真走镜像
不能只看 composer config -g repo.packagist 输出，它只说明“配了”，不等于“用了”。真实请求域名才作数。
- 统一加
-vvv参数跑一次安装：composer install -vvv 2>&1 | grep "Downloading\|GET"，确认日志中出现的是mirrors.aliyun.com或mirrors.cloud.tencent.com，而非api.packagist.org - macOS/Linux 可用
curl -I https://mirrors.aliyun.com/composer/packages.json测试连通性；Windows 建议用curl.exe（非 PowerShell 的Invoke-WebRequest），因后者默认禁用 HTTP/2 且 TLS 版本策略不同 - 所有系统都应执行
composer clear-cache后再测试，否则旧缓存可能仍指向海外元数据 - Docker 构建中，务必把
composer clear-cache和镜像配置放在composer install之前，且不要复用未清理的/root/.composer/cache卷
容易被忽略的兼容性细节
看似统一了镜像，但实际请求行为仍受底层影响。这些点在多系统混用时最容易暴露：
-
http-max-concurrent-downloads是唯一有效的并发配置项（parallel-downloads已弃用），设为8比10更稳妥，尤其在低内存容器中 - PHP 的
openssl.cafile必须正确指向系统 CA 包，否则 Windows 和部分 Alpine Linux 镜像会因证书校验失败反复重试 —— 查看php --ini找到 php.ini，确认该行未被注释 - macOS 默认 curl 支持 HTTP/2，但某些 Linux 发行版（如 CentOS 7）的 curl 版本太老，需升级或临时加
--http1.1避免握手卡住 - 所有系统上，
composer diagnose的输出都要检查curl和openssl两行，任一异常都会导致下载阶段不可预测延迟
