说出来你可能不信，我以为是我要求高，后来才懂91网的缓存管理逻辑
那天在 91 网刷内容，遇到一个让我反复刷新仍然看不到更新的页面。起初以为是我太挑剔：图片加载慢、旧版内容不消失、同一页面在不同设备上表现不同。我翻了浏览器设置、清理了缓存、甚至换了网络。问题仍在。几经尝试后，才慢慢推断出背后的缓存管理逻辑——不是我“要求高”，而是缓存设计在默默影响着体验。
把这段经历写出来，既想把自己的“抓包观察”分享给需要的人，也想让做产品或运维的同路人能从另一个角度看到缓存策略的现实影响。
我从哪儿看出来的？
- 更新延迟有规律：热门图片和静态资源秒级命中，但文章内容更新后要等较长时间才反映，说明静态资源与动态内容的缓存策略分层不同。
- 区域差异明显：在不同地区访问相同页面，返回内容的版本不同，暗示有 CDN 的边缘节点缓存和分片策略。
- 带参数/不带参数行为不同：同一个 URL 加上查询字符串或打上时间戳会刷新内容，说明缓存 key 中可能包含或排除 query string。
- 登录与未登录差异：登录态下页面更新更及时，说明某些页面在有 Cookie 时走了不同的缓存路径或直接回源。
基于这些观察，我推断 91 网（或类似大流量站点）很可能采用了下列缓存组合策略
- 分层缓存架构：浏览器缓存 → CDN 边缘缓存 → 反向代理/缓存层（如 Varnish、Nginx）→ 源站数据库/应用。不同层级使用不同 TTL 和失效策略。
- 静态资源长缓存、动态内容短缓存：图片、样式表、脚本一般设置较长的 Cache-Control（max-age），配合文件名指纹（hash）进行缓存更新；文章、评论这样的动态内容设置较短 TTL 或采用短路回源机制。
- 基于请求特征的路由：有无 Cookie、Accept 头、Query String 等会影响缓存 key。对登录用户通常绕开公共缓存或使用私人缓存。
- 按热门度自适应：热内容被更积极地预热和保留在边缘节点，冷内容则可能回源频繁或者只在少数节点缓存。
- 延迟失效策略（soft-expire + background refresh）：当缓存过期时，第一请求仍然返回旧内容给用户，同时后台异步去回源刷新缓存，以减少回源压力和响应延迟。
- 批量/标签化清理：对整类内容（比如某个目录或标签）做批量清理比逐个资源清理更高效，但也会带来短时间的缓存不一致性。
这些策略背后的“取舍” 任何面向百万级或亿级访问的网站都会面临性能与一致性的平衡：
- 更长的缓存能显著降低带宽和服务器压力，但会增加内容传播的滞后；
- 更严格的实时性需要频繁回源或广泛的失效通知，会牺牲可用性和成本；
- 对于登录用户绕过缓存可以保证个性化体验，但会把流量推回源站，影响扩展性。
对普通用户的实用建议（遇到“旧内容”时可以这样做）
- 尝试强制刷新（Ctrl/Cmd + F5）或清除浏览器缓存；但注意这只是短期手段。
- 在 URL 后加上时间戳或随机参数（如 ?t=123）能绕开公共缓存，临时查看最新内容。
- 登录后查看：部分站点对登录用户返回的是更“实时”的视图。
- 换节点或使用移动/桌面端比对：如果不同设备显示不同，说明是边缘缓存差异。
给开发和运营团队的一些可落地建议（不会判若两端）
- 明确分类缓存策略：将静态资源、半静态页面、强实时数据分别规划 TTL 和失效方式。给每类资源写清楚期待的时效和更新路径。
- 使用文件指纹与版本号：对静态资源采用内容哈希或版本号，确保更新能安全绕过客户端/CDN缓存。
- 实现柔性失效：采用 soft-expire + 后台刷新，能在保证性能的同时尽量减小用户看到“过期”内容的概率。
- 优化缓存 key 组合：决定是否把 query string、Cookie 等纳入缓存 key，并统一文档化，避免同一资源被多个 key 切割成孤岛缓存。
- 设置可观测性指标：缓存命中率、回源率、边缘/中枢节点差异等数据能帮助评估策略有效性。
- 提供清晰的回退与手动刷新机制：对重要内容提供接口或操作面板来触发 CDN/Purge，而不是靠人工逐项清理。
结语 一开始我以为自己“要求高”，直到搞明白缓存在大流量系统里到底怎么“聪明”地省资源、牺牲实时性。我对 91 网的“看不见的规则”多了几分理解，也少了几分抱怨。了解缓存，不是为了挑毛病，而是为了更聪明地和网络互动——无论你是用户、前端、后端还是产品经理，都能从一套清晰的缓存策略里获利。
