这事越传越离谱：91在线——关于缓存设置的说法｜我把过程完整复盘了一遍？评论区已经吵翻了

导语 近日围绕“91在线”的缓存设置出现了很多说法——有人说页面缓存太久导致内容不更新，有人说根本没用缓存，有人贴出一堆截图互相打脸。评论区吵得热闹，但信息参差不齐。为弄清真相，我在可控的环境里把常见的缓存策略逐一复盘、模拟和验证，下面把过程、技术细节、复盘结论和可落地的建议一次性给出，便于你判断和验证自己看到的那些“说法”。

事件回顾（简要）

• 起因：用户/开发者发现 91在线 某些内容在更新后浏览器或第三方渠道还是显示旧内容。
• 扩散：有人截图显示 Cache-Control/max-age 很大，有人又说 CDN 配置有问题，评论区因此分成两派。
• 关键争议点：到底是服务器端头设置问题、CDN 缓存策略问题，还是前端没有做 cache-busting？

我怎么复盘（方法与工具） 步骤概览 1) 把问题拆成三类对象：HTML（动态页面）、静态资产（CSS/JS/图片）、API/数据接口。 2) 在本地/测试环境里搭建简单服务器（Nginx、Node/Express）模拟常见响应头；同时在一个 CDN 测试环境（Cloudflare/通用反向代理）模拟边缘缓存行为。 3) 用标准工具观察和验证：

• curl -I / curl -v 检查响应头和重定向；
• 浏览器 DevTools 的 Network 面板观察缓存行为（Status、Size、Headers、Age）；
• 使用带变更的请求（添加查询字符串、修改文件 hash）验证 cache-busting 效果。 4) 逐一组合：只改源服务器头、只改 CDN 缓存规则、同时改两者，观察差异。

常用检查命令（可直接复制）

• 查看头信息：curl -I https://example.com/path
• 更详细：curl -v https://example.com/path
• 带输出头和正文：curl -s -D - https://example.com/path -o /dev/null

技术解析（常见响应头与含义）

• Cache-Control: public/private/max-age/s-maxage/no-cache/no-store/must-revalidate/stale-while-revalidate
• max-age：浏览器在本地缓存的最长秒数。
• s-maxage：为共享缓存（CDN/代理）专用，优先级高于 max-age。
• no-cache：资源在使用前必须向源验证（会向服务器发 If-None-Match/If-Modified-Since）。
• no-store：禁止任何缓存（浏览器或中间缓存都不保存）。
• immutable：适合带版本号的静态文件，浏览器可跳过再验证。
• ETag / Last-Modified：用于协商缓存。ETag 更精确，但对分布式部署要注意一致性。
• Expires：HTTP/1.0 的老方法，现代用 Cache-Control 更灵活。
• Age：通常由 CDN 添加，表示资源在边缘缓存中已经存在的秒数。
• Vary：决定中间缓存是否要区分请求头（比如 Vary: Cookie／Accept-Encoding）。错误使用会降低缓存命中。

复盘关键发现（模拟场景与结论） 场景 A：源服务器给 HTML 设置 max-age 很长（比如 1 天），没有 s-maxage

• 结果：浏览器直接从本地缓存取旧 HTML；若 CDN 在前面但未覆盖或配置不同，可能两端不一致。结论：不要对 HTML 设长期 max-age，除非每次部署都更换 URL。

场景 B：源服务器对静态资产设置 max-age=31536000 且带文件 hash（如 app.abc123.js）

• 结果：性能极好，CDN/浏览器都缓存；只要文件名变版本就不会出现陈旧问题。结论：静态资源用长期缓存 + 文件指纹是最佳实践。

场景 C：源服务器对 HTML 设短的 max-age，但 CDN 配置 s-maxage 很长

• 结果：浏览器每次都可能收到来自 CDN 的缓存页面，造成用户看到旧内容。结论：当使用 CDN 时，控制 s-maxage 比仅改 max-age 更关键。

场景 D：使用 ETag 但部署后不同节点生成的 ETag 不一致

• 结果：协商缓存失败，浏览器每次都回源或拿到新内容。结论：分布式部署要确保生成一致的 ETag 或采用 Last-Modified + 可靠构建流程。

场景 E：设置了 Vary: Cookie，但没有考虑这会显著降低 CDN 的缓存命中率

• 结果：CDN 会为不同 Cookie 值分别缓存，命中率下降。结论：只有在确实需要区分响应时才用 Vary。

针对“评论区吵翻了”的那些说法

• “缓存太久导致内容不更新”——在许多案例中确实是因为 HTML 或 API 被设置了过长的 max-age 或 CDN 的 s-maxage 导致边缘节点长期返回旧内容。
• “根本没缓存”——有些人看到 no-cache/no-store 或没有 Age/Cache-Control，就断言无缓存，但实际上 CDN 可能在前端做了隐式缓存或代理缓存。必须同时查看边缘（Age）和源头头信息。
• “是前端没做 cache-busting”——这条常常是根源问题。如果静态资源没有版本号，部署更新但文件名不变，会导致浏览器继续使用旧文件。

实战建议（可直接复制到服务器或 CDN） 静态资源（JS/CSS/图片）

• Cache-Control: public, max-age=31536000, immutable
• 使用文件指纹（例如 build 输出加 hash）来做 cache-busting。

HTML 页面（频繁更新/用户相关）

• 如果使用 CDN 边缘缓存：Cache-Control: public, max-age=0, s-maxage=60, stale-while-revalidate=30
• 含义：浏览器不长期缓存（max-age=0），CDN 在边缘缓存 60 秒，并允许在后台异步刷新。适合频繁更新但希望利用边缘性能的页面。
• 如果不使用 CDN 或页面高度动态：Cache-Control: no-cache
• 含义：浏览器每次都会向服务器验证资源是否改变（会走 If-None-Match 或 If-Modified-Since）。

API / JSON 接口

• 对于需要即时一致性的接口：Cache-Control: no-store 或 no-cache（视场景）。
• 可缓存但需要短时缓存：Cache-Control: public, max-age=5 或 s-maxage=10（小数值视业务而定）。

CDN 配置提示

• 优先使用 s-maxage 来控制边缘缓存；如果同时设置了 s-maxage 和 max-age，边缘缓存采用 s-maxage。
• 在 CDN 上启用“按路径/按文件类型”的缓存规则：静态资源长期缓存，HTML 短期或按需缓存。
• 使用缓存清除（Purge）或智能回源（stale-while-revalidate）来减少部署后旧内容残留。

如何在现场快速排查（五分钟行动清单） 1) 在问题页面运行：curl -I https://site/page —— 看 Cache-Control、Age、ETag、Vary。 2) 在浏览器 DevTools Network 面板中刷新（按 Ctrl+F5 或普通刷新），观察响应状态（200、304）与 Size。 3) 在 CDN 控制台看该 URL 的缓存命中/未命中记录与 Age 值。 4) 如果怀疑是文件没版本化，检查静态资源 URL 是否带 hash。 5) 在一次部署后，做一次全站 Purge 或按规则清除 CDN 缓存，并观察用户反馈是否立刻改善。

常见误区（别被评论区带偏了）

• 误区：只要设置了 ETag，就不用担心缓存问题。事实：ETag 是协商缓存的一部分，但对跨节点部署要求高。
• 误区：CDN 一定会覆盖源头设置。事实：CDN 会遵守源头头，但若 CDN 有自定义规则或页面规则，表现会不同。
• 误区：刷新浏览器能解决所有用户缓存问题。事实：许多用户不会手动刷新，且移动端/中间代理可能仍返回旧缓存。

结论（简明版）

• 争论的根源通常不是单一的“谁错谁对”，而是多个层级（源服务器、CDN、浏览器、前端资产管理）协同不当导致的表现。
• 针对不同资源采用不同缓存策略：静态长期缓存 + 文件指纹；HTML/CDN 使用短缓存或 s-maxage；API 按业务要求设置。
• 问题发生后用 curl+DevTools+CDN 控制台逐层排查，能最快定位责任方。

最后说两句 评论区吵翻了说明大家都很在意体验和更新速度，这很好——对开发者和产品方是压力也是动力。把上述排查方法放到常规部署流程里（部署后自动清缓存或触发 CDN Purge、构建输出带版本号、在监控中加入缓存命中率指标），能把大部分“越传越离谱”的场景变成可控的运维事件。