Composer下载大ZIP包卡在Downloading本质是下载慢或假死，关键在镜像命中、/tmp空间充足、并发配置合理；需用-vvv确认HTTP路径是否走国内镜像，检查/tmp剩余空间，禁用Xdebug，并合理设置parallel-downloads。
composer 本身没有「导出」大文件的功能——你遇到的其实是下载大 ZIP 包（如 laravel/framework、symfony/console）时卡在 Downloading 状态，本质是下载环节慢或假死，不是导出问题。真正有效的加速点就三个：镜像必须命中、临时空间要够、并发配置得当。
怎么确认大 ZIP 包真走国内镜像？
不看 composer config -g repo.packagist 的输出，要看实际 HTTP 请求路径：
- 加
-vvv运行：composer install -vvv 2>&1 | grep "Downloading.*\.zip" - 命中镜像会显示类似：
Downloading https://mirrors.aliyun.com/composer/dist/symfony/console/5a7b9f2.zip✅ - 若出现
https://codeload.github.com/或https://api.github.com/❌，说明该包未被镜像收录，Composer 自动 fallback 到原始源，此时再快的镜像也无效 - 华为云镜像路径必须带
/repository/php/composer/，漏掉会 404 而非 fallback，这是静默失败高发点
/tmp 空间不足会导致大 ZIP 下载“假死”
PHP 的 file_put_contents() 写入大 ZIP 时，若系统 /tmp 分区满或 I/O 饱和，cURL 不报错但阻塞，表现为长时间停在 Downloading 无进度。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 检查：
df -h /tmp，低于 500MB 就危险（一个 Laravel ZIP 解压后常占 300MB+） - 临时改缓存目录避坑：
COMPOSER_CACHE_DIR=/home/www/cache composer install - 禁用 Xdebug：
php -d xdebug.mode=off $(which composer) install，否则流式写入慢 3–5 倍
parallel-downloads 对大文件没分片作用，但影响整体吞吐
parallel-downloads 控制的是「同时发起多少个 HTTP 请求」，不是把单个 ZIP 拆成多线程下载。设为 10，意味着最多并行拉 10 个不同包的 ZIP，而非把一个 50MB 包切成 10 份。
- Composer 2.2+ 支持：
composer config -g parallel-downloads 10 - 旧版需用：
composer config -g concurrent.http.max-parallel-downloads 10 - 值不是越大越好：VPS 内存 ≤1GB 时设 >6 可能触发 OOM；阿里云/华为云镜像本身已支持 HTTP/2 + Range，单连接吞吐足够高，重点还是先确保镜像命中
repos.packagist（多一个 s）。这些细节不验证，光换源也没用。 
