前端indexeddb需手动实现过期机制:写入时添加expiresat时间戳,用dexie.js定时分批清理+读取时惰性校验,并辅以监控告警与容量兜底。

前端大型缓存数据库(如 IndexedDB)本身不支持自动过期机制,必须由开发者主动设计时间戳+清理逻辑。定期清理的核心不是“等它满了再清”,而是“在合适时机主动释放无效数据”,避免磁盘占用失控、查询变慢或同步冲突。
给每条数据打上时间戳
存储时记录创建/更新时间,是后续判断是否过期的基础。不要依赖服务端时间,统一用 Date.now() 生成毫秒级时间戳。
- 写入数据时,显式添加
createdAt和expiresAt字段(例如:3天后过期 →expiresAt: Date.now() + 3 * 24 * 60 * 60 * 1000) - 字段名保持一致,便于后续批量扫描;建议用
expiresAt而非ttl,语义更明确、计算更安全 - 对已有数据迁移,可设默认过期时间(如 7 天),避免历史数据永远滞留
用 Dexie.js 实现定时扫描清理
Dexie.js 封装了 IndexedDB,提供简洁的查询和事务能力。定期清理推荐用 后台定时任务 + 分批删除,防止阻塞主线程。
- 使用
setInterval每 4–6 小时执行一次清理(频率太高无必要,太低易积压) - 每次只查并删最多 50 条过期数据,用
where('expiresAt').below(Date.now())定位,配合limit(50)控制负载 - 删除前开启事务,确保原子性;失败时捕获错误,不中断后续清理
- 示例代码片段:
const db = new Dexie('MyAppDB');
db.version(1).stores({ logs: '++id, createdAt, expiresAt' });
<p>function cleanupExpiredLogs() {
db.transaction('rw', db.logs, async () => {
const expired = await db.logs
.where('expiresAt')
.below(Date.now())
.limit(50)
.toArray();
if (expired.length > 0) {
await db.logs.bulkDelete(expired.map(l => l.id));
console.log(<code>已清理 ${expired.length} 条过期日志</code>);
}
}).catch(err => console.warn('清理日志出错:', err));
}</p><p>setInterval(cleanupExpiredLogs, 6 <em> 60 </em> 60 * 1000); // 每6小时一次</p>结合访问时惰性清理(读时校验)
定时清理不能覆盖所有场景(比如用户长时间不刷新页面)。在关键读取路径中加入过期检查,能及时剔除“刚过期但还没被扫到”的数据。
- 查询单条数据后,立即比对
expiresAt与当前时间;若已过期,立刻调用delete()并返回空值 - 适用于用户登录态 token、临时配置、离线表单草稿等对时效敏感的数据
- 注意避免在高频循环中重复校验,可加简单缓存标记(如最近1分钟内已确认未过期)
监控与兜底策略
清理不是一劳永逸。需建立可观测性,防止策略失效导致缓存膨胀。
- 启动时或每日首次加载,统计各 objectStore 的数据量和平均过期率(如
count / total),异常偏高时上报告警 - 设置总容量软上限(例如 IndexedDB 占用超 50MB),触发强制全量清理或提示用户手动清空
- 版本升级时,在
upgrade回调中清空旧 schema 的过期数据,避免跨版本残留
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南











