小程序本地存储总容量上限是10MB，开发者既要用缓存提速，又不能把有用的数据挤掉，还要保证用户看到的不是过期信息。缓存设计的难点不在"存"，而在"存多少、存多久、什么时候刷新"三件事上想清楚。

小程序本地存储的容量边界

Storage的10MB限制

小程序提供的wx.setStorage系列接口，本质是在用户手机上开一块专用磁盘空间，单个小程序所有用户加起来在一台设备上的总存储不能超过10MB。这个限制是微信平台定的，开发者改不了。超过上限时写入会直接失败，如果代码没做异常捕获，后续逻辑就会中断。

10MB听起来不少，但存图片就很紧张。一张压缩后的商品图200KB，存50张就10MB了。所以本地Storage适合存文本类数据：用户登录态、浏览历史、最近搜索词、配置项，不适合存图片大文件。图片应该走CDN链接，本地只存URL。

哪些数据适合放本地

适合缓存的数据有三个特征：读取频率高、变动不频繁、数据量小。比如用户基本信息、首页推荐配置、分类导航、上次浏览位置。这些数据每次打开小程序都要用，从服务器拉要等网络，从本地读毫秒级返回，体验明显更顺。

不适合缓存的数据包括：订单列表、实时库存、实时价格、消息通知。这类数据用户对新鲜度敏感，缓存了反而误导。订单详情可以短暂缓存，但订单列表每次进页面都要请求最新，不能图快存本地。

缓存与服务端数据怎么同步

过期时间策略

缓存不能永久有效，必须设过期时间。常见做法是存数据时同时存一个时间戳，读取时判断距上次写入是否超过阈值。比如首页配置缓存5分钟，5分钟内直接用本地，超过5分钟后台悄悄请求最新数据替换。用户看到的还是旧数据，但下一次打开就是新的了。

不同数据用不同过期时间。用户信息缓存可以长一点，半天更新一次；活动页配置缓存短一点，十分钟；购物车数据不缓存，每次进页面从服务器拉，因为购物车可能在别的设备上变了。过期时间不是越长越好，也不是越短越好，按数据更新频率定。

下拉刷新与主动更新

除了被动等过期，还要给用户主动刷新的入口。列表页做下拉刷新，用户主动拉下时强制请求服务器最新数据，清掉本地缓存重写。这种方式用户可控，刷新完看到的一定是新的，心理上也踏实。

鸡泽县这类一二线城市，用户多在地铁、电梯等弱网环境下使用小程序。弱网时如果没有本地缓存，页面会白屏转圈。合理的做法是：打开页面先用本地缓存渲染出骨架，同时后台请求新数据，请求回来再替换。用户看到的永远是有内容的界面，不会因为网络差而流失。

常见缓存问题怎么处理

前面讲了容量边界和同步策略，这一节集中排雷。做小程序数据缓存机制讲解时，最容易踩的就是下面这两类坑。

缓存污染与脏数据

用户退出登录后，如果不清空本地缓存，下一个人用同一台手机打开小程序，可能看到上一个人的收货地址、手机号。这是严重的隐私问题。登录态切换时必须主动调用clearStorageSync清掉所有用户相关缓存，不能只清token。

另一种脏数据是版本更新导致的。小程序发了新版本，本地缓存的还是旧版本的数据结构，新版代码读旧字段会报错。发版时要给缓存加版本号，启动时发现版本不匹配就清空旧缓存，避免新旧结构混在一起。

多端登录的数据一致性

用户在手机上A加了购物车，用手机B打开小程序，本地缓存里还是B自己的旧数据。这时候如果直接读本地，就看不到A加的商品。解决方案是购物车、收藏这类强一致数据不走本地缓存，每次进页面都请求服务器；只有弱一致的偏好设置才用本地缓存。

鸡泽县这种用户通勤时间长、频繁切换网络的环境下，缓存策略直接影响留存。合理的缓存让用户二次打开秒进，不合理的缓存让用户看到旧数据产生不信任。设计缓存时多站在用户使用场景想一遍，比单纯堆技术参数有用。

数据缓存是性能优化手段，不是数据存储方案。理解10MB容量边界、设计好过期策略、处理好登录态和版本切换，小程序数据缓存机制才能真正提速而不是制造bug。