清理过期本地持久化缓存需主动识别并干预“已失效但未自动回收”的数据，涵盖浏览器（Service Worker Cache、IndexedDB）、App本地存储（如vivo浏览器offline目录）及Redis/SQLite等客户端缓存系统。
清理过期的本地持久化缓存，关键在于识别“已失效但未被自动回收”的数据，并主动干预其生命周期。这类缓存常见于浏览器（如 Service Worker Cache、IndexedDB）、App 本地存储（如 Android/data 下的离线资源）、或自建客户端缓存系统（如基于 Redis 或本地 SQLite 的持久化层）。它们不像内存缓存那样随进程退出而消失，容易长期滞留并占用空间、引发页面异常。
一、浏览器端：精准定位并清除过期离线资源
现代浏览器使用多种机制持久化资源，其中 Service Worker 控制的 Cache Storage 最易积累过期内容，且不会自动按 HTTP 头清理。
- 打开目标网站后，按 Ctrl+Shift+I（Windows）或 Cmd+Option+I（macOS） 打开开发者工具
- 切换到 Application → Cache Storage，左侧会列出所有注册的缓存名称（如
vivo-offline-cache-202604） - 点击任一缓存名，右侧显示全部缓存条目；观察 URL 路径和响应头中的
Expires或Cache-Control: max-age=值 - 若发现大量请求返回
504、404或响应体为空，基本可判定该缓存已失效；选中对应缓存名，点击 “Delete” 即可清空整组 - 更稳妥的做法是：在 Application → Clear storage 页面，勾选 Cache storage + Service Workers 后点击 Clear site data，强制重置站点级离线能力
二、移动端 App：清理隐藏的离线文件目录
以 vivo 浏览器为例，其离线网页实际保存在 Android/data/com.vivo.browser/files/offline/ 目录下，每个子文件夹对应一次保存行为，命名含时间戳（如 20260420_1532），但系统不自动删除早于有效期的文件夹。
- 用手机自带的文件管理器进入路径：
Android/data/com.vivo.browser/files/offline/ - 按修改日期排序，筛选出最后修改时间早于 2026年4月25日的文件夹（参考当前时间为 2026年9月，超 4 个月未更新即视为过期）
- 逐个点开，检查内部是否有
index.html及配套资源；若打开空白或提示“已过期”，可安全删除整个文件夹 - 也可借助 i管家 → 深度清理 → 过期离线资源，它能扫描
novel_cache、AppCache等隐藏子目录，识别孤立 HTML 快照与断连 JS/CSS
三、服务端/本地数据库缓存：结合 TTL 与手动校验
对于使用 Redis 或本地 SQLite 存储的业务缓存，过期依赖配置策略，但存在“逃逸”风险——比如定期清理频率低、惰性删除未触发、或 key 未设 TTL。
- Redis 中执行
redis-cli --scan --pattern "*cache*" | xargs -L 1 redis-cli ttl查看匹配 key 的剩余存活时间，ttl 返回-2表示 key 不存在，-1表示永不过期，需人工评估是否应加 TTL - 对明确已废弃的业务模块（如停用的老版 API 文档页），可直接用
redis-cli --scan --pattern "doc_v1:*" | xargs redis-cli del批量清除 - 若用 SQLite 做本地持久缓存，建议表结构中包含
created_at和expires_at字段，定期运行DELETE FROM cache_table WHERE expires_at < datetime('now')
四、通用原则：从源头减少过期缓存生成
清理是补救，阻断才是长效方案。
- 在网页中禁用预加载：vivo 浏览器设置里关闭 “网页预加载” 和 “后台同步”，避免 Service Worker 自动抓取新资源却无人校验
- 开发侧为静态资源添加版本哈希（如
app.a1b2c3.js），使缓存自然失效，避免复用旧 manifest 导致离线包错乱 - App 内 WebView 加载离线页前，先调用
shouldInterceptRequest检查本地文件是否存在且未过期（通过读取文件 lastModified 时间比对）
