HTML文件必须显式缓存才能离线访问，manifest不会自动包含引用它的HTML，路径需完全匹配且字节级变更才触发更新；Chrome 95+已弃用manifest，应改用Service Worker精准控制缓存。
manifest 文件里不写 HTML 就别想离线访问页面
离线缓存生效的前提是：你要访问的 HTML 文件本身必须被缓存。很多开发者只在 CACHE: 段里写了 js/app.js 和 css/style.css，却忘了把 index.html 显式列进去——结果网络一断，浏览器连主文档都拿不出来，直接白屏或 404。
注意点：
-
CACHE MANIFEST不会自动包含引用它的那个 HTML 文件，必须手动加进CACHE:列表 - 路径必须完全匹配：如果 HTML 是
/app/index.html，清单里就得写/app/index.html，不能写成index.html（相对路径在 manifest 中默认从根目录解析） - 若用
FALLBACK:做兜底，也得确保 fallback 页面（如/offline.html）本身在CACHE:里，否则离线时连 fallback 都加载不了
manifest 字节级变更才是更新的唯一触发条件
改了 JS 文件内容、更新了 CSS 版本号，但只要 cache.manifest 文件响应体没变，浏览器就当什么事都没发生。它不比对资源文件，只盯着 manifest 自己的字节流。
实操建议：
立即学习“前端免费学习笔记（深入）”；
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 每次发布前，在 manifest 最后加一行带时间戳或哈希的注释，例如：
# build-20260615-1822 - 禁用服务器对
.manifest或.appcache的强缓存，确保每次请求都返回 200 而非 304 - 检查响应头是否为
Content-Type: text/cache-manifest，否则 Chrome/Firefox 直接忽略该文件 - 用 DevTools 的 Network 面板确认 manifest 请求的 Response 是否真变了——别信 “Last-Modified” 时间，要看实际响应体
HTML 结构变更后缓存未同步的典型表现
你改了 DOM 结构、加了新 <script> 标签、调整了资源加载顺序，但用户刷新后页面仍渲染旧结构，甚至 JS 报错找不到元素。这不是代码没部署，而是旧 HTML 还躺在应用缓存里。
原因和对策：
- HTML 文件被缓存后，后续所有请求都由应用缓存提供，
Cache-Control头完全失效 - 解决办法只有两个：要么在 manifest 更新时同步更新 HTML 的路径（如改成
index-v2.html），要么确保每次变更都触发 manifest 字节变化并让用户刷新 - 避免在 HTML 中用
document.write或内联脚本动态插入关键 DOM——这些内容不会被 manifest 缓存，离线时直接丢失 - 如果 HTML 里有服务端注入的变量（如
<meta name="version" content="1.2">），这类内容离线时永远固定，无法随部署更新
现在还用 manifest 就等于主动放弃可控性
Chrome 95+、Firefox 84+ 已彻底移除 window.applicationCache，manifest 属性被忽略，DevTools 的 “Application → Manifest” 面板只是历史残留 UI，点进去看到的数据可能是错的或来自其他域名。
真正要保障 HTML 结构与离线数据的一致性，只能靠：
- Service Worker +
caches.open()显式缓存 HTML，并在fetch事件中拦截匹配，用stale-while-revalidate策略保证结构及时更新 - 把 HTML 当作动态资源处理：每次构建生成带哈希的 HTML 文件名（如
index.a1b2c3.html），再让 SW 缓存这个精确路径 - 结构变更若涉及数据模型（如新增字段），必须同步升级 IndexedDB Schema —— 单靠缓存 HTML 无法解决底层数据不一致问题
manifest 的一致性校验是静态的、单次的、不可调试的；而 Service Worker 提供的是可编程的、分阶段的、可打日志的控制流。后者才是你现在该花时间适配的方向。
