旧系统中HTML5缓存包括localStorage、sessionStorage、indexedDB、Application Cache和服务端Worker，需分别清理：localStorage用removeItem精准删除；sessionStorage关闭标签页或调用clear；indexedDB需监听deleteDatabase回调；AppCache须服务器移除manifest文件并用户硬刷新。
旧系统里 HTML5 相关缓存到底藏在哪
旧系统（比如 IE11 兼容模式、老旧 Electron 壳、或内嵌 WebKit 的桌面客户端）中，HTML5 的“清理”往往不是清浏览器历史那么简单——localStorage、sessionStorage、indexedDB、Application Cache（已废弃但旧系统仍可能残留）、甚至 Service Worker 缓存都可能独立存在且互不干扰。
关键判断：如果页面刷新后仍显示旧 JS/CSS/HTML，大概率不是 HTTP 缓存，而是这些客户端存储机制在起作用。
逐项清理 localStorage 和 sessionStorage
这两个最常被误认为“自动清掉”，其实只要没手动调用或没关闭全部标签页，sessionStorage 就不会清；localStorage 更是永久驻留，除非显式删除或用户手动清除站点数据。
-
localStorage.clear()可一键清空，但会删掉所有键值对——若系统依赖其中某些配置（如userTheme或lastLoginTime），建议改用localStorage.removeItem('keyName')精准删除 -
sessionStorage在页面关闭后自动释放，但旧系统若使用window.open或 iframe 跨域加载，可能意外保留。调试时可在控制台直接执行sessionStorage.clear() - 注意：部分旧版 IE 对
localStorage的 key 名称敏感，含点号（.）或斜杠（/）的 key 可能无法被removeItem正确识别，建议统一用下划线命名
indexedDB 清理必须指定数据库名
不像 localStorage 那样有全局 clear 方法，indexedDB 必须先 deleteDatabase 再等待 success 事件完成——否则后续打开会失败或读到旧结构。
立即学习“前端免费学习笔记（深入）”；
常见错误：只调用 indexedDB.deleteDatabase('myApp_v1') 就以为完事了，但没监听回调，导致后续 open 时仍连接到旧库（尤其在快速刷新场景下）。
const req = indexedDB.deleteDatabase('myApp_v1');
req.onsuccess = () => console.log('DB deleted');
req.onerror = () => console.error('Delete failed:', req.error);
req.onblocked = () => console.warn('DB is open somewhere — close all tabs first');
旧系统中，若页面通过多个 iframe 加载同一域名资源，onblocked 极易触发，需提醒用户关闭所有相关窗口。
Application Cache（AppCache）不能靠 JS 清除
这是 HTML5 早期标准，虽已废弃，但 IE10/11、旧版 Safari 和某些国产双核浏览器仍支持。它的缓存由浏览器在解析 时自动管理，JavaScript 无法通过 API 删除。
唯一可靠方式是：
- 服务器端彻底移除
app.appcache文件，并返回 404 - 同时把 HTML 中的
manifest属性删掉或设为空： - 用户必须硬刷新（Ctrl+F5）或清空浏览器“离线网页”类缓存（IE 设置 → Internet 选项 → 删除 → 勾选“脱机网页”）
漏掉任一环节，旧 manifest 缓存就会继续拦截网络请求，连 500 错误都看不到——只显示“找不到网页”或白屏。
真正麻烦的不是步骤多，而是旧系统里这几层缓存常常叠加生效：比如 Service Worker 控制了页面，但它自己又从 indexedDB 读配置，而配置里又写了 localStorage 的开关状态。动手前最好先用开发者工具的 Application 标签页挨个点开看，别猜。
