清理客户端缓存先分清哪层可丢

更新于 2026-10-08

**「浏览器缓存占了 22G」不是缓存本身有问题，而是几个不同的层被混在一起：可丢弃的加速层、共享的内容寻址仓库、以及悄悄下载的模型权重。删之前先分层，判据是「丢了会不会影响数据与登录态」。**

| 占用 | 是什么 | 删了会怎样 |

|---|---|---| | Service Worker 缓存（Cache Storage） | 网站自己管理的后台缓存，用来离线可用/秒开/后台同步 | 安全：下次重新从服务器拉。数据在服务端，登录态在 Cookies，都不受影响。代价只是「离线打开一个从没访问过且已删缓存的页面」会失败 | | pnpm store（~/Library/pnpm/store） | 内容寻址的共享仓库，各项目 node_modules 是硬链接指过来 | 用 pnpm store prune 只删无引用的孤儿包 = 安全；直接 rm -rf 会打断所有项目的 node_modules | | ~/Library/Caches/pnpm | 元数据/下载缓存，与 store 不是一回事 | 可以更激进地清 | | OptGuideOnDeviceModel（4G，weights.bin，模型 v3Nano = Gemini Nano） | Chrome 自动下载的端侧模型权重，供页面摘要/写作助手/自动填充/DevTools AI 用 | 安全：不影响浏览、历史、密码、登录态；启用相关 AI 功能时会重新下载 |

要点：

  • 判断一个缓存能不能删，看它是不是「可从别处重建」。加速层与模型权重都可重建；硬链接指向的共享 store 一旦整目录删掉，别的项目立刻坏。
  • 缓存体积往往暴露使用史，可作为旁证：飞书（Feishu/Lark）多租户文档 + 多维表格把完整数据与图片塞进本地缓存，单它一家就占了约 20G / 91%；bytedance.larkoffice.com 这类内部租户的缓存，人已离开就基本无用。
  • 官方提供的 prune 语义才是安全的：pnpm store status 报 "Packages in the store are untouched" 说明无损坏包，可放心 prune。
  • 端侧模型是静默下载的：Chrome 判断机器够强就自己拉了 4G，用户往往毫无察觉 —— 所以「我没装过什么大东西」不等于「没有大文件」。

相关