强缓存和协商缓存，配错一次全班白屏
内部系统改版上线，客服打电话来说页面白屏。后端查日志：静态资源全是 200，接口也正常。最后发现是 app.js 配了三十天强缓存，文件名又没变——老用户的浏览器根本不来拉新文件。
把两类缓存摆在一起，其实很好选：
| 维度 | 强缓存 | 协商缓存 |
|---|---|---|
| 是否发请求 | 不发，直接用本地副本 | 发请求问"变了吗" |
| 判断依据 | Cache-Control: max-age | ETag / Last-Modified 比对 |
| 命中结果 | 200（from disk/memory cache） | 304，只省正文传输 |
| 适合 | 内容不变的资源 | 内容可能变的资源 |
所以常见的健康搭配是：带 hash 的文件名 + 一年强缓存（app.a3f2.js 这种，内容变名字就变），HTML 本体走 no-cache（每次协商，保证入口最新）。这套组合拳的精髓是：把"会不会变"的责任从服务器挪到文件名上。
几个容易记混的点：no-cache 不是不缓存，是"每次都协商"；no-store 才是真的一个字节都不留；max-age=0 等价于强制协商。调试时浏览器 DevTools 的 Network 面板要开 Disable cache，否则看到的全是 from cache，人会懵。
那次事故的修复倒是很朴素：服务端把 max-age 调回 300，等三十天强缓存自然过期。从此新项目上线前，缓存策略是发布清单里的必查项。