关键在于按资源类型分层控制，而非一刀切禁用缓存：静态资源配public、max-age=31536000、immutable；HTML用no-cache或max-age=60搭配ETag实现协商缓存；API按语义分级设置private、must-revalidate或no-store。
关键在于按资源类型分层控制，而不是一刀切地禁用缓存。Cache-Control 的指令组合决定了浏览器是否复用缓存、是否验证、是否允许中间节点缓存，配置不当才会导致“缓存污染”——即旧版本资源长期滞留，新逻辑无法生效。
静态资源：强缓存 + 内容哈希 + immutable
JS、CSS、图片等构建时确定的文件，应彻底避免版本错乱。必须配合构建工具生成带内容哈希的文件名（如 app.9f3a2d8c.js），再设置响应头：
- Cache-Control: public, max-age=31536000, immutable
- public：允许 CDN 和浏览器共同缓存
- max-age=31536000：一年内不检查过期（省去验证开销）
- immutable：告诉浏览器“URL 不变，内容绝不会变”，连 Ctrl+F5 都不发请求
这样既保证极致性能，又杜绝旧文件残留风险——只要文件名变了，就一定是新内容。
HTML 入口页：短时效 + 协商验证
HTML 是路由和资源加载的入口，必须及时感知变更。不能设 long max-age，也不能简单 no-cache（否则每次全量回源）：
立即学习“Java免费学习笔记（深入）”；
- Cache-Control: no-cache 或 max-age=60
- 搭配服务端生成的 ETag 或 Last-Modified
- 浏览器后续请求自动携带 If-None-Match，服务端比对一致即返回 304，不传 HTML 内容
既避免用户卡在旧首页，又节省带宽——60 秒内重复访问几乎零传输。
API 响应：按业务语义分级控制
接口数据新鲜度要求差异大，需按场景定制：
- 用户资料类（低频更新）：Cache-Control: private, max-age=3600（仅用户本人缓存 1 小时）
- 实时行情/通知类（高鲜度）：Cache-Control: no-store（禁止任何缓存，每次走真实请求）
- 列表页数据（可容忍短暂延迟）：Cache-Control: private, max-age=300, must-revalidate（5 分钟有效，过期必须验证）
注意：no-cache 不等于“不缓存”，而是“用前必须验证”；no-store 才是真正不存副本。
避免常见污染陷阱
很多缓存问题其实源于配置冲突或误用：
- 同时设置 Expires 和 Cache-Control：只要后者存在，前者被完全忽略
- 给 JS 文件设 no-cache 却没配 ETag：浏览器每次都回源，失去协商缓存价值
- 用 ?v=1.2.0 控制版本：多数 CDN 默认忽略 query string，缓存仍复用旧副本
- 在 fetch 中手动加 cache: 'reload' 或请求头 Cache-Control: max-age=0：跳过验证流程，反而可能拿到过期 304 响应
