cache-control优先级高于expires，http/1.1规范明确规定二者共存时浏览器忽略expires；现代web应弃用expires和meta expires，按资源类型配置cache-control策略。
Cache-Control 优先级高于 Expires，别再混用
浏览器遇到同时存在 Cache-Control 和 Expires 的响应头时，会直接忽略 Expires。这是 HTTP/1.1 规范明确规定的，不是浏览器差异问题。很多老项目还在模板里写 <meta http-equiv="expires" content="0">，这在现代浏览器中完全无效，纯属心理安慰。
真正该配的是 Cache-Control，而且要按资源类型分策略：
-
CSS/JS/字体/图片：用public, max-age=31536000（1年），配合文件内容哈希命名（如main.a1b2c3.js） -
HTML 文件：必须用no-cache或max-age=0, must-revalidate，否则用户永远看不到新页面 -
API 响应：动态数据慎用缓存，若需临时缓存，优先用private, max-age=60，避免 CDN 错误复用
html-webpack-plugin 的 cache 选项不等于浏览器缓存
很多人以为把 html-webpack-plugin 的 cache 设为 true 就能控制浏览器行为，其实它只影响 Webpack 构建阶段的模板编译缓存——即是否跳过对 index.html 模板的重复解析。和浏览器加载 HTML 时是否走本地缓存毫无关系。
构建缓存生效的前提是：minify 配置没变、入口 chunk 没增删、模板文件内容未改动。一旦你改了 title 或加了个 script 标签，缓存就失效，Webpack 仍会重新生成 HTML 文件——但这个新文件发给浏览器后，是否被缓存，全看你的服务器响应头怎么设。
常见误操作：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 开发时关掉
html-webpack-plugin的minify，上线又打开 → 构建缓存失效，但 HTML 内容体积突变，可能触发意料外的压缩 bug - 把
cache: false当成“禁用所有缓存”，结果只是让 Webpack 编译更慢，对浏览器毫无影响
协商缓存失效时，304 不等于没请求
设了 Cache-Control: no-cache 后，浏览器每次都会发请求，但服务器可以返回 304 Not Modified。这看起来省了带宽，实则仍有完整 HTTP 往返开销（DNS、TCP、TLS、首字节时间）。对于首页这种关键路径，哪怕只有 200ms 的首字节延迟，也比强缓存慢一个数量级。
所以 HTML 文件的最优解从来不是“靠 304 省流量”，而是：
- 用构建时注入版本号或时间戳（如
<link rel="stylesheet" href="/app.css?v=20261013">），再配Cache-Control: public, max-age=31536000 - 或者用
Service Worker拦截 HTML 请求，返回预缓存副本（适合 PWA 场景） - Nginx/Apache 层做
try_files或rewrite，把带 hash 的 HTML 路径映射到实际文件，彻底绕过协商
CDN 缓存和浏览器缓存不是一回事
CDN（比如 Cloudflare、阿里云DCDN）会按自己的规则解析响应头，并可能覆盖你设的 Cache-Control。例如你回源返回 Cache-Control: no-cache，CDN 却可能根据自身策略缓存 5 分钟——用户看到的就是“明明刷新了，还是旧 HTML”。
排查这类问题最直接的方式是看真实响应头：
- 用
curl -I https://yoursite.com/index.html查看回源响应头 - 再用浏览器开发者工具 Network 面板看实际收到的响应头，对比
via、age、x-cache等字段 - CDN 控制台里检查是否有“强制缓存”或“忽略源站缓存头”的开关被误开启
真正难调的点不在配置本身，而在于多层缓存（浏览器 → CDN → 反向代理 → 应用服务器）之间状态不同步。一次发布后清缓存，必须按顺序逐层清理，漏一层就白忙。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
