HTTP缓存通过强缓存与协商缓存双层机制优化静态资源加载：强缓存（如Cache-Control: max-age=31536000）跳过请求直接复用本地文件，需配合内容哈希命名；协商缓存（ETag/Last-Modified）仅验证更新，返回304节省带宽；二者须与构建工具、Nginx/CDN配置及压缩、CDN、preload等协同生效。
HTTP 缓存能显著加快静态资源加载，核心是让浏览器复用已下载的 JS、CSS、图片等文件，避免重复请求。关键不在“要不要缓”，而在于“怎么分层设、设对没”。
强缓存：跳过请求，直接读本地
适用于内容稳定、带哈希命名的构建产物（如 app.a1b2c3.js）。浏览器检查 Cache-Control: max-age=31536000 或 Expires 头，未过期就完全不发请求。
- 服务端必须为这类文件设置长期缓存（如 1 年），且确保文件名含内容哈希——内容一变，文件名就变，自然失效旧缓存
- 第三方库（React、Vue）单独打包并设相同 long-term 缓存，它们更新频率低，复用率高
- 避免对 HTML 文件设强缓存，否则 JS/CSS 更新后，用户可能仍加载旧 HTML，导致白屏或报错
协商缓存：只验证，不重传
当强缓存失效或未设置时启用，浏览器仍发请求，但服务器根据 ETag 或 Last-Modified 判断是否真要返回内容。若未变更，返回 304 Not Modified，响应体为空，节省带宽。
-
ETag更精准（基于内容生成），适合频繁更新的 API 响应或动态生成的 JS bundle -
If-Modified-Since依赖时间戳，适合变动少的资源（如文档类 JS 工具包） - 注意：协商缓存仍会产生 1 次网络请求，但响应极小；相比无缓存，加载时间可降 30% 以上
配合构建与部署策略才真正生效
光配响应头不够，得和前端工程化联动：
立即学习“Java免费学习笔记（深入）”；
- 构建工具（Webpack/Vite）开启 contenthash，确保产出文件名随内容变化
- Nginx 或 CDN 配置按路径匹配缓存策略：/static/js/ →
Cache-Control: public, max-age=31536000；/api/ →Cache-Control: no-cache或max-age=0 - HTML 本身建议设
Cache-Control: no-cache或短时效（如max-age=60），保证能及时拉到最新入口文件
别忽略压缩与传输优化
缓存再好，如果文件体积大、传输慢，首次加载和缓存更新都卡顿：
- 服务端启用 GZIP/Brotli 压缩，JS 文件通常能压缩至原体积 30%–40%
- 通过 CDN 分发静态资源，利用边缘节点降低 RTT，尤其对海外用户效果明显
- 关键 JS 使用
<link rel="preload">提前加载，不阻塞渲染，配合缓存实现更快首屏
