真的有点离谱，刷新91视频最折磨人的不是时间，是缓存管理反复拉扯（越早知道越好）

谁没遇到过这样的场景：手机上点开视频，缓冲一下可以看；结果一刷新，进度丢了、又开始重下、网络流量被吞得一干二净。很多人以为是“网慢”，但更常见的真正凶手是缓存策略和缓存层之间的拉扯——浏览器、CDN、服务端、还有有时候的 Service Worker，彼此的“指令”不一致，就会反复把用户拉回重新请求和下载的地狱。

先说个直观的比喻：想象你家门口有好几个快递柜（CDN 边缘节点），快递员（浏览器）先去最近的柜子取，但柜子里每个包裹都有不同的保质期和标签（Cache-Control、ETag、Expires）。如果标签写得乱七八糟，快递员就会不停地跑到仓库（源站）确认或者直接重新取包裹，最后你看着快递员跑来跑去的样子，比等快递慢还闹心。

缓存拉扯具体是怎么发生的（略微技术化但必要）

• 浏览器缓存：浏览器会根据 Cache-Control、Expires、ETag 等头决定是否使用本地缓存或发起条件请求。如果服务器下发 no-cache 或者频繁改变 ETag，就会强制重新验证或重新下载。
• CDN 缓存：CDN 在边缘节点缓存静态资源或视频分片。边缘缓存的 TTL、是否带 Cookie、是否根据查询字符串区分等设置，会影响命中率。错误的配置会导致边缘不停地向源站拉数据。
• 分段流/播放器行为：HLS/DASH 等分段流协议把视频拆成许多小片段。播放器对片段的请求策略（预取、并发请求、断点续传）以及服务器对 Range 请求的支持，会直接影响是否需要重复下载。
• Service Worker / App 缓存：如果站点用了 Service Worker，不同的缓存策略（cache-first、network-first）与版本更新策略（skipWaiting、clients.claim）处理不当，会造成旧资源被一直用或频繁全部重新拉取。
• 条件请求与验证：ETag 和 Last-Modified 能减少流量，但若生成策略不稳定（每次构建就变），就会失去意义，响应总是 200 而非 304。

普通用户能做的，越早知道越省心

• 如果遇到不断重下或刷新后进度被重置，先试试无痕/隐身模式，看问题是否与本地缓存或扩展有关。
• 在浏览器开发者工具的 Network 面板里勾选 Disable cache（仅在 DevTools 打开时生效），可以观察每次请求的真实返回头和是否命中缓存。
• 长期用数据流量看视频，尽量开启播放器的“自动播放下一个/预加载”控制，或关闭预加载以节省流量（根据你的网络情况调节）。
• 手机端遇到问题时，尝试清理应用缓存或重启应用，尤其是遇到 Service Worker 或旧版本资源残留时。
• 若你能访问别的镜像/域名试试，或者换到一个稳定的 Wi‑Fi，看是否是某个 CDN 节点的问题。

站长 / 开发者更应该知道并修正的点（实际而具体）

• 静态资源（JS/CSS/图片、视频分片）采用版本化文件名 + 长缓存（Cache-Control: public, max-age=31536000, immutable）。当内容变化时通过文件名变更来做缓存失效。
• 对于需要频繁更新的资源，使用短 TTL 或者 stale-while-revalidate，让边缘能返回旧内容同时后台异步拉新，用户体验更平滑。
• 避免在视频文件响应中加入不必要的 Cookie，因为带 Cookie 的请求通常不会被 CDN 高效缓存。
• 支持并正确处理 Range 请求，这对断点续传和播放器跳转至关重要。服务器需返回 Accept-Ranges，正确处理 206 Partial Content。
• ETag 的生成策略要稳定且有意义（基于内容哈希），否则每次构建导致的变化会让条件请求失效，造成频繁 200 下载。
• 配置 Service Worker 时，区分好静态资源（cache-first）和接口数据 / 播放列表（network-first）。更新策略要设计好：新版本发布时提示用户刷新而不是悄悄让客户端不停拉取。
• 对 HLS/DASH 等分段流：合理设置分片的 Cache-Control，分片可以设置较长缓存，清单文件（manifest）则短一些。用 CDN 缓存分片并在需要时通过快速清除/版本化清单来失效。
• 使用 CDN 的边缘编入日志与缓存命中率监控，设置自动化的缓存清理策略（例如基于版本号的路径而非频繁 purge）。
• 在响应头中使用 stale-if-error，这样当源站不可用时边缘可以返回过期缓存，避免用户直接看见错误。

排查问题的实用步骤（快速定位）

1. 在浏览器 DevTools 查看每个视频分片或主文件的响应头（Cache-Control、Age、ETag、Last-Modified、Content-Range）。
2. 检查是否每次都是 200 或偶尔 304，304 说明条件请求生效，200 则说明浏览器或 CDN没命中缓存或直接返回新内容。
3. 在不同网络、不同设备上对比，判断是某个 CDN 节点还是全网问题。
4. 暂时绕过 CDN（直连源站）做测试，确认问题出在 CDN 配置还是源站响应。
5. 查看 Service Worker 的安装/激活/缓存策略日志，确认是不是 Service Worker 强制替你做了“刷新”。

用户体验补救与沟通

• 若无法立刻改架构，至少在播放器加上清晰的缓冲提示、进度保存、和出错重试机制。让用户知道“这不是你网络绝对出问题，我们在努力恢复”比让他们反复刷新要温和很多。
• 在公告/帮助页解释缓存更新策略（例如新版本发布会导致短时间内刷新或重新缓存），能减少用户困惑和投诉。