标题：91官网避坑清单（高频踩雷版）：缓存管理一定要先处理（别说我没提醒）
导语 你的网站上线后，大多数用户遇到的问题并不是页面长得丑，而是“为什么我看不到最新内容”“登录信息错乱”或“性能忽高忽低”。在这类高频故障中，缓存问题排在前列。本文把多年实战经验浓缩成一份可直接执行的避坑清单，重点放在缓存管理并覆盖前端、后端、CDN 和部署流程，照着做能省下大量排查时间和用户投诉。
一、先定规则：缓存策略三步走
- 静态资源（CSS/JS/图片）：长期缓存 + 文件指纹（hash），一旦文件内容变更就换 URL。这样既省带宽又保证更新可见。
- 动态内容（HTML/API）：短 TTL 或不缓存，结合变更触发的主动失效（版本号/时间戳）保证及时性。
- 鉴权/隐私数据：绝不缓存到公共缓存层（浏览器、CDN、代理）。把认证态与缓存分层管理。
二、静态资源必做项（高频踩雷点） 常见错误：给 index.html 或可变资源设置长缓存；不做文件指纹；用服务工作线程缓存静态文件但不考虑更新。 做法：
- 构建产物加 content-hash（app.abc123.js），配合 Cache-Control: public, max-age=31536000, immutable。
- index.html、主 HTML、模板等使用短 TTL（例如 Cache-Control: no-cache 或 max-age=0, must-revalidate），或通过版本号引用新文件。
- Service Worker：缓存策略要能处理更新（比如在激活阶段强制清理旧缓存或使用 skipWaiting + clients.claim，并在 fetch 时优先 network-first 对于 HTML）。
三、API 与动态数据（最容易被忽视） 常见错误：对 API 响应设置过长缓存或靠浏览器默认缓存，导致用户看到旧数据。 做法：
- 对返回用户特定数据或敏感信息的接口设置 Cache-Control: no-store, no-cache 或 private, max-age=0。
- 对可缓存的公共查询结果使用合理 TTL，并加上 stale-while-revalidate（例如 Cache-Control: public, max-age=60, stale-while-revalidate=30）以提升响应感知速度同时允许后台刷新。
- 为复杂缓存引入版本号或 ETag，搭配 If-None-Match / 304 响应减小带宽。
四、鉴权与会话处理（千万别大意） 踩雷案例：登录后页面被 CDN 缓存，其他用户看到的是缓存页面或登录信息错误。 对策：
- 对包含 Set-Cookie 的响应或认证页面设置 Cache-Control: private, no-store 或 no-cache。
- CDN 配置上对 Cookie、Authorization、Set-Cookie 等头部敏感的路径禁止缓存或走规则化缓存。
- 使用 HttpOnly + Secure 的 Cookie 并合理设置 SameSite，以避免跨站问题和缓存错误。
五、CDN 与反向代理：清除与版本化优于强制过期 常见错误：上线后只靠 CDN 手动 purge，遇到频繁发布效率低下；或完全不做版本化导致无法精确失效。 做法：
- 静态资源采用版本化 URL，减少对 CDN purge 的依赖。
- 对需要即时更新的资源（公告、促销页）实现 API 控制的 purge 接口或使用短缓存配合预热。
- 使用 CDN 的 Cache-Key 控制（忽略某些查询参数或包含必要参数），避免缓存污染。
六、服务器端缓存层（Redis/Memcached/Varnish） 坑点：多层缓存之间一致性差，导致数据既非最新也非预期。 实践：
- 设计清晰的缓存 key 命名与失效策略（例如：user:{id}:profile，变化时原子删除或更新）。
- 避免把长 TTL 缓存和实时写入逻辑混用，使用消息队列或事件总线同步失效。
- 对高并发读场景使用缓存穿透、击穿和雪崩防护（布隆过滤器、互斥锁或请求合并）。
七、HTTP 头部样例（可直接复制）
- 静态（带 hash 的文件） Cache-Control: public, max-age=31536000, immutable
- 页面（可变 HTML） Cache-Control: no-cache, must-revalidate 或 Cache-Control: private, max-age=0, no-store
- API（用户专属） Cache-Control: no-store
- 可缓存的公共 API Cache-Control: public, max-age=60, stale-while-revalidate=30
八、快速排查命令与工具（开发/运维常备）
- curl 检查头部 curl -I https://yoursite/asset.js
- 查看是否收到 304 curl -I -H "If-None-Match: \"etag\"" https://yoursite/page
- 浏览器 DevTools → Network：勾选 Disable cache（开发时）并查看缓存命中（from memory cache / disk cache）。
- Lighthouse / WebPageTest：性能与缓存影响评估。
- CDN 管理控制台：查看命中率与 purge 日志。
九、上线与回滚流程清单（每次发布都照做）
- 构建产物哈希完成并写入 index 或 manifest。
- 修改需要立刻可见的内容（如 HTML）使用短缓存或强制清理。
- 发布前在测试环境验证缓存头与 service worker 行为。
- 上线后快速检查 CDN 命中率、关键页面是否为最新、用户会话是否正常。
- 回滚方案：保证回退版可兼容现有缓存（避免新老版本冲突）。
十、常见踩雷案例与解决办法（真实场景）
- 用户看不到新样式：原因是 index.html 被长缓存。解决：把 index.html 缓存改短并改用 hash 引用静态资源。
- 登录态错乱：原因是登录响应被 CDN 缓存。解决：对登录响应禁用缓存，CDN 配置基于路径/头部规则。
- 发布后用户仍看到旧图标：原因是没有文件指纹或 CDN 没清理。解决：使用文件哈希并在 CDN 上做预热/自动 purge。
结语 + 联系方式 缓存不是“设置一个参数就完事”的小活，而是贯穿前端、后端、CDN 和部署的系统工程。把缓存策略当作发布流程的第一步来做，很多用户体验问题和夜间报警能被提前杜绝。需要把你的 91 官网从“偶发问题制造机”变成“稳定可靠的内容平台”？我可以根据你当前的架构给出定制优化清单与部署脚本，欢迎私信或留言约时间。
