HTML缓存机制本身不防劫持，它只控制是否使用旧文件，无法验证内容完整性或阻止中间人篡改；防劫持必须依赖HTTPS、HSTS、CSP及no-store等组合策略，而非缓存头。
HTML 缓存机制本身**不防劫持**，它只管“要不要用旧文件”，不管“这个旧文件是不是被篡改过”。靠 Cache-Control 或 Expires 无法验证 HTML 内容完整性，更不能阻止中间人（MITM）在传输途中替换页面。
为什么 Cache-Control 对劫持完全无效
缓存响应头只是告诉浏览器“这个资源可以存多久”，不包含任何签名、哈希或校验逻辑。即使你设了 no-cache 或 must-revalidate，浏览器每次仍会向服务器发请求——但只要链路未加密或证书异常，中间节点就能伪造响应体，返回恶意 HTML，而浏览器照单全收。
- HTTPS 是防劫持的第一道、也是唯一可靠的防线：它确保从服务端到浏览器的字节流完整且未被篡改
-
Cache-Control: no-store只是禁止本地存储，不影响传输中被截获和替换 - HTTP 缓存策略在 HTTP 协议层，而劫持发生在网络层或 TLS 层之下，缓存机制根本感知不到
真正起作用的是 Subresource Integrity（SRI）
SRI 能让浏览器校验外链 JS/CSS 的哈希值，但它对主 HTML 文件本身**不适用**——因为 标签没法加 integrity 属性。所以 SRI 只能保护子资源，不能保护 HTML 主体内容是否被掉包。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 你可以在
<script src="main.js"></script>上加integrity="sha384-..."，但或普通不支持该属性 - 如果攻击者替换了整个
index.html，那它可能删掉所有 SRI 属性，或指向自己控制的带毒资源 - SRI 前提是 HTML 本身可信；一旦 HTML 被劫持，SRI 就失去意义
防止 HTML 页面被劫持的实操底线
没有银弹，只有组合防御。重点不在“怎么缓存”，而在“怎么确保拿到的是原始 HTML”：
立即学习“前端免费学习笔记（深入）”；
- 强制全站 HTTPS，且服务端启用
HSTS（Strict-Transport-Security: max-age=31536000; includeSubDomains），防止降级到 HTTP - 禁用不安全的混合内容：HTML 中所有
http://资源引用必须清除，否则浏览器可能加载被劫持的子资源并执行 - 避免使用
Cache-Manifest（已废弃）：它不仅不防劫持，还会把被污染的 HTML 持久固化到离线缓存中，更难清理 - 敏感页（如登录、支付）必须配
Cache-Control: no-store+ HTTPS +Content-Security-Policy限制脚本来源，减少攻击面
最常被忽略的一点：缓存越激进（比如 public, max-age=31536000），HTML 被劫持后驻留时间就越长——用户刷新也拿不到新版本，除非清空磁盘缓存或等超时。所以防劫持不是“缓得更久”，而是“换得更快、验得更严、传得更牢”。
