Composer不支持HTTP Range分片下载，因其设计要求完整获取带sha256签名的ZIP包以确保校验可信；底层无分片调度机制，且源站zipball URL含短期token导致Range请求不可复用。
Composer 不支持利用 HTTP Range 请求做分片下载。
它压根没这个机制，也不依赖服务器的 Accept-Ranges 响应头，所有 ZIP 包都当作完整文件一次性下载 —— 即使你手动加 Range: bytes=0-1048575 头，Composer 也不会识别、拆解或拼接。
为什么 Composer 不用 Range 分片？
根本原因不在技术限制，而在设计取舍：
-
Composer下载的是带签名的 ZIP 包（含sha256校验），必须完整拿到才能验证完整性；分片下载后拼接再校验，等于把校验逻辑从“一次可信”降级为“多段可信+拼接可信”，风险不可控 - GitHub、GitLab 等源站对 zipball URL 使用短期 token，
Range请求无法复用同一 URL 的不同区间 —— 第二个请求大概率返回404或416 -
HttpDownloader底层基于stream_context_create或cURL单次请求，没有分片调度、临时文件管理、断点状态持久化等配套模块
遇到大包下载中断，实际能做什么？
别指望 Range 续传，真正有效的动作是绕过下载环节本身：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 手动用
wget -c或curl -C -下载 ZIP 到缓存目录：~/.composer/cache/files/{vendor}/{package}/{hash}.zip - 确认
COMPOSER_CACHE_DIR可写且空间充足，否则缓存失效，每次都是重下 - 删掉损坏的临时文件：
rm -f vendor/composer/tmp-*.zip，否则composer install会卡在解压前 - 遇到
sha256 hash mismatch，说明缓存里存了坏包，必须清空对应包的缓存项，不能只删 vendor
并发下载 ≠ 分片下载，但能缓解大包卡顿
Composer 的并发（如通过 composer-plugin-parallel-downloader）只是同时发起多个完整 ZIP 请求，每个仍是全量下载：
- 默认串行是因为底层
stream不支持并行，不是故意慢 - 启用并发后，若镜像源不支持
Range（绝大多数都不支持），反而可能触发416 Requested Range Not Satisfiable - 真正提速靠
--prefer-dist+ 国内镜像源，而不是调高并发数 —— 大包瓶颈在单连接吞吐，不在请求数
Range 分片的场景（比如前端下载 GB 级安装包、视频切片加载），得自己用 axios 或 fetch + ReadableStream 实现，Composer 的职责边界不覆盖这类需求。它只管“拿到一个校验通过的 ZIP”，不管你怎么拿。 
