http缓存头控制静态资源复用最高效可靠,因浏览器可直接从磁盘读取而跳过网络请求;关键需服务端配置cache-control: public, max-age=31536000, immutable并禁用etag/last-modified,同时html设no-cache以确保版本更新。

直接用 HTTP 缓存头控制静态资源(JS/CSS/图片/字体)的复用,比任何前端代码逻辑都更高效、更可靠——前提是服务端配置正确,且不把 Cache-Control 设成 no-cache 或 max-age=0。
为什么改前端代码不如改响应头
很多人试图用 localStorage 存 JS 文件内容、用 fetch + cache.put() 手动缓存 CSS,结果反而引入竞态、版本错乱、更新失效等问题。真实瓶颈从来不在“能不能缓”,而在“浏览器愿不愿意直接从磁盘读”。只要服务端返回了正确的 Cache-Control,浏览器会在后续请求中直接跳过网络,连 TCP 握手都不发。
常见错误现象:
- Network 面板里所有 JS/CSS 显示
200 (from memory cache)或200 (from disk cache)—— 这是理想状态 - 明明文件没变,却总看到
304 Not Modified—— 说明强缓存没生效,退到了协商缓存,多了一次 HTTP 往返 - 每次部署新版本,用户仍加载旧 JS —— 很可能是 CDN 或反向代理缓存了
index.html,而它引用的app.js路径没变
关键响应头怎么配才不踩坑
对静态资源(.js、.css、.png、.woff2 等),必须满足两个条件:路径带哈希、响应头禁用协商缓存。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图,自动匹配视觉风格。触发场景:文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
-
Cache-Control: public, max-age=31536000, immutable——immutable告诉浏览器“这个 URL 永远不会变”,彻底跳过If-None-Match和If-Modified-Since请求 - 绝对不要配
ETag或Last-Modified—— 它们会触发协商缓存,哪怕你写了max-age=31536000,浏览器在过期前仍可能发条件请求 - HTML 文件必须单独对待:
Cache-Control: no-cache或max-age=0—— 否则用户永远看不到新版本的index.html,也就加载不到新哈希的 JS - 如果用 Webpack/Vite,确保构建产物文件名含 content hash,例如
main.a1b2c3d4.js;否则immutable会锁死旧内容
CDN 和反向代理的缓存要同步清理
即使源站响应头全对,CDN(如 Cloudflare、阿里云 CDN)或 Nginx 反向代理也可能按自己的规则缓存,覆盖源站设置。
- Nginx 示例:在
location ~ \.(js|css|png|woff2)$块里显式加add_header Cache-Control "public, max-age=31536000, immutable"; - Cloudflare 默认会忽略源站的
Cache-Control,需进缓存规则页,将匹配/*.js的规则设为 “Cache Level: Cache Everything”,并勾选 “Edge Cache TTL” 自定义为 1年 - 发布新版本后,如果用户仍加载旧资源,先检查 Network 面板 Response Headers 是否真包含你设的
Cache-Control;若没有,问题一定出在 CDN 或中间层
Service Worker 不适合替代 HTTP 缓存
有人用 caches.open() + cache.addAll() 在 install 阶段预存所有静态资源,以为这样更可控。但实际带来三个硬伤:
- 首次访问必须等 SW 安装完成才能发起资源请求,白屏时间拉长
- SW 更新有延迟:新 SW 安装后,旧页面仍用旧 SW 的缓存,除非强制 reload 或关掉所有标签页
- 无法利用浏览器原生的内存缓存(
from memory cache),所有资源都要走cache.match()+ 解析 Response,开销更大
真正该用 Service Worker 的场景,是离线 fallback、API 请求重试、或需要运行时动态策略(比如只缓存特定域名下的图片)。对标准静态资源,HTTP 缓存仍是不可替代的底层机制。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!










