大HTML视频在Chrome、Safari中无法缓存的问题排查与解决求助

这个问题我之前帮开发者排查过类似的情况，核心原因是Chrome和Safari对大文件的分段Range请求（206状态码）的缓存策略和Firefox存在差异，结合你的测试结果（小视频正常、大视频异常），具体原因和解决办法如下：

为什么大视频无法正常缓存？ #

• 分段请求的缓存合并逻辑差异：Firefox会将多次Range请求返回的片段合并为一个完整的缓存条目，而Chrome和Safari在处理大文件的多段206响应时，不会默认把这些片段关联成一个完整的资源缓存。当你调用视频定位API时，浏览器会认为需要的片段没有被缓存，从而重复发起Range请求。
• 大文件的缓存阈值限制：Chrome和Safari对单个缓存资源的大小有隐性阈值（不同版本略有差异，通常在50-100MB左右）。你的170MB视频超过了这个阈值，浏览器会将其存入临时缓存而非持久缓存，页面刷新后临时缓存被清理，自然无法命中缓存。而9MB的小视频在阈值内，能正常存入持久缓存。
• 缺少缓存验证头的辅助：虽然你设置了cache-control，但Chrome和Safari在处理分段缓存时，依赖ETag或Last-Modified头来验证缓存片段的有效性。如果没有这些头，浏览器会更倾向于重新发起请求，而不是复用已有的片段缓存。

可行的解决方案 #

1. 补充缓存验证头 #

在服务器响应中添加ETag（基于文件内容生成的唯一标识）和Last-Modified头，让浏览器能准确判断已缓存的片段是否有效。例如：

ETag: "abc123-def456"
Last-Modified: Wed, 15 Nov 2023 12:00:00 GMT

这样Chrome和Safari在发起Range请求时，会先发送If-Range头验证缓存，避免重复下载已有的片段。

2. 调整视频分段策略（推荐） #

将170MB的大视频拆分为多个几MB的小片段（比如采用HLS或DASH协议），每个片段单独作为一个资源请求。这样每个小片段都能被浏览器正常缓存，定位视频时只需请求对应时间点的片段，不会重复请求已缓存的内容，同时也能降低单请求的带宽压力。

3. 尝试禁用Range请求（权衡使用） #

如果你的业务场景不需要断点续传，可以在服务器端设置Accept-Ranges: none，强制浏览器发起完整的GET请求（状态码200）而非分段的206请求。这样大视频会作为一个完整资源被缓存，但代价是失去断点续传功能，且首次加载时间会更长。

4. 使用Service Worker手动控制缓存 #

借助Angular的Service Worker（或自定义Service Worker）拦截视频的Range请求，手动缓存所有返回的片段，并在后续请求时优先返回缓存的内容。这种方式可以完全绕过浏览器原生的大文件缓存限制，自定义缓存逻辑，但需要额外的开发工作量。

5. 检查浏览器缓存配额 #

虽然这个操作对用户不友好，但可以让用户检查Chrome/Safari的缓存存储设置，确保没有设置过小的缓存配额。不过这属于用户端操作，只能作为辅助排查手段，不能作为通用解决方案。

内容的提问来源于stack exchange，提问作者Rohan Khajuria