低带宽下 Composer 下载卡在 Downloading 阶段，主因是默认下载含 tests/、docs/、.github/ 的完整 ZIP 包，叠加单连接慢速下载、无流式解压及 GitHub CDN 限流；换用阿里云镜像源（composer config -g repo.packagist https://mirrors.aliyun.com/composer/）并清缓存（composer clear-cache）是必须第一步，因其解决 DNS 超时、TLS 握手慢、CDN 绕行等物理链路不通问题，而非单纯加速。
低带宽下 Composer 下载卡在 Downloading 阶段，不是因为你网速差，而是默认行为没做任何带宽适配：它硬要下载含 tests/、docs/、.github/ 的完整 ZIP 包，单连接慢速下载 + 无流式解压 + GitHub CDN 限流，三者叠加直接卡死。
为什么换镜像源是必须第一步，而不是“试试看”
国内直连 packagist.org 本质是走境外链路：DNS 解析常超时、TLS 握手慢、CDN 路由绕行。这不是 Composer 慢，是物理链路不通。镜像源解决的是这三重瓶颈，不是“加速”，而是“让请求能通”。
- 阿里云镜像目前同步最稳：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 切完立刻清缓存：
composer clear-cache，否则旧元数据还在读海外索引 - 验证是否生效：
composer config -g repo.packagist，输出里必须看到阿里云 URL，不是https://packagist.org - 别用已停服的
https://packagist.phpcomposer.com，2025 年底起返回 404 或空响应
parallel-downloads 设多少才不翻车
parallel-downloads 是 Composer 2.2+ 原生并发机制，但它不是“线程越多越快”，而是靠 cURL multi 同时发起多个 HTTP 请求。设太高会触发本地资源竞争，反而失败。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 推荐值是
10：composer config -g parallel-downloads 10 - 超过
15容易报file_put_contents(/tmp/): failed to open stream，说明临时文件冲突 - 某些企业网络对并发敏感，若出现
SSL operation failed，降到6～8更稳妥 - 这个配置只对
composer install有效；composer update仍需串行计算依赖图
如何避免下载包体积过大（剔除 test/doc/.git）
GitHub 默认生成的 dist ZIP 包包含全部文件，哪怕你只用 src。国内主流镜像（阿里、腾讯、华为）已默认启用 sparse archive，自动剔除 tests/、docs/、.github/ 等非运行时目录——但前提是镜像配置正确且缓存已清。
- 确认 sparse 生效：安装后进
vendor/some/package/，检查是否存在tests/目录；若存在，说明没走镜像或镜像未启用 sparse - 若仍需更小体积，强制切 source 模式：
composer install --prefer-source --no-progress，此时走git clone --depth=1，但要求仓库允许匿名 git 访问 - 注意：
--prefer-source在弱网下可能比 dist 更慢，因 git 协议握手开销大，慎用
超时、IPv6 卡顿、缓存失效这些隐形杀手
很多“下载慢”实际是超时中断或协议 fallback 导致的假性卡顿。Composer 默认 http.timeout 是 300 秒，但在低带宽下一个大包很容易超时；IPv6 尝试失败后再 fallback 到 IPv4，每次多等几秒，百个包就累加成分钟级延迟。
- 延长超时：
composer config -g http.timeout 600和composer config -g process-timeout 600 - 强制 IPv4：
COMPOSER_IPV4=1 composer install（Linux/macOS 可写入~/.bashrc永久生效） - 缓存目录权限异常会导致“续传”失败，比重装还麻烦；建议定期检查
~/.composer/cache是否可写 - CI/CD 中不要清理
vendor/，而应复用~/.composer/cache，这才是真正省带宽的地方
真正卡住时，先跑 composer install -v 看停在哪一行，别默认归咎于“网速”。低带宽优化的核心从来不是调参数，而是让每个 HTTP 请求都尽可能短、小、快——镜像、sparse、IPv4、超时、缓存，环环相扣，漏掉一个，其他都白搭。
