html文件必须禁用强缓存，设cache-control: no-cache, must-revalidate, max-age=0并配etag；静态资源须用contenthash命名+cache-control: public, immutable，cdn策略需与源站一致，否则仍会加载旧版本。
HTML 文件必须禁用强缓存，靠服务端响应头强制每次校验；静态资源则要靠文件名哈希 + immutable 实现长期可靠复用——两者缺一不可。
为什么只改 HTML 响应头还不够
很多团队给 index.html 配了 Cache-Control: no-cache，就以为万事大吉，结果用户仍看到旧页面。问题出在：HTML 本身只是“入口”，它引用的 JS/CSS 路径如果没变，浏览器就继续用旧缓存，哪怕 HTML 已更新。
- 典型现象：改了按钮文案并重新部署，但用户刷新后仍是旧按钮——因为新 HTML 里仍引用着旧哈希名的
app.abc123.js（构建未触发重哈希） - 根本原因：HTML 缓存策略和静态资源构建产物没联动，构建工具输出的哈希没随内容真实变化（比如 Webpack 的
[contenthash]未正确启用，或用了不稳定的[hash]） - 验证方式：打开 DevTools → Network → 刷新 → 查看新加载的
index.html中<script src="..."></script>的路径是否和构建产物一致；再检查该 JS 请求的状态码是200还是304
Nginx 怎么安全配 HTML 缓存头
别信 expires 1s 或 add_header Cache-Control "max-age=1" —— 这些看似短时间，实则可能被浏览器当作强缓存处理，尤其在 Safari 和部分 CDN 上表现不稳定。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 必须用组合指令：
Cache-Control: no-cache, must-revalidate, max-age=0，语义明确且兼容性好 - 一定要配
ETag ""（空字符串），让 Nginx 自动生成基于内容的校验值；比Last-Modified更可靠，避免秒级修改导致校验失效 - 禁用
expires epoch以外的expires指令，防止与Cache-Control冲突 - 常见陷阱：Nginx 的
add_header在if块里不生效；location 匹配必须精确，例如location = /index.html，不能写成location /index.html（后者会匹配所有含该子串的路径）
静态资源怎么确保浏览器不复用旧文件
光靠 max-age=31536000 不行。浏览器只看 URL 是否命中缓存，而 URL 不变时，哪怕服务端文件已更新，它也绝不会发新请求。
- 构建阶段必须生成内容哈希文件名，例如
main.a1b2c3d4.css，Webpack 用[contenthash]，Vite 默认开启 - 响应头必须加
immutable：告诉 Chrome 等浏览器“这个 URL 永远对应同一内容”，跳过If-None-Match协商请求，省掉一次 RTT -
public必须带上：允许 CDN、公司代理等中间节点缓存，否则private会让 CDN 绕过，失去边缘加速效果 - CDN 控制台要同步设为“绕过缓存”或 TTL ≤ 60 秒——如果源站返回
no-cache，但 CDN 后台却配了 10 分钟缓存，用户就永远卡在旧 HTML
开发调试时最容易忽略的一点
本地用 file:// 协议打开 HTML，或通过 Webpack Dev Server 访问，Cache-Control 头压根不生效——因为没有 HTTP 服务器参与，浏览器退化到启发式缓存（比如按文件修改时间猜一个 max-age）。这时你看到的“缓存行为”，跟线上完全不是一回事。
真正验证，必须走真实 HTTP 服务（哪怕只是 python3 -m http.server 8000），并用 curl -I http://localhost:8000/index.html 确认响应头；线上则必须盯紧 x-cache（Cloudflare）或 x-cdn-cache（阿里云）响应头，确认 CDN 没覆盖你的配置。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
