别笑我夸张：我以为是我要求高，后来才懂91官网的缓存管理逻辑（建议反复看）
刚开始研究这个站的缓存策略时，我还以为自己太较真：怎么同样是静态资源，缓存表现能差出一截？慢慢翻请求头、看CDN控制台、模拟登录/未登录场景，把几百条网络请求过一遍后，才恍然大悟——真正决定体验的不是单项优化，而是一整套“按场景分级缓存”的工程思路。把这些观察整理出来，分享给遇到类似问题的人，省你反复摸索的时间。
一、先说结论（便于带着目标读下去）
- 区分用户状态（匿名/已登录）、资源类型（HTML/API/静态文件）和边界条件（是否携带Cookie、是否带查询参数）是缓存策略的基础。
- 静态资源用内容哈希+长缓存；HTML 用短缓存或无缓存配合边缘缓存刷新策略；动态接口用分层缓存与局部失效。
- 错误地设置 Set-Cookie、Vary 或没做资源版本化，比任何微小的压缩/合并优化都更伤性能和稳定性。
二、我看到的典型做法（也就是91官网的套路）
- 静态资源（js/css/img）采用文件名指纹（hash）+ Cache-Control: max-age=31536000, immutable。这样在客户端基本不会重复请求，CDN层又可长时间命中。
- HTML 页面在边缘（CDN）设置短TTL（如 30s–5min），并结合 stale-while-revalidate 或 surrogate-control，让用户看到可用内容同时在后台刷新缓存。
- 登录相关页面或携带特定 Cookie 的请求被判定为“不可被公共缓存”，通过Vary: Cookie 或直接禁止公共缓存，保证个性化不泄露给其他用户。
- API 层采用分层缓存：边缘缓存热点数据（短TTL），主节点做更细粒度的缓存与局部失效（tag-based 或 key-versioning），确保数据一致性的同时最大化命中率。
- 对静态CDN缓存失效，使用路径或文件名版本化（推荐）而不是手动 purge，减少误伤与延迟。
三、如何像我一样去“读”一个站点的缓存逻辑（实操清单） 1) 浏览器开发者工具 + curl 是你的显微镜
- 关注响应头：Cache-Control、Expires、ETag、Last-Modified、Vary、Set-Cookie、Surrogate-Control、Age。
- 用 curl -I 或 curl -v 模拟有无 Cookie、携带不同 Query 的请求，看是否被边缘缓存命中（观察 Age 和 X-Cache 等自定义头）。
2) 模拟场景比单次抓包要靠谱
- 匿名用户、已登录用户、跨地域（或用不同CDN节点）各抓一次。观察哪些请求在不同场景下行为不一样。
- 修改静态资源 URL（加 ?v=1 或换 hash），看缓存是否立即失效或依然命中。
3) 注意“致命头”：
- Set-Cookie 几乎会让公共CDN放弃缓存；如果只是在静态资源上无意中返回了 Set-Cookie，缓存命中率会暴毙。
- Vary: * 或 Vary: Cookie 会显著降低缓存效率。对定制化内容，应尽量减少 Vary 的使用或做边缘分片。
四、给开发与运维的可落地建议（按优先级） 高优先级
- 静态资源使用内容哈希命名 + 长缓存（Cache-Control max-age 大且 immutable）。
- HTML 页面通过短TTL + stale-while-revalidate 在边缘缓存（能兼顾实时性与响应速度）。
- 绝不在静态资源上返回 Set-Cookie；将个性化数据通过 API 请求或前端注入而非在主 HTML 上返回大量 Cookie。
中优先级
- API 采用分层缓存与 tag-based invalidation（标记失效）来支持局部刷新而不全局清除。
- 对大流量网站，使用边缘逻辑（Edge Workers/Function）处理简单个性化，避免回源频繁。
低优先级但常被忽视
- 对查询字符串和排序参数统一处理缓存策略：对于无害的查询（如 ?utm_source），通过 CDN 配置忽略它们；对于影响响应内容的参数则不同缓存键。
- 正确使用 ETag 与 Last-Modified：ETag 更精确，但生成成本高；结合 If-None-Match/If-Modified-Since 做 304 会比每次都回传完整内容节省带宽。
五、常见坑与排错思路（经验之谈）
- 坑：上线了新版本文件但用户仍旧加载旧的。检查看文件名是否带内容哈希；没有时就会出现缓存污染。
- 坑：在静态资源上无意识设置 Set-Cookie 导致 CDN 每次都回源。解决：去掉不必要的 Cookie，利用 localStorage/sessionStorage 存储个性化标识。
- 排错：先用 curl 检查边缘是否命中（Age 和 X-Cache），再在不同节点测试。不要只在本地浏览器测，会被本地缓存、代理影响判断。
六、对网站优化者/产品负责人的建议（一句话） 把缓存策略当成产品体验的一部分来设计：哪些页面必须实时，哪些页面可以接受一定延迟，按这些需求划分缓存边界和失效策略。性能优化的真正回报来自在“对的地方”放置“对的缓存”。
尾声：为什么值得反复看 缓存并不是单个头能解决的魔法，它是架构、前端、运维三方配合的产物。理解背后的场景分类和边缘思路，比盲目追求 gzip/合并更能实质提升体验。读一遍可能有收获，反复看你会开始在自己的项目里发现类似模式并马上改掉那些“看着小但致命”的配置。