浏览器标签页切换本身不会自动清除临时缓存，HTML无原生机制删除已缓存资源；真正可控的是避免缓存复用或触发重新验证，如通过visibilitychange监听+fetch(cache:'reload')校验HTML是否过期。
浏览器标签页切换本身不会自动清除临时缓存；所谓“切换时清除”，其实是误读——HTML 没有提供原生机制让页面在 blur 或 visibilitychange 事件中删掉已缓存的资源（如 index.html、main.js）。你真正能控制的，是**避免缓存被错误复用**，或**触发重新验证/加载**。
为什么标签页切换后页面还是旧的？
这不是“缓存没清”，而是浏览器按 HTTP 缓存策略（比如 Cache-Control: public, max-age=3600）直接从 Disk Cache 返回了 HTML，连请求都没发。即使你切走再切回，只要没刷新、没禁用缓存，它就照用。
常见现象包括：
- 修改了服务器上的
index.html，但用户切回标签页仍看到旧 DOM 结构 - JS 中通过
fetch('/api/status')拿到新数据，但页面 layout 还是老版本（因为 HTML 入口没更新） - 手动改了 URL 参数（如加
?t=123）才生效 → 说明 HTML 被强缓存了
用 visibilitychange + fetch(cache: 'reload') 强制校验 HTML
虽然不能“删除”缓存，但可以在用户切回标签页时，主动向服务器发起一次条件请求，验证当前 HTML 是否过期。关键不是删缓存，而是绕过它去问服务器：“这个资源还有效吗？”
立即学习“前端免费学习笔记（深入）”；
实操建议：
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 监听
document.addEventListener('visibilitychange', ...) - 当
document.hidden === false（即标签页变为可见）时，用fetch(location.href, { cache: 'reload' })发起请求 - 注意：该请求只校验 HTML，不自动重渲染页面；你需要自己对比 ETag / Last-Modified，或服务端返回 304 就忽略，返回 200 则提示用户刷新
- 不要在每次切回都
location.reload()，会丢失表单输入；优先做静默校验
示例片段：
document.addEventListener('visibilitychange', () => {
if (!document.hidden) {
fetch(location.href, { cache: 'reload' })
.then(r => {
if (r.status === 200) {
// 服务端返回了新 HTML，可弹窗提示“检测到更新，是否刷新？”
}
});
}
});
更可靠的方案：让 HTML 入口根本不进缓存
前端最省心的做法，是让浏览器压根不缓存 index.html。这样每次标签页切换后首次访问，都会走网络请求，自然拿到最新版本。
配置方式（服务端或构建工具）：
- Nginx：对
index.html添加响应头Cache-Control: no-cache, no-store, must-revalidate - Apache：
<Files "index.html"> Header set Cache-Control "no-cache" - Vite / Webpack：通过
server.headers或插件注入响应头 - 注意：不要只设
max-age=0，某些浏览器仍可能用内存缓存（Memory Cache）；no-store更彻底
别踩的坑：以为 localStorage 或 sessionStorage 清了就能解决
这两个和 HTML 缓存完全无关。localStorage 存的是 JS 写入的键值对，sessionStorage 是会话级数据，它们不影响浏览器从 Disk Cache 加载 index.html 的行为。清了它们，页面照样显示旧 HTML。
真正容易被忽略的一点：即使你设置了 Cache-Control: no-cache，如果服务端同时返回了 ETag 或 Last-Modified，浏览器仍可能发条件请求（If-None-Match），而服务器若未正确处理这些头，就会错误返回 304 —— 导致你以为“没更新”，其实是服务端逻辑没跟上。务必验证服务器对条件请求的响应逻辑。
