背景
zlxlabs/MediaResolverAPI#16：视频号长视频经 GET /api/stream/wechat_channels/{sph_code} 下载在十几 MB 处断流。根因已定位在 resolver 侧（透传式流式转发把下游速率传导给微信 CDN，CDN 约 60 s 推不动数据就关连接），修复在 resolver 落地，本 issue 不阻塞。
建议（纵深防御，非阻塞）
resolver 的流式端点支持标准 Range（Accept-Ranges: bytes，206 + Content-Range）。下游收到 IncompleteRead 时，与其整体重试从 0 开始，不如带 Range: bytes=<已收字节数>- 续拉并追加到已有文件，直到累计长度等于首个响应的 Content-Length。这样 resolver 或中间网络的任何一次断流都只损失一次往返，而不是整段下载。
注意点：
- 续传请求仍需带
X-API-Key。
- 以首个响应的
Content-Length 为总长权威，累计够了才算完成；206 的 Content-Range 起点必须等于已收字节数，不等则丢弃重来。
- 有次数上限，连续零进展即放弃。
证据见 zlxlabs/MediaResolverAPI#16 的机理复核评论。
背景
zlxlabs/MediaResolverAPI#16：视频号长视频经
GET /api/stream/wechat_channels/{sph_code}下载在十几 MB 处断流。根因已定位在 resolver 侧（透传式流式转发把下游速率传导给微信 CDN，CDN 约 60 s 推不动数据就关连接），修复在 resolver 落地，本 issue 不阻塞。建议（纵深防御，非阻塞）
resolver 的流式端点支持标准
Range（Accept-Ranges: bytes，206 +Content-Range）。下游收到IncompleteRead时，与其整体重试从 0 开始，不如带Range: bytes=<已收字节数>-续拉并追加到已有文件，直到累计长度等于首个响应的Content-Length。这样 resolver 或中间网络的任何一次断流都只损失一次往返，而不是整段下载。注意点：
X-API-Key。Content-Length为总长权威，累计够了才算完成；206 的Content-Range起点必须等于已收字节数，不等则丢弃重来。证据见 zlxlabs/MediaResolverAPI#16 的机理复核评论。