HTML主文档缓存不能靠meta标签控制，Chrome、Firefox、Edge、Safari均忽略；必须通过服务端（如Nginx精确匹配location = /index.html）配置Cache-Control响应头实现可靠控制。
HTML主文档不能靠标签控制缓存
浏览器完全忽略 <meta http-equiv="Cache-Control"> 这类声明——Chrome、Firefox、Edge 均不解析，Safari 也早在 2018 年后弃用。写它只会制造“我已经配好了”的错觉，掩盖真实配置缺失。本地用 file:// 协议打开 HTML 时连 HTTP 头都没有，更谈不上缓存生效，此时看到的任何“缓存行为”都是假象。
Nginx 中正确配置 index.html 的 Cache-Control
对 HTML 主文档，核心原则是：不强缓存，但允许协商验证。常见错误是给 index.html 配 public, max-age=3600，结果用户卡在旧 HTML 里，JS/CSS 已更新但 DOM 结构没变，页面直接白屏或按钮失灵。
- 静态站点（如文档页）可设
public, max-age=300, must-revalidate，但必须确保所有资源路径含内容哈希（如main.a1b2c3.js） - 带登录态或用户数据的页面（仪表盘、订单页），应设
private, max-age=0, must-revalidate - 敏感页（支付确认、密码修改）用
no-store，彻底禁用磁盘/内存缓存 - 不要在 Nginx 的通用静态资源规则里覆盖 HTML，要单独写
location = /index.html块
示例配置：
location = /index.html {
add_header Cache-Control "private, max-age=0, must-revalidate";
expires -1;
}
验证 HTML 缓存是否按预期工作
别信地址栏回车或 F5——它们可能走内存缓存或强制校验。真正可靠的验证方式只有一种：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
- 打开 DevTools → Network 标签页
- 勾选 “Disable cache” 关掉它（避免干扰）
- 普通刷新（非 Ctrl+Shift+R），找到
index.html请求 - 看 Response Headers 里是否有你设的
Cache-Control - 看 Status 列：出现
304 Not Modified表示协商缓存生效；200 from disk cache对 HTML 来说基本等于配错了
SPA 场景下 index.html 缓存错配的连锁反应
单页应用最典型的问题是：HTML 缓存太久，而新版本 JS/CSS 已上线，导致旧 HTML 加载新 JS，document.getElementById("app") 找不到容器、路由初始化失败、样式全乱。这不是 JS 本身的问题，而是 HTML 和资源版本脱节。
- 构建产物中 JS/CSS 必须启用 content hash（Webpack
contenthash，Vite 默认） - CDN 或 Nginx 必须对 HTML 单独设短缓存，且不能和
.js/.css共用同一location规则 - 如果用 Vercel/Netlify，需在
_headers或netlify.toml中显式匹配/**/*.html并设cache-control: public, max-age=0, must-revalidate
最容易被忽略的一点：HTML 缓存时间越长，对 JS/CSS 路径哈希一致性的要求就越苛刻——一个字符错，整页就不可用。
