做开发最烦的不是写 Bug而是改完代码刷新页面浏览器却固执地给你看老版本。CtrlF5按烂了Disable cache也勾了它依然我行我素。后来才发现作祟的根本不是传统 HTTP 缓存而是Service Worker和Code Cache这两尊大佛。市面上找不到一个能一次性把这三者连根拔起的小工具——要么只清 HTTP 缓存要么得手动去chrome://serviceworker-internals/一个个注销。于是我自己写了个 EXE专治各种顽固缓存。核心代码不多但把坑基本都踩了一遍分享出来供参考。下载地址https://download.csdn.net/download/u012551928/93287457核心思路找到真正的“缓存”在哪Chrome 的缓存从来不止一个地方。我打开%LocalAppData%\Google\Chrome\User Data\Default\一看至少有四个目录在悄悄囤积数据Cache—— 传统磁盘缓存图片、CSS 等这个大家都知道。CacheStorage—— Service Worker 用cache.add()塞进去的资源独立于 HTTP 缓存。Service Worker—— SW 脚本本身、注册信息、元数据。Code Cache—— V8 引擎编译后的 JS/Wasm 字节码用来加速页面加载的。关键认知即使你清空了Cache只要CacheStorage和Service Worker还在页面刷新后依然能从 SW 手里拿到旧资源而且网络面板显示(from ServiceWorker)你甚至看不出它走了缓存。所以清理策略必须是关闭浏览器 → 挨个删目录 → 重建空目录防止启动报错。定位目录的坑别写死路径一开始我想用环境变量拼接比如这样cache_diros.path.expandvars(r%LOCALAPPDATA%\Google\Chrome\User Data\Default\Cache)但很快发现问题有些用户把 Chrome 装在 D 盘或者 Profile 目录重命名过。更靠谱的做法是只依赖%LOCALAPPDATA%这个标准路径因为 Chrome/Edge 的默认用户数据目录都在这里无论安装到哪个盘这个位置不变。对于 Firefox它的结构更恶心——配置文件夹名字随机生成xxxx.default-release且缓存藏在cache2子目录里。我用了笨办法遍历Profiles目录找到第一个以.default或.default-release结尾的文件夹再拼接cache2。虽然不优雅但管用。安全删除必须杀掉进程缓存目录里的文件可能被浏览器进程锁住直接用shutil.rmtree会报PermissionError。所以清理前必须先执行subprocess.run([taskkill,/f,/im,chrome.exe],capture_outputTrue)/f强制终止不用担心用户正在浏览因为工具本身就用于开发测试场景用户自己会保存工作。如果不关进程删除失败率极高特别是Code Cache和Service Worker目录浏览器后台线程一直在读写。核心清理函数去掉冗余后的精简版defclean_browser(browser_name,dirs_to_clean):# 先杀进程process_map{Chrome:chrome.exe,Edge:msedge.exe,Firefox:firefox.exe}subprocess.run([taskkill,/f,/im,process_map[browser_name]],stderrsubprocess.DEVNULL)# 挨个删目录forpathindirs_to_clean:ifnotos.path.exists(path):continuetry:# 统计一下大小方便日志输出sizeget_dir_size(path)# 自己实现递归计算shutil.rmtree(path)os.makedirs(path,exist_okTrue)log(f✅ 清理{os.path.basename(path)}释放{size/1024/1024:.2f}MB)exceptExceptionase:log(f❌ 删除{path}失败:{e})这个函数最大的价值在于“删除后立即重建”——很多工具只删不建结果浏览器下次启动时因为目录缺失会重新创建但权限或所有者可能出错导致后续缓存写入异常。重建空目录能避免这类副作用。关于 Service Storage 的疑惑有用户问我“为什么你不清理Service Storage目录”实际上在 Chrome 的标准目录结构里根本不存在叫Service Storage的顶层文件夹。你看到的很可能有两种情况Service Worker\CacheStorage被误读因为两个词连在一起容易看串。某些旧版 Chromium 曾用过非标准命名但现代版本Chrome 80统一为CacheStorage。所以我只清理Service Worker和CacheStorage两个目录这已经覆盖了 SW 所有的存储数据。如果用户机器上真有叫Service Storage的文件夹大概率是某个网站自定义的 IndexedDB 数据库名称跟缓存无关不碰为妙。重启并恢复会话给用户留条后路清理完缓存浏览器被杀了用户还得手动重新打开一堆标签页体验很差。所以我加了个可选功能清理后自动用--restore-last-sessionChrome/Edge或-restoreFirefox启动浏览器恢复之前的会话。关键代码subprocess.Popen([chrome_exe_path,--restore-last-session])这比单纯启动空白页友好得多而且能帮助用户快速验证清理效果——重新打开后如果页面资源全部从服务器重新加载说明清理生效。踩过的坑Code Cache 清理后首次加载变慢这是正常的V8 需要重新编译 JS后续会重新生成。用户反馈“清理后页面变卡”时需要解释原因。Edge 和 Chrome 路径几乎一样但 Edge 的User Data在Microsoft\Edge\User Data别搞混。Firefox 的坑它的cache2目录里没有明显的CacheStorage概念而且 SW 缓存和其他数据Cookies、LocalStorage混在storage/default下为了安全我只清cache2SW 缓存建议用户去about:serviceworkers手动注销。多用户 Profile如果系统有多个 Chrome 用户PersonDefault只是其中之一清理Default不会影响其他 Profile。这既是缺点也是优点——至少不会误删别人的数据。最后这套清理逻辑前后迭代了四个版本从最初只删Cache到后来加入 SW、Code Cache再到区分 Firefox基本覆盖了 90% 的开发场景。代码本身不复杂但搞清楚浏览器到底把东西藏在哪里花了最多时间。如果你也想手搓一个类似的工具记住三点定位准目录、先杀进程、删完重建。剩下的就是用户体验细节了。