换镜像源不能直接省流量，因其仅切换请求节点而不压缩包体积；真正省流量需启用sparse archive（最小可用包），依赖正确配置镜像url、清缓存、禁用官方源及合理设置并发下载数。
为什么换镜像源不能直接省流量
换镜像源本身不压缩包体积，只是把请求从 packagist.org 切到国内节点；但若仍下载完整 ZIP（含 tests/、docs/、.github/），带宽消耗几乎没变。真正省流量的关键是让 Composer 拉「最小可用包」，而不是「默认全量包」。
必须启用 sparse archive 镜像源
阿里云、腾讯云、华为云的 Composer 镜像站默认已启用 sparse archive，但前提是：你配的是正确 URL 且缓存已清。否则 Composer 仍会 fallback 到 GitHub 原始 ZIP。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意末尾无/，这是 HTTPS 正确写法） - 立刻执行
composer clear-cache，否则旧元数据还在读 GitHub 的 full ZIP 地址 - 验证是否生效：
composer install --no-progress -vvv日志里应出现Downloading https://mirrors.aliyun.com/composer/dists/...，且安装后进vendor/some/package/查不到tests/目录 - 若仍有
tests/，说明没走镜像——常见原因是项目级composer.json里写了repositories但没加"packagist.org": false
并发下载数设太高反而浪费带宽
低带宽下，并发不是越多越好。http-max-concurrent-downloads 控制同时发起的 HTTP 请求个数，设高了会触发镜像限流、本地临时文件冲突，甚至因 TCP 拥塞重传拉低整体吞吐。
- 推荐值是
10：composer config -g http-max-concurrent-downloads 10 - 老旧服务器或 CI 环境建议降到
6～8，避免file_put_contents(/tmp/): failed to open stream - 别用已废弃的
parallel-downloads，它在 Composer 2.2+ 中已被替换 - 加
--no-progress可减少 CLI 输出开销，在弱网终端上也更稳定
哪些操作会悄悄绕过镜像、白费带宽
你以为在走镜像，其实请求早已发往 packagist.org 或 GitHub，白白消耗本就紧张的带宽。
- 项目
composer.json里定义了repositories字段但没显式禁用官方源："packagist.org": false必须加上，否则元数据请求仍走海外 - 依赖中包含已废弃（
abandoned）包，Composer 会尝试回源拉 provider 信息 - 新发布的包尚未同步到镜像（通常延迟 5–30 分钟），此时
composer show vendor/package -vvv会显示请求发往repo.packagist.org - 用了停服镜像如
https://packagist.phpcomposer.com，返回 404 后 Composer 默默重试三次再 fallback，全程空耗带宽
