最近重构一个数据同步组件，翻旧代码才发现缓存层是 Map + SharedPreferences + 手写文件 IO 混着用的，索性把本地缓存方案重新梳理了一遍。
如果你的需求只是缓存接口响应几分钟、存点用户配置、或者离线保存草稿，选型其实不复杂。真正麻烦的是"既要又要"的场景：既要快、又要持久、还要监听变化、还得控制内存。
三个常见方案的真实体感：
内存缓存（Map / LRU）：最快，进程一杀就没。我之前把 token 放进内存 Map，应用被系统回收后用户重开就要重新登录，体验很差。
SharedPreferences / UserDefaults：简单 KV 存配置够用，但存大对象会卡 UI，频繁写入有性能问题，key 散落各处也不安全。
文件缓存（JSON / Room / SQLite / CoreData）：结构化、可查询、容量大。代价是 schema、迁移、版本兼容都得自己管。
我选型时会问自己三个问题：
- 数据丢了用户会不会感知到？会 → 必须持久化；不会 → 内存就行
- 有没有结构化查询需求？有 → 文件/SQL；没有 → KV 即可
- 写入频率高不高？高 → 避开 SharedPreferences，考虑批量写或内存层
几个容易踩的坑：把缓存当数据库用（缓存应该有 TTL，能容忍丢失）、忘了做容量控制（几个月后用户手机存储报警）、UI 线程同步读 SP 在老 Android 上会 ANR、不是所有本地数据都需要加密。
我的结论：缓存没有银弹。先想清楚数据的生命周期，比选哪个库重要得多。下次给项目加缓存前，建议先别急着换库，把现有数据分类一遍：哪些是配置、哪些是临时、哪些是业务数据。分类清楚后，技术选型自然就清晰了。
如果你也在重构老项目的缓存层，欢迎交流踩过的坑。
Top comments (0)