看似偶然，其实是设计：同样是91网页版，体验差异怎么来的？答案藏在缓存管理
同一份网页在不同用户、不同设备上表现不一致，常被误以为“网络运气”或“用户设备有问题”。实际上，绝大多数差异都能追溯到一组有意或无意的缓存决策：浏览器缓存、服务工作者（Service Worker）、CDN（内容分发网络）、代理缓存、以及应用内的本地存储。本文把这些层次拆开，讲清楚为什么会出现差异、如何定位问题，以及工程上可落地的解决方案。
一、缓存为什么会造成不同体验
- 多层缓存并行存在：浏览器会缓存静态资源（CSS/JS/图片）；CDN在边缘节点缓存请求；企业代理或移动运营商可能有额外缓存；Service Worker 可以拦截并返回已缓存内容。不同设备可能命中不同层，导致版本不一致或更新延迟。
- 缓存策略不一致：静态资源和接口可能被设置了不同的缓存头（Cache-Control、ETag 等），某些资源无限期缓存、某些又每次必须验证，结果体验差别很大。
- Service Worker 的生命周期与更新逻辑：老旧的 SW 仍在活跃会拦截请求并返回旧缓存，用户即便刷新页面也可能得到旧内容，除非 SW 正确处理更新与激活。
- CDN 与缓存键策略：CDN 的 cache key（是否包含 Cookie、Query String、Header）不同，会让同一 URL 在不同请求下产生不同缓存命中率。
- 隐私策略与浏览器差异：例如 Safari 的 ITP、浏览器隐私模式或存储限制，会影响缓存分区与可用存储，导致体验差异。
- 本地存储与离线策略：IndexedDB/localStorage 的使用会让同一页面在离线或弱网下表现出不同结果，视实现细节而定。
二、常见误区与具体成因
- 误以为“刷新就好”：普通刷新（F5）在有 Service Worker 的场景下不一定触发资源重新拉取；需要在 SW 中实现 skipWaiting + clients.claim 或在控制台执行更新。
- 只看浏览器缓存，忽视 CDN：开发环境看到即时更改，但生产经常被 CDN 的边缘缓存拦住；没有正确设置 s-maxage 或未执行 CDN 清理会导致“旧版本仍在跑”。
- ETag 与 Last-Modified 被误用：如果后端总返回同一个 ETag 即使内容变了，浏览器会认为未变化，从而不拉新资源。正确的做法是保证 ETag 与内容一致或使用基于内容的文件名版本化。
- 忽略 Vary 头：当响应依赖于 Header（如 Accept-Encoding、Cookie）时，未设置 Vary 会导致缓存混淆；例如带 Cookie 的响应被共享到不带 Cookie 的用户上。
三、关键技术细节（工程师必读）
- Cache-Control 示例：
- 静态资源（版本化文件名）：Cache-Control: public, max-age=31536000, immutable
- HTML 主文档或 API：Cache-Control: no-cache (代表每次回源验证)，或 no-store（绝对不缓存）
- CDN 专用：s-maxage 用于覆盖共享缓存（CDN）TTL
- 校验与协商缓存：
- ETag：服务器应返回基于内容的 ETag（例如文件 hash），客户端用 If-None-Match 验证
- Last-Modified / If-Modified-Since：适合内容更新不频繁且精度不要求太高的场景
- Vary 头：在根据 Cookie、Accept-Encoding、User-Agent 等返回不同内容时加上 Vary 列表，避免错误共享缓存
- 服务工作者要点：
- update flow：install -> activate；要实现快速生效可在 install 后调用 self.skipWaiting()，在 activate 中调用 clients.claim()
- 缓存命名与清理：使用带版本号的 cacheName（如 app-v2026-02-01），在 activate 阶段清理旧 cache
- 策略选择：静态资源用 cache-first，HTML 或 API 用 network-first 或 stale-while-revalidate（取决于业务对新鲜度的要求）
- 文件名指纹化（cache busting）：通过构建产物名嵌入 hash（app.abcd1234.js）是解决长期缓存最稳妥的方法，配合 long max-age 使用。
四、诊断步骤（快速定位）
- 打开浏览器开发者工具 → Network，勾选 Disable cache（注意：需在 DevTools 打开时生效），观察请求是否回源与响应头。
- 检查响应头：Cache-Control、ETag、Last-Modified、Age、X-Cache（CDN 命中信息）、Vary。
- 在 Application 面板查看 Service Worker 的状态与 Cache Storage 内容，尝试 Unregister SW 并刷新看是否变化。
- 使用 curl -I https://example.com/ 跟踪服务器返回的头，模拟不同请求头（-H "Cookie: …"）看缓存键是否敏感。
- 检查 CDN 管理后台的 cache-hit 日志与 purge 历史，确认是否有未清理的旧缓存。
五、最佳实践清单（可直接落地）
- 静态资源使用文件名指纹 + 长缓存（max-age 1 year, immutable）
- HTML 主文档设置短缓存或 no-cache，并结合 ETag；页面更新时确保 HTML 引用的新版本静态资源
- 对于需要个性化内容的响应，避免被共享缓存：设置适当的 Cache-Control 或在 CDN 层面基于 Cookie/Token 做差异化缓存
- Service Worker 实现版本化与清理逻辑：skipWaiting + clients.claim + 在 activate 中删除旧缓存
- 在构建流程中加入自动化 CDN 刷新或通过版本化路径避免大范围 purge
- 在响应头中正确使用 Vary，避免不同用户看到不该共享的缓存
- 对关键接口使用 network-first 策略，非关键资源用 stale-while-revalidate 提升感知性能
- 在发布流程中包含“缓存验证”步骤：检查关键 URL 的头部、模拟用户更新流程并监控首屏加载是否使用最新资源
六、结语 用户感知的“卡顿”或“旧版页面”很少是随机发生的，多数是因为缓存层的设计或配置导致不同环境命中不同的缓存策略。通过明确分层（静态资源长期缓存 + 主文档短缓存）、对 Service Worker 和 CDN 的谨慎配置、以及在发布流程中加入缓存验证，可以把“看似偶然”的体验差异变成可控、可复现的工程问题，并显著提升用户的一致性体验。
如果你愿意，我可以根据你的当前部署环境（是否有 CDN、是否使用 Service Worker、后端语言/框架）给出一份具体的配置示例与发布检查清单。
