小程序数据缓存不是把数据往本地一存就完事，而是要按冷热分层：热数据放内存级缓存随取随用，温数据放本地Storage持久化，冷数据每次从服务器实时拉。三层各有各的过期时间，混着用才会出现"用户看到旧数据"的问题。本文讲清冷热分层怎么分、每层的过期策略怎么设计。

冷热数据怎么分层

热数据放哪、存什么

热数据是用户在当前页面马上要用的数据，比如用户基本信息、当前浏览的商品详情页数据。这类数据放在页面变量里（也就是内存），页面不关闭就一直在，读起来零延迟。热数据的生命周期和页面一致：用户离开页面，热数据就释放，下次进来重新请求。

热数据不要往Storage里塞。Storage是磁盘读写，虽然比网络快，但比内存慢几十倍。每次打开页面都去读Storage取用户信息，不如在小程序启动时把用户信息读进全局变量，之后任何页面直接从内存拿。灵寿县用户打开小程序的头两秒体验，差别就在热数据放在哪。

热数据还有一类是页面间传递的临时数据。比如从商品列表点进详情页，要把商品ID传过去；详情页加购后返回列表，列表要知道购物车数量变了。这种跨页传递用页面栈参数和全局事件，不要存Storage，因为它只在当前会话有效。

温数据与冷数据

温数据是跨页面、跨启动会话都要用但不那么频繁的数据：首页推荐配置、分类导航树、搜索历史。这类数据放本地Storage，下次打开小程序直接读，不用走网络。温数据的特征是：变化频率低，但每次启动都要用，存下来能省一次请求。

冷数据是用户对新鲜度敏感的数据：订单列表、实时库存、实时价格、消息通知。这类数据不缓存，每次进页面都从服务器拉。图快把订单列表缓存五分钟，用户付完款回来看到还是待支付，就会重复下单。冷热分层的边界就在这里：用户能容忍多久的旧数据，决定了它是温数据还是冷数据。

每层的过期策略怎么设计

TTL分级设置

温数据存进Storage时，要同时存一个过期时间戳。读取时判断：没过期直接用本地数据；过期了后台悄悄请求服务器新数据替换。不同数据设不同TTL：用户偏好设置TTL可以长一点，半天到一天；首页活动配置TTL短一点，五到十分钟；分类导航树TTL中等，一小时。

TTL设置原则是"宁可短不要长"。TTL设短了，最多多请求几次服务器，网络成本；TTL设长了，用户看到旧活动旧价格，是业务错误。后者代价远大于前者。一个活动已经下线了，用户缓存里还显示着活动价下单，客服纠纷不断。

主动失效与一致性

除了被动等过期，还要有主动失效机制。用户在小程序里改了自己的昵称，改成功后要立刻把本地缓存里的旧昵称清掉，不能等TTL到期。因为用户下次看个人中心时，如果看到的还是旧昵称，会觉得没保存成功。这种"写后即清"是缓存一致性的基本操作。

还有版本切换时的全局失效。小程序发了新版本，数据结构变了（比如加了一个字段），本地缓存里的旧结构会导致新版代码读旧字段报错。启动时检查缓存里存的版本号，和当前版本不一致就清空整个Storage重新初始化。这一步不做，老用户升级新版后必出bug。

弱网下的缓存兜底

用户通勤时在地铁、电梯里网络很差，完全靠服务器渲染会白屏转圈。正确做法是：打开页面先用本地温数据渲染出内容，同时后台请求新数据，请求回来再静默替换。用户看到的永远是有内容的界面，哪怕是稍微旧一点的数据，也比转圈强。灵寿县通勤时间长、地铁信号弱的环境下，这个兜底策略直接影响小程序留存率。兜底时还要在页面角落加一行小字"数据更新于十分钟前"，让用户对数据新鲜度有预期。

但冷数据不能用这个兜底。订单页如果用本地旧数据兜底，用户可能以为没付款又下一单。冷数据在弱网下应该显示"网络加载中，请稍后"，而不是显示旧订单。分层策略的意义就在这里：热温数据兜底体验，冷数据保证准确，不能一刀切。

最后补一个容量管理细节。Storage总容量10MB，不能无限存温数据。要给温数据设总量上限：超过5MB时按最近访问时间淘汰最久没用的数据。比如搜索历史存最近二十条就行，不要把一年前的搜索词都留着。容量满了还继续写会报错，代码里要catch这个异常，写失败了静默丢弃旧数据，不能让用户看到报错弹窗。图片类数据一律不进Storage，走CDN链接本地只存URL，这是10MB额度下的铁律。

小程序数据缓存机制讲解的核心，不是记住wx.setStorage这个API，而是先想清楚每条数据属于哪一层、能容忍多旧，再决定存不存、存多久。灵寿县做缓存设计时多站在用户使用场景过一遍，比堆技术参数有用。