html文件不应长期缓存，须设no-cache或max-age=60配合etag协商验证；静态资源应使用内容哈希命名+immutable指令实现强缓存；cdn策略必须与源站响应头一致，避免版本错配。
HTML 文件本身不适合长期缓存，但必须和浏览器缓存机制协同工作——关键在于「短缓存 + 内容哈希静态资源 + 协商验证」三者配合，否则极易出现白屏、错版、旧 JS 执行等线上事故。
为什么不能给 index.html 设 max-age=31536000
HTML 是入口文件，内容常变（比如新上线了按钮、改了路由、加了新 script 标签）。如果它被强缓存 1 年，用户刷新页面时仍加载旧 HTML，而旧 HTML 里引用的仍是旧版本的 app.a1b2c3.js，但实际部署已发布 app.d4e5f6.js，结果就是：资源 404、功能缺失、控制台报错。
- 正确做法是让 HTML 走「短强缓存」或「no-cache + 协商缓存」：比如
Cache-Control: no-cache或max-age=60 - CDN 层尤其要注意：很多 CDN 默认对
/index.html缓存 10 分钟，必须手动关掉或设为Cache-Control: no-cache，否则服务端返回的响应头会被覆盖 - 调试时看 Network 面板里
index.html的响应头，确认Cache-Control和x-cache（如 Cloudflare 的）是否符合预期
Cache-Control: no-cache 不等于不缓存
这个命名极具误导性。它实际含义是「跳过强缓存，但允许进入协商缓存流程」——浏览器仍会把 HTML 存在本地，只是每次请求都带 If-None-Match（对应 ETag）或 If-Modified-Since（对应 Last-Modified）去问服务器：“这版还有效吗？”
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 服务器若返回
304 Not Modified，浏览器就复用本地 HTML，不下载新内容，省带宽也快 - 若 HTML 真变了，服务器返回
200 OK+ 新内容，浏览器自然更新 - 注意：
ETag必须由服务端动态生成（如基于文件内容 hash），不能固定写死，否则协商永远返回 304
静态资源靠文件名哈希 + immutable 实现真正长期缓存
JS/CSS/图片这些资源内容不变就不该换 URL。打包工具（Webpack/Vite）输出 main.7a8b9c.js 后，配合响应头 Cache-Control: public, max-age=31536000, immutable，浏览器就知道：“这文件永久有效，连协商都不用发。”
-
immutable是关键：告诉浏览器该资源在生命周期内绝不会变，彻底跳过协商请求 - 没加
immutable时，即使max-age很大，某些浏览器（如 Safari）仍可能在地址栏回车或 F5 时发If-None-Match请求，多一次往返 - 务必确保构建产物的文件名哈希只随内容变化——改注释、删空行这类无意义改动不应触发新 hash，否则缓存失效率飙升
CDN 缓存和浏览器缓存不是一回事，必须分层控制
CDN 缓存的是你源站吐出的响应，包括响应头；浏览器缓存则是根据这些响应头自行决策。两者叠加时，错配风险极高。
- 典型错误：CDN 把
index.html缓存了 5 分钟，但你源站返回的是Cache-Control: no-cache——CDN 无视它，继续返回旧 HTML - 解决方案：CDN 规则按路径精细配置，例如
/static/** → Cache-Control: public, max-age=31536000，/index.html → Cache-Control: no-cache，且关闭 CDN 的“自动覆盖响应头”选项 - 上线后务必验证：清空浏览器缓存，用隐身窗口访问，检查每个资源的
Cache-Control值和是否命中 CDN（看x-cache头）
最容易被忽略的一点：HTML 缓存策略不是独立配置项，而是整个前端发布链路的终点——它依赖构建时的文件哈希、部署时的响应头注入、CDN 的路径规则、甚至服务端模板的 ETag 生成逻辑。任何一个环节断掉，缓存协同就失效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
