小程序数据缓存的核心原理是：把高频读取、变动不频繁的数据存到客户端本地，下次打开直接读取，从而减少网络请求、加快页面打开速度。望谟县开发者最常用的本地存储是键值对方式，但它本身不会自动过期，必须自己加上过期策略和失效更新，否则用户会一直看到旧数据。

缓存分哪几层

本地存储缓存

小程序提供的本地存储以键值对形式保存，容量一般限制在几兆到十几兆，适合存用户偏好、最近浏览记录、登录凭证这类小数据。它的特点是跨启动保留——用户关掉小程序再打开，数据还在。望谟县开发者常把商品分类、地区列表这类几乎不变的配置缓存下来，避免每次启动都发请求。

内存缓存

页面运行期间存在内存里的数据，比如当前列表页的分页数据，退出页面后即释放。内存缓存速度最快，但不持久，主要用于避免同一页面内反复请求。它通常和本地存储配合使用：内存里没有就查存储，存储过期再请求网络。

缓存什么、不缓存什么

适合缓存的是读多写少、允许短暂延迟的数据：首页推荐、分类列表、商品详情的静态信息、用户基本资料。不适合缓存的是强实时数据：购物车数量、订单状态、库存余量、支付结果。望谟县做电商类小程序时，最常见的线上事故就是把库存和购物车也缓存了，导致超卖和数量对不上。判断标准很简单：这条数据晚几秒更新，业务上能不能接受，能接受才进缓存。

过期与失效策略

给缓存加时间戳

本地存储本身不自动过期，需要在写入时一并存一个"过期时间"。读取时先判断当前时间是否超过过期时间，超过就视为失效、重新请求。比如缓存一个商品列表，过期时间设为十分钟，既减少请求，又不至于让用户看到太久以前的价格。

主动失效与版本号

当后台数据发生关键变化——比如商品下架、价格调整——应在返回数据时带上版本号，前端比对后主动清掉对应缓存。登录态过期、用户退出登录时，要清空与该用户相关的所有缓存，避免下次登录看到上一个人的数据。

更新时机怎么选

常见做法是"打开时先读本地秒开，后台再静默拉新数据"：首次渲染用缓存，用户几乎无等待；请求成功后用新数据替换旧缓存，下次进入就是最新的，这种方式兼顾速度和新鲜度。但对于订单、支付这类页面，应直接请求网络、不读缓存，宁可多等一秒也不能展示错误状态。望谟县团队上线前，应针对每一类数据明确"用不用缓存、缓存多久、何时刷新"，形成清单而不是凭感觉写。

缓存容量管理

本地存储有总容量上限，单条数据也不宜过大。设计时应建立"缓存键命名规范"，比如按页面、按数据类型给key统一前缀，方便后期排查和批量清理。用户退出登录时，要把该用户相关的缓存整体删掉，而不是只清登录态，否则新账号可能读到上一个人的历史记录。望谟县团队还可以在设置页提供"清除缓存"入口，让用户在数据异常时自己一键恢复，减少客服工单。

缓存不是越多越好。每多一份本地缓存，就多一处可能与服务端不一致的地方，维护成本随之上升。正确的做法是先把不缓存时的请求量和耗时统计清楚，只对真正拖慢页面的少数数据做缓存，用数据驱动而不是凭感觉到处加缓存。

常见坑

一是缓存容量超限，大量把图片转成base64存本地导致写入失败；图片应走网络地址，本地只存链接。二是多端数据不一致，用户在A设备改了资料，B设备还读着旧缓存，这类数据要缩短过期时间。三是缓存了登录凭证却没有安全处理，本地存储虽有隔离，但涉及资金的操作仍应以后端校验为准。此外，调试阶段可以专门做一个测试页，列出本地每一个缓存键的内容和过期时间，上线后遇到用户投诉"数据不对"时，先自查是缓存没刷新还是接口本身出错，能大幅缩短排查时间。把这些坑提前想到，缓存机制才能真正提升体验，而不是埋下隐患。