我踩过坑才敢提醒，91网页版让我最破防的一次：原来缓存管理才是核心（越早知道越好）
前言 上周跟一个客户调试 91 网页版的用户反馈，原以为是前端框架或后端接口的问题，结果把我们绕了三天三夜——罪魁禍首竟然是缓存。那一刻我彻底破防：一个看似简单的缓存配置，能把体验和迭代速度按在地上摩擦。把这次踩坑的过程、排查手段和修复策略整理出来，省你未来被同样问题折腾的时间。
现场回放：表现、排查、真相 表现：用户反映页面样式错乱、旧功能还在、最新提交不生效。有时登录状态不同步，报错出现在部分用户。
排查思路（实战）：
- 打开 Chrome DevTools，Network 面板先勾选 Disable cache，然后刷新。若问题消失，说明是缓存问题。
- Application 面板查看 Service Worker、Cache Storage、Local Storage；发现 service worker 在拦截旧版本资源。
- 使用 curl -I 查看响应头，发现 HTML 返回了长时间的 Cache-Control: max-age=31536000。
- 检查 CDN 配置，发现静态资源长期缓存但没有版本化，导致用户拉到旧 bundle。
真相：静态资源长期缓存 + 没有稳定的版本化 + service worker 错误更新策略 = 部分用户长期使用旧代码，造成功能不一致、报错频发。换言之，缓存管理才是核心。
原则和对策（落地可执行） 1) 区分资源角色
- HTML（入口页）：设置短 TTL 或 no-cache；保证用户每次能拿到最新的入口页。
- 静态资源（带内容哈希的 JS/CSS/图片）：可设置长期缓存（immutable）。
- 动态接口：使用 ETag/Last-Modified 与合理的 Cache-Control、并结合后端的缓存穿透/失效策略。
2) 版本化与缓存清理
- 构建产物使用文件名哈希（例如 app.abcdef.js），每次发布都会产生新文件名，客户端无需手动清理。
- 对于必须覆盖的资源（比如 HTML），在部署后触发 CDN 的路径或文件级别清理（purge），或用版本号查询参数强制刷新。
3) Service Worker 策略
- Service Worker 能带来离线能力，但更新流程要严谨：采用 skipWaiting/clients.claim 需谨慎，合理实现更新提示与回退方案。
- 实现缓存优先但带回退的策略（stale-while-revalidate）：先展示缓存内容，同时后台拉新版本，拉到后更新缓存并通知页面刷新。
4) HTTP 头最佳实践示例
- HTML: Cache-Control: no-cache, must-revalidate
- 静态（含哈希）: Cache-Control: public, max-age=31536000, immutable
- API：Cache-Control: private, max-age=60 或 使用 ETag
5) 监控与回溯
- 在 CDN/边缘与后端记录缓存命中率、purge 请求、错误率。
- 结合 RUM（Real User Monitoring）看真实用户是否拉到了旧资源，和 Lighthouse 做定期检测。
- 日志中标注部署版本号，出问题时快速定位受影响用户的资源版本。
快速解决清单（紧急）
- 立刻把入口 HTML 的 Cache-Control 改短或 no-cache。
- 强制更新或注销有问题的 Service Worker（临时措施）。
- 在 CDN 上对关键文件执行 purge（优先入口页和 manifest）。
- 确保构建管线产出文件名带 hash，后续发布走自动版本化+invalidate 流程。
- 推送一条兼容性的前端热修复（比如小版本强制刷新逻辑）给受影响用户。
实战数据（参考） 在此次修复后，我们把首页首屏时间从 3.8s 降到了 2.1s，同时用户反馈中的“功能不同步”问题几乎清零。缓存命中策略调整后，CDN 流量下降 20%，而页面稳定性显著提升——说明合理缓存会让体验和成本双赢。
结语 缓存不是可选项，也不只是性能加速的细节。它既能放大你的体验优势，也能在配置失误时把整个产品扯烂。越早把缓存管理纳入发布与监控流程，越能把这类“隐形炸弹”踩在脚下而不是踩到自己。