风向突然变了｜91视频——关于缓存设置的说法 | 背后原因比你想的复杂！！我先把要点列出来
引子 最近关于“91视频修改缓存设置导致播放/更新异常”的讨论越发激烈。表面上看像是一次简单的配置调整，深入分析会发现牵扯到 CDN 策略、浏览器缓存、缓存失效机制、个性化内容和合规性等多层因素。下面先把要点列出来，然后逐条拆解、给出可落地的应对建议。
要点（先列要点）
- CDN 与源站缓存策略不一致会造成客户端体验波动。
- 浏览器与 CDN 的缓存控制Header（Cache-Control / Expires / Vary）设置极其关键。
- 动态内容（登录态/用户定制）与静态资源需区分缓存策略。
- 缓存失效（cache invalidation）是坑——错误做法会导致旧内容长期存在或频繁击穿。
- 版本化/缓存穿透（cache busting）是常用但需谨慎使用，尤其影响带宽与成本。
- 区域与运营商差异会放大“风向改变”的感知。
- 数据统计与埋点在缓存层面会失真，需要特殊处理。
- 推荐的排查步骤与实践清单（可操作性最高）。
逐条拆解与实操建议
1) CDN 与源站缓存策略不一致的影响 解释：很多团队只是把缓存策略配置在源站（如设置 Cache-Control），但 CDN 有自己的默认策略或重写规则。如果 CDN 缓存 TTL 与源站不同步，用户在不同节点看到的版本会不一致，进而导致“风向突然变了”的错觉。 应对：审查 CDN 配置面板，查看每个路由/路径的缓存规则。用 curl 加上 -I 查看经过 CDN 的响应头，确认实际生效的是哪一套 Header。
2) Cache-Control / Expires / Vary 等 Header 的魔力与陷阱 解释：Cache-Control 的 no-cache、no-store、max-age、s-maxage、public/private、must-revalidate 等指令控制着不同层面的缓存行为。Vary 头告诉中间缓存如何区分请求（如根据 Cookie 或 User-Agent），但滥用会导致缓存命中率急剧下降。 应对建议：
- 静态资源（视频封面、JS/CSS）建议设置长 TTL 并使用文件名版本号（例如 v1234.jpg）。Header 示例：Cache-Control: public, max-age=31536000, immutable
- 动态页面与带 Cookie 的接口使用 private 或 s-maxage=0 加上 no-store/ no-cache 视需要。示例：Cache-Control: no-cache, no-store, must-revalidate
- 谨慎使用 Vary: Cookie 或 Vary: Authorization，会让 CDN 为每个用户/状态生成不同缓存，命中率下降。
3) 区分静态与动态，避免把“动态”当成静态缓存 解释：视频播放页常常有个性化推荐、播放历史、点赞状态等。把这些页面整体缓存，会导致用户看到错位信息或隐私泄露。 实务操作：
- 对页面做模块化渲染：把公共静态部分由 CDN 缓存；把用户相关模块通过 AJAX 请求按需拉取并设置短 TTL 或不缓存。
- 使用 Edge Side Includes (ESI) 或 SSR + 客户端补偿策略，平衡性能与准确性。
4) 缓存失效（invalidation / purge）策略 解释：当资源更新（例如封面、标题、文件）时，如何快速让 CDN/浏览器丢弃旧版本是关键。不当手段会导致要么大量清空缓存增加成本，要么延迟更新引发用户投诉。 策略建议：
- 优先采用版本化 URL（最可靠、最简单）。更新时换 URL，CDN 自动获取新资源。
- 若必须 purge：使用 CDN 的批量清理 API，按需精确清理而不是模糊全站清理。
- 在发布流程中把清理步骤作为必选项纳入 CI/CD。
5) 版本化与缓存穿透的利与弊 说明：版本化（query string 或文件名）可以确保更新即时生效，但频繁变更会导致 CDN 缓存失效频繁，增加回源成本。 建议：
- 静态大文件用版本化（例如视频封面、静态 JS/CSS）；
- 对小变更（如元数据）采用 header 驱动或局部替换，避免每次都改大文件名。
6) 区域、运营商与节点差异放大感知 说明：同一资源在不同 CDN 节点可能缓存策略不同或同步延迟，用户在不同地区看到的内容和性能感受会有差别，这也是“风向突然变了”的来源之一。 应对：
- 建立多点监控（不同地区、不同运营商）。用合成监测或真实用户监测（RUM）来捕捉差异。
- 对关键资源在主要节点做预热（prewarm）或主动回源缓存。
7) 埋点、统计与缓存的相互影响 说明：缓存会拦截很多原本该上报的请求，导致 PV/播放统计偏差，或把用户行为统计混淆。 落地做法：
- 把关键埋点作为不被 CDN 缓存的请求（set no-cache 或直接走到源）。
- 使用 client-side 上报（JS 在客户端发起上报），保证即便页面被缓存，行为也能被实时记录。
排查流程（便于复制的步骤）
- 用 curl -I 检查响应头（来源：是否有 via、x-cache 等）；
- 在浏览器 DevTools Network 查看是否从 disk cache/memory cache/ 304 返回；
- 验证 CDN 管理面板里的规则与源站响应头是否冲突；
- 针对单用户差异，模拟带 Cookie/不带 Cookie 的请求，观察 Vary 和 Set-Cookie 行为；
- 如果遇到更新延迟，检查是否用了版本化或是否需要触发 purge；确认 purge 是否成功；
- 用 RUM 数据或合成监测确认不同地区的差异。
快速检查命令举例
- 查看经过 CDN 的响应头：curl -I -H "Cache-Control:" https://your-domain/path
- 强制不使用缓存的请求（浏览器等效）：curl -I -H "Cache-Control: no-cache" https://your-domain/path
结语与落地清单（3分钟自检）
- 有没有把静态和动态分开缓存？
- CDN 与源站的 Header 是否一致，并且遵循预期？
- 更新是否通过版本化或精确 purge 触达用户？
- 是否监控不同地区与运营商的响应差异？
- 埋点数据是否因缓存而失真？是否已经补救？