你用91网总觉得不顺？大概率是缓存管理没对上（真相有点反常识）
很多人把网站慢、内容不对、登录异常等问题归咎于服务器性能或前端代码，事实上真正犯错的常常是缓存策略——设置得不对，或根本没有把“缓存层次”想清楚。下面把常见症状、犯错原因、排查方法和修复技巧都讲清楚，能直接拿去在 91 网做诊断和改进。
一、先看症状（你是不是遇到这些）
- 页面加载忽快忽慢，用户体验波动明显。
- 刷新页面后仍看到旧内容，推送更新后用户才看到新页面。
- 登录状态乱、个性化数据错位（别人看到你的数据或相反）。
- 发布新版本后静态资源仍被旧版本缓存。
- 后端压力偶发性增大，短时间内大量请求打到同一个后端。
- 过度缓存会把错误或过期数据长期留在用户端，导致“看起来慢”或“行为异常”。
- 缓存策略不一致比不缓存更糟：浏览器、CDN、反向代理、应用层缓存各自为政，会互相覆盖或冲突，结果是命中率低且难以预测。
- 有时把缓存完全关闭调试后，生产反而出问题更频繁：因为没有缓存会让后端瞬间承压，暴露隐藏问题（缓存其实在掩饰后端的某些低效）。
- 反而正确的做法不是“去掉缓存”，而是“分层明确、键一致、版本化”。
三、常见根因（对症下药很关键） 1) HTTP 缓存头设置混乱：Cache-Control、Expires、ETag、Last-Modified 等互相矛盾。 2) CDN 或缓存代理的缓存键被 cookie、query string、Accept-Encoding 等影响，导致缓存碎片化或命中率下降。 3) 静态资源没有指纹化（文件名不加版本号），导致更新后无法快速失效。 4) 动态页面被误缓存（例如包含用户个性化数据却被CDN缓存）。 5) 缓存失效策略不合理：TTL 要么太长造成陈旧，要么太短无法减轻后端压力。 6) 缓存穿透/击穿/雪崩：热点缓存过期瞬间大量请求打到后端。 7) Service Worker、浏览器插件或代理缓存行为与服务器策略不一致。
四、实操排查步骤（顺序做，能最快定位问题） 1) 在浏览器打开开发者工具，Network 面板查看资源是 200、304 还是 404/500；检查响应头中的 Cache-Control、ETag、Vary、Set-Cookie。 2) 用 curl 检查 HTTP 头： curl -I https://your.91domain.com/path 注意响应是否有 Cache-Control、Age、X-Cache（CDN常见自定义头）。 3) 在不同网络环境（移动、家宽、同事的公司网）测试，判断是否为 ISP/CDN 边缘缓存问题。 4) 发布新内容后，观察 CDN 面板的缓存命中率、带宽与回源流量变化。 5) 针对登录/个性化问题，测试带/不带 Cookie 的请求返回有什么不同。 6) 在后端记录 cache hit/miss 日志，查看热点 key 的访问频度和失效时间点。
五、可立刻实施的修复清单 1) 静态资源采用指纹化（文件名或 query 版本号），配合长 TTL（例如一年），保证更新时通过变更文件名让缓存失效。 2) 对动态内容明确设置 Cache-Control：
- 绝对私有或与用户相关的响应：Cache-Control: private, no-store, no-cache（或短 TTL + ETag）。
- 公共静态：Cache-Control: public, max-age=31536000, immutable（配合指纹化）。
- 半动态数据：Cache-Control: public, max-age=60, stale-while-revalidate=30。 3) 在 CDN 层配置排除 Cookie、Authorization 等不参与缓存键（或明确指定哪些 header 参与）。 4) 使用缓存预热（warm-up）或在发布时主动清理/刷新 CDN（用版本化能减少频繁清理）。 5) 防止缓存击穿：对热点资源使用互斥锁、双层缓存或加上随机失效时间，避免大量同时回源。 6) 统一域名/协议/末尾斜杠策略，避免相同资源生成不同缓存键。 7) 对 API 响应做差异化缓存：对可缓存的字段单独缓存，不把整条响应作为原子缓存（或拆成公共+私有两段）。
六、一些反常识但有效的小技巧
- 给静态资源设置非常长的缓存时间，并用指纹更新，这比频繁 purge 更稳健。
- 对于用户可见但变更不频繁的数据，采用“在线 stale-while-revalidate”策略：先返回旧数据快速响应，同时后台异步刷新缓存并通知客户端更新。
- 别把所有错误都归结为 CDN：有时候是浏览器的 Service Worker 曾缓存了旧 HTML，清除或更新 SW 是必要步骤。
- 请求头里的 Vary: Accept-Encoding 能破坏 CDN 的合并缓存策略，只有在确实需要时才加。
七、简单命令与 header 快速范例（发给运维直接用）
- 查看响应头： curl -I https://example.com/page
- 示例正确的静态资源头： Cache-Control: public, max-age=31536000, immutable
- 示例半动态头： Cache-Control: public, max-age=60, stale-while-revalidate=30
- 禁止 CDN 缓存私有响应： Cache-Control: private, no-store
八、最终 Checklist（5分钟快速自检）
- 静态资源是否指纹化并设置长 TTL？（是/否）
- 动态/个性化响应是否设置为 private 或不被 CDN 缓存？（是/否）
- CDN 的缓存键是否被不必要的 header/cookie污染？（是/否）
- 发布时是否有自动刷新或版本化流程？（是/否）
- 是否对热点数据有防穿透策略？（是/否）
结语 感觉 91 网“不顺”多数时候不是流量太少或代码差，而是缓存这一层没调好。把缓存层次（浏览器、CDN、代理、应用、数据库）想清楚、把键和失效策略统一、用版本化替代频繁 purge，往往能把体验和稳定性同时拉上去。需要我帮你看看某个具体请求的 header 或写一份针对你站点的缓存策略示例配置吗？留下一个具体 URL 或你用的 CDN/代理类型，我来帮你诊断。