核心是快速验证缓存是否为因，而非盲目清空；多数情况Ctrl+F5或Disable cache即可定位，若仍异常则需排查Service Worker或服务器缓存。
清空页面缓存排查版本更新异常，核心不是“清得越干净越好”，而是快速验证是否真由缓存导致——多数情况下，Ctrl + F5或开发者工具里勾选Disable cache就能立刻定位问题；但若仍显示旧版 HTML，大概率是 Service Worker 或服务器缓存没被绕过。
强制刷新（Ctrl+F5）为什么有时不生效
按下Ctrl + F5本应跳过 disk cache，但它对以下情况无效：
- 已注册的 Service Worker 拦截了
fetch并返回缓存响应 —— 它完全无视硬刷指令 - HTML 响应头含
Cache-Control: immutable或超长max-age=31536000，浏览器会复用 memory cache，硬刷只清 disk 层 - 你刷新的是子路由（如
/dashboard），但入口 HTML 实际由根路径/加载，缓存源头没被触发
此时必须打开开发者工具 → Network 面板 → 勾选 Disable cache，并手动进入 Application → Service Workers → 点击 Unregister。
开发者工具中 Disable cache 的真实作用边界
Disable cache 只在当前 tab 且 Network 面板保持激活时生效，它能：
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 强制所有请求走网络（状态码变为
200而非304），对 HTTP disk/memory cache 有效 - 对 Service Worker 缓存无效 —— 必须额外勾选
Bypass for network（Network 面板右上角三点菜单里） - 对
document.write()动态插入的 script、iframe 加载的页面无影响，这些仍可能读取缓存
调试时建议同时开启 Disable cache 和 Bypass for network，否则容易误判“缓存已禁用”。
URL 参数绕过缓存的可靠写法
给 HTML 文件加查询参数（如 index.html?t=1728546720）看似简单，但常见失效原因有：
- 直接改地址栏参数不触发重载：SPA 应用由 JS 控制路由，改 URL 不会重新请求 HTML —— 必须关闭标签页再新开
- 用了固定值（如
?v=1.2）：用户一旦缓存该带参 URL，后续访问仍复用，应改用时间戳或构建哈希（?t=1728546720或?hash=abc123） - CDN 或 Nginx 默认忽略 query string 缓存：需确认配置中开启了
$scheme$request_method$host$request_uri作为 cache key
最稳妥的做法是：本地开发用 python3 -m http.server 8000 启服务，避免 file:// 协议限制；上线后配合 Cache-Control: no-cache 响应头，而非仅靠参数欺骗。
真正难处理的从来不是“怎么清”，而是“清哪一层”——HTML 文件本身、JS/CSS 子资源、Service Worker 脚本、CDN 边缘节点、甚至反向代理的 upstream 缓存，每一层都可能独立生效。调试时务必先看 Network 面板第一个请求的响应头和 Status，再决定下一步动哪一层。
