做过小程序开发的朋友都知道，缓存是绕不开的话题。用户打开小程序的每一秒体验，背后都有缓存默默工作的身影。今天咱们就聊聊小程序缓存那些事儿，把原理、用法和踩过的坑一次讲清楚。
什么是小程序缓存
简单说，小程序缓存就是把数据临时存到用户手机本地的一种机制。它有个官方名字叫本地存储，wx.setStorage 存进去，wx.getStorage 取出来。存进去的数据会一直留在用户手机上，除非用户手动删除小程序或者代码主动清掉，否则下次打开还在。
和网页的 localStorage 很像，但小程序缓存能力更强一些。单个 key 能存 1MB 数据，总体上限 10MB。这个容量对大多数业务场景来说够用了，比如存用户的登录状态、浏览记录、搜索历史、页面配置等等。
同步和异步怎么选
小程序的缓存接口分两套，一套同步一套异步。以 wx.setStorage 为例，异步版是 wx.setStorage，同步版是 wx.setStorageSync，多了个 Sync 后缀。
区别很简单。同步版本会阻塞代码执行，一行存完才走下一行，写起来直观，但数据量大时会卡住界面。异步版本不阻塞，操作放后台跑，完成后再回调通知你，界面不卡，适合存大一点的数据或者频繁读写。
实际开发中的经验是：小数据、初始化阶段可以用同步，代码好写不容易出 bug；用户操作触发的读写尽量用异步，别让用户感觉界面顿了一下。
哪些数据适合放缓存
不是什么数据都往缓存里塞，挑对了才能发挥价值。
第一类是用户身份信息。登录成功后的 token、用户 ID，存进缓存，下次打开直接用，不用每次都走一遍登录流程。
第二类是不常变的配置数据。比如城市列表、商品分类、字典表，这些内容一个月都不带改一次的，拉一次接口存起来，后面直接读本地，省流量又快。
第三类是提升体验的临时数据。比如用户浏览过的商品、搜索历史、表单填了一半的内容，缓存起来，用户误退出还能找回。
不适合放缓存的也提醒一下：敏感信息比如密码别明文存；频繁变动的实时数据比如股票价格、库存数量，缓存了反而出错；超过 10MB 的大文件，应该走文件下载的通道，不是缓存该干的活。
一个完整的缓存策略示例
光说不练假把式，来个实战中常用的读取策略。思路是先读缓存，缓存没有或者过期了再请求接口，拿到数据后写回缓存，并打上时间戳。
具体做法是：存数据的时候顺便存一个时间字段，读的时候判断当前时间和存储时间的差值，超过设定时长比如 10 分钟，就当作过期处理，重新走接口。这样既享受了缓存的速度，又保证了数据的新鲜度。
再进阶一点，可以做先返回旧数据、后台悄悄更新的模式。用户一进来先看到缓存内容，秒开没商量，同时后台请求最新数据，到了再刷新界面。用户感知上就是又快又新。
缓存常见坑点提醒
第一个坑是容量超限。缓存总量 10MB，存之前最好算算账，写个 try catch 捕获存储失败的异常，超限时按优先级清理旧数据。
第二个坑是数据结构变更。老版本小程序存的缓存结构，新版本代码读取时字段对不上，直接崩溃。解决办法是给缓存加版本号，版本不匹配就清掉重存。
第三个坑是账号切换。同一个手机换账号登录，上一个用户的数据还在缓存里，串了就尴尬了。缓存 key 里带上用户 ID，或者退出登录时主动清理相关数据。
第四个坑是真机清理。用户在微信里删除小程序，或者用清理工具清缓存，本地数据说没就没。所以缓存只能是加速手段，核心数据必须以服务端为准。
写在最后
小程序缓存用好了是利器，用不好是隐患。核心原则就三条：该缓存的缓存，不该缓存的老老实实走接口；读写注意同步异步的选择；永远做好缓存失效的准备，服务端数据才是唯一真相。把这套思路落地到项目里，小程序的打开速度和用户体验会有肉眼可见的提升。