移动端HTML缓存不可照搬桌面配置，需按生成方式区分：静态页可设max-age=300，SSR/CSR混合页用no-cache协商缓存，敏感页必须no-store；静态资源须加immutable才生效；meta标签无效，依赖HTTP响应头；Service Worker不宜用于HTML主文档离线缓存。
移动端 HTML 缓存不能照搬桌面端配置——浏览器行为、网络环境、WebView 容器、系统级缓存策略都不同，直接复用 Cache-Control: public, max-age=3600 很可能在 iOS Safari 或 Android WebView 里失效甚至引发白屏。
移动端 HTML 文件该不该缓存？看生成方式
HTML 本身是否缓存，取决于它“动”还是“静”：
- 纯静态 HTML（如文档站首页、营销落地页）：可设
Cache-Control: public, max-age=300，5 分钟足够缓解 CDN 回源压力，又不至于卡住更新 - SSR/CSR 混合页（如用
htmx加载评论、用户头像）：必须用Cache-Control: no-cache，靠服务器返回ETag或Last-Modified做协商缓存；否则用户刷新可能看到旧数据 - 含登录态、实时仪表盘、支付页等敏感 HTML：只能用
Cache-Control: no-store，禁止任何中间节点（包括 iOS 的WKWebView内部缓存）存储
特别注意：Android WebView 默认启用磁盘缓存，但若后端返回 no-cache，它仍会发请求——只是可能复用旧响应体；而 iOS WKWebView 对 no-store 更严格，会彻底跳过缓存链路。
静态资源缓存必须加 immutable 才真正生效
移动端弱网下，协商缓存（If-None-Match）的往返耗时比桌面端更致命。Nginx 配置中漏掉 immutable，等于白设长缓存：
立即学习“前端免费学习笔记（深入）”；
location ~* \.(css|js|woff2|png|jpg|gif)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}immutable 告诉浏览器：“这个 URL 永远不会变”，后续请求直接跳过验证阶段。没有它，哪怕你用了哈希文件名（如 main.a1b2c3d4.js），iOS Safari 仍可能在弱网下多发一次 304 请求。
常见错误：只加了 max-age=31536000 却没加 immutable，结果在 iPhone 上实测首屏 JS 加载慢了 400ms+。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
meta http-equiv 在移动端基本无效
别用 <meta http-equiv="Cache-Control" content="no-cache"> 控制 HTML 缓存——它只对地址栏直接访问生效。一旦页面被 iframe 嵌入、被 fetch 加载、或由 WKWebView / Chrome Custom Tabs 打开，这个 meta 标签就完全被忽略。
真实场景中，80% 的 H5 页面是通过 App 内 WebView 加载的，缓存策略必须依赖 HTTP 响应头，而不是 HTML 内容。
Android 端还要额外注意：某些厂商 WebView（如华为、小米）会强制覆盖响应头，此时必须在客户端代码里调用 webView.getSettings().setAppCacheEnabled(false) 关闭其自有缓存，否则和 Nginx 配置冲突。
Service Worker 在移动端的实际限制
想用 Service Worker 实现离线 HTML 缓存？先确认目标环境：
- iOS 全系（包括 iOS 17+）不支持
navigationPreload，导致 HTML 导航请求无法被 SW 拦截，fallback 逻辑容易断掉 - Android WebView 默认禁用 Service Worker（需手动调用
WebSettings.setJavaScriptEnabled(true)和setAppCacheEnabled(false)） - 如果页面走的是 HTTPS + 自签名证书，多数 Android WebView 会直接拒绝注册 SW
结论：Service Worker 更适合控制 JS/CSS/图片的离线策略，而非 HTML 主文档。对 HTML 的离线兜底，优先考虑 App 层预置 HTML 包 + 版本号校验，比强依赖 SW 更可靠。
最易被忽略的一点：移动端缓存不是“设完 header 就完事”，而是 HTTP 头、CDN 规则、WebView 设置、Service Worker 逻辑四者必须对齐；任一环节覆盖或冲突，前面所有配置都会失效。
