浏览器不缓存206响应，仅内存缓冲；cdn需开启range回源并匹配分片策略（如≥10mb文件、4mb分片）才能按字节段缓存；源站必须支持range响应206，否则整链路降级为全量下载。
浏览器对大型音视频的 Range 请求响应（206）本身**不会被浏览器整体缓存为一个完整资源**，而是按“分片”粒度被临时管理——它不走传统 HTTP 缓存（如 disk/memory cache），而是由媒体播放器内部缓冲机制协同处理。真正参与逐级缓存的是 CDN 和中间代理层，它们依据 Range 回源能力与分片缓存策略决定是否、如何缓存每个字节段。
浏览器端：不缓存 206 响应，只做内存缓冲
浏览器收到 206 Partial Content 响应后：
- 不会将该响应写入 HTTP Cache（比如 DevTools 的 “Cache” 标签页里查不到）；
- 而是交由
<video></video>或<audio></audio>元素的媒体引擎（如 Blink 的 Media Source Extensions 或原生解码器）做**内存缓冲（in-memory buffer）**； - 缓冲区大小有限（通常几 MB），播放完或跳过即丢弃，不持久化；
- 拖动进度条时，会发起新的 Range 请求（如
Range: bytes=12000000-15000000），旧缓冲自动释放。
CDN 层：按“分片”缓存，依赖 Range 回源开关
CDN 是否缓存某一段数据，取决于两个关键配置：
Comet AI 浏览器
下载
下载 Comet AI 浏览器，体验由 Perplexity AI 驱动的革命性上网方式。内置 AI 助手可实时总结网页、跨标签页对比信息、自动执行任务。告别繁琐操作，让 AI 成为你的浏览副驾，大幅提升研究与工作效率。支持 Windows、macOS、Android 和 iOS。
- Range 回源必须开启：否则 CDN 向源站发的是无 Range 的全量 GET，拿到 200 响应后只能整块缓存，无法支持后续任意 Range；
- 分片缓存阈值与大小需匹配文件特征：例如腾讯云默认仅对 ≥10MB 文件启用分片缓存，且默认分片为 4MB；若文件 9.5MB，则仍按整文件缓存，失去分片优势。
开启后，CDN 节点收到用户 Range 请求（如 bytes=0-3999999），会向源站发出相同 Range 的回源请求；源站返回 206 + Content-Range: bytes 0-3999999/524288000，CDN 将这一段独立缓存为一个 key（如 sha256(url+range)），后续同 Range 请求直接命中。
源站与反向代理：决定能否响应 206，是整个链路的前提
只有源站（或 Nginx/Apache 等反代）正确支持 Range，整条链路才能生效：
- 静态文件服务（如 Nginx 默认配置）天然支持 Range，返回
Accept-Ranges: bytes； - 动态后端（如 Node.js/Python）若未手动解析
Range头并构造 206 响应，浏览器将降级为全量下载（200），CDN 也无法分片回源； - 源站还需确保
ETag和Last-Modified一致——否则同一文件不同 Range 响应可能被误判为不同资源，导致缓存分裂。
Azure Front Door / Cloudflare 等现代边缘：区块预取 + 分片缓存一体化
这类平台把“分片”逻辑下沉到边缘：
- 收到首个 Range 请求（如开头 8MB），立即以 8MB 区块为单位向源站回源；
- 每收到一个区块，就缓存并实时吐给客户端，同时并发预取下一个区块；
- 后续请求同一区块直接返回，跨区块请求则组合已缓存部分 + 补充回源；
- 只要源站支持 206，边缘就能自动完成分片缓存与流式交付，无需业务侧改造。
