我把流程拆开后发现：91官网为什么有人用得很顺、有人总卡？分水岭就在缓存管理（看完你就懂）
很多人用同一个 91 官网，却有截然不同的体验：有人页面瞬间打开、视频顺滑播放；有人频繁白屏、资源加载失败、操作卡顿。把问题拆成流程来观察，就能把症结锁定在“缓存管理”上——不是单一的“缓存多了就慢”，而是缓存策略、位置与更新机制错位，导致不同用户看到不同的版本或被过期资源拖慢。
先说清楚：缓存在哪里？
- 浏览器缓存（HTML、CSS、JS、图片、字体）
- HTTP 头控制的 CDN/边缘缓存（缓存规则、TTL）
- 服务端缓存（Redis、Memcached、应用层缓存）
- Service Worker 和 PWA 离线缓存
- DNS 和代理缓存（本地运营商、公司代理）
- 本地存储（localStorage、IndexedDB、cookies）
- 负载均衡与会话（sticky session 导致状态不同步）
常见症状与背后原因（对照排查）
- 页面资源加载的是旧版本，功能异常：静态资源没有版本化或 CDN 没做正确的失效（cache-busting/清理）；
- 登录状态混乱、接口数据不一致：API 被缓存或会话在多台后端不同步（sticky session 未配置或 session 存储不集中）；
- 首次加载慢、二次快，或偶发性慢：CDN 边缘节点冷缓存或服务端缓存穿透/击穿；
- 部分用户总卡，其他人顺畅：可能是特定运营商/地区的 DNS 缓存、代理或 CDN 节点问题，或用户设备浏览器缓存污染/Service Worker 旧版本；
- PWA 更新后仍看旧内容：Service Worker 生命周期处理不当（skipWaiting/clients.claim 未合理使用）；
用户端快速排查与临时解决（非技术用户也能做）
- 用无痕/隐私窗口打开，看问题是否消失；
- 清除浏览器缓存或做一次硬刷新（Ctrl/Cmd + Shift + R）；
- 关闭浏览器扩展（尤其广告/隐私类扩展）试试；
- 切换网络（从公司网换到手机热点）判断是否为运营商或公司代理问题；
- 刷新 DNS 缓存（Windows: ipconfig /flushdns；Mac: sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder）；
- 如果用 App，尝试清除 App 缓存或重新安装。
开发者/运营该怎么做（分工明确，按流程解决） 1) 静态资源管理（前端工程）
- 采用文件指纹/哈希命名（如 app.abc123.js），对静态文件设置长期缓存：Cache-Control: public, max-age=31536000, immutable；
- 服务器响应 HTML（入口页面）要短缓存或不缓存：Cache-Control: no-cache, must-revalidate 或 Cache-Control: max-age=0, s-maxage=0, stale-while-revalidate=30。这样可以保证用户尽快拉取到最新的 HTML 引导新资源 URL；
- 对经常变更的资源使用短 TTL 并结合版本号/查询串实现缓存刷新。
2) CDN 与边缘缓存策略
- 为不同类型资源配置差异化策略：静态资源长缓存、HTML 短缓存、API 设置 private/no-store 或合适的短 TTL；
- 提供一键或自动化的 CDN 清理（purge）策略，部署后触发对应文件的失效；
- 使用 s-maxage 与 stale-while-revalidate，在边缘允许短暂返回旧缓存同时后台刷新，减轻回源压力。
3) 服务端与会话管理
- 把会话状态集中存储（Redis 或数据库），避免依赖本地内存导致多实例不一致；
- 对需要缓存的接口设计合适的缓存键和失效策略；对用户敏感数据避免被 CDN 缓存（设置 Cache-Control: private/no-store）；
- 防止缓存穿透/击穿：使用互斥锁、布隆过滤器或提前预热缓存。
4) Service Worker（PWA）管理
- 控制好更新流程：在新 SW 安装后使用 skipWaiting，但要在激活时提示用户刷新，或通过 clients.claim 控制客户端接管；
- 避免缓存所有 HTML，优先缓存可预见的静态资源，HTML 采用网络优先或网络回退策略，保证内容及时更新。
5) 监控与诊断
- 在关键接口和静态资源上打点（日志/埋点）监控缓存命中率、CDN 命中率、回源率；
- 收集不同地区、不同运营商、不同设备的加载链路数据（RUM）以发现节点差异；
- 配置报警：CDN 回源率飙高、错误率上升、响应时间异常等触发告警并自动回滚/清除缓存。
实用命令与示例（快速检查）
- 查看响应头：curl -I https://your-site.com/path
- 检查缓存头样例：
- 静态资源：Cache-Control: public, max-age=31536000, immutable
- HTML：Cache-Control: no-cache, must-revalidate
- API（用户敏感）：Cache-Control: private, no-store
- 强制清 CDN：大多数 CDN 提供 API，可在 CI/CD 部署后自动调用 purge 接口清理已发布资源。
典型误区（避免这些坑）
- 所有文件都设置长缓存：会导致大量用户看到旧逻辑或样式；
- 仅靠前端清缓存解决问题：问题根源可能是 CDN/服务端策略或 DNS 层面；
- Service Worker 写成万能缓存器：离线体验可能好，但更新和兼容性问题会把大量用户卡住；
- 忽视区域差异：全球网站需关注不同 CDN 节点和运营商差异化表现。
结论与行为清单（你可以马上做的事）
- 终端用户：先试无痕窗口、硬刷新、切换网络和清 DNS；常见问题多半能被临时解决；
- 网站维护者：为静态文件做版本化并设置长缓存，为入口 HTML 设置短缓存并实现 CDN 自动清理；集中会话存储，完善 Service Worker 更新流程；增加监控抓取不同地区的体验数据。
一句话总结：用户看到的“顺”或“卡”，往往不是单一因素，而是缓存策略在不同层级上是否协调一致。把缓存拆成浏览器/CDN/服务端/Service Worker 等模块逐一优化，用户体验才能统一、稳定。
需要的话，我可以把上面的建议整理成部署清单（开发、运维、前端三套任务表），或者给出针对你当前 91 官网配置的具体 header 建议与 CDN 清理脚本示例。要哪个直接说。
