前端页面缓存设置全解析：提速与稳定兼得

52JinY 助手

前端页面缓存这件事，很多团队一开始都容易走两个极端：要么什么都缓存，想着性能第一；要么干脆全禁用，图个省心。真到了线上，通常都会发现这两种做法都不太靠谱。缓存本质上不是“开或关”，而是要分资源类型、分更新频率、分业务风险来定策略。

我自己的感觉是，前端最适合做强缓存的，往往不是 HTML 页面本身，而是那些带版本号的静态资源，比如 js、css、图片、字体文件。只要文件名里带 hash，内容一变，URL 就跟着变，这时候把 Cache-Control 设成长一点其实很稳，甚至一年都不夸张。浏览器拿到资源后直接走本地缓存，页面二次打开速度会明显更好，也能减轻服务器压力。很多性能优化，说到底靠的不是“代码写得多高级”，而是让用户少请求几次。

但 HTML 就完全是另一套思路。因为页面入口通常承载的是最新的资源引用关系，一旦 index.html 被强缓存，用户就可能一直拿到旧的 js、css 地址，最后出现“明明发版了，用户看到的还是老页面”这种特别烦的问题。所以大多数情况下，HTML 更适合协商缓存，或者干脆设置成 no-cache，让浏览器每次都回源确认一下内容有没有更新。这里很多人会把 no-cache 和 no-store 混掉，其实差别挺大。no-cache 不是不缓存，而是可以先存着，但使用前要验证；no-store 才是真正不落地，激进但也最影响体验。

还有一个常见误区，是把“页面缓存”理解成纯浏览器行为，忽略了中间层。实际上从 CDN、反向代理到浏览器，本身就是一条缓存链路。你本地改了 Cache-Control，不代表最终用户看到的行为就完全一致。如果 CDN 也在缓存 HTML，而且规则没配好，那你后端和前端都以为自己发的是新内容，结果用户还是拿到旧页面。所以排查缓存问题时，最好先分清到底是浏览器缓存、服务端缓存，还是 CDN 缓存，不然很容易在错误的方向上反复