小程序缓存管理器教程｜规则化预取与版本号失效｜弱网页面秒开不翻旧价 – MPForge
直接回答：这是一篇写给零售商家与小程序开发的小程序缓存管理器教程：用规则匹配控制活动页预取，用版本号做失效，再配一个店长可用的手动清理入口，解决弱网下活动页打不开、改价后用户看到旧价这两类高频客诉。MPForge（DEVDIY 旗下）在零售试点里跑通这套方案后，弱网页面可交互时间改善约 30%。
一、旧价客诉的根子：缓存没有失效规则
先说清一个事实：缓存管理器要解决的是「规则化预取与失效」，不是把接口结果一股脑塞进本地。零售活动页改价后，顾客翻到的还是昨天的价格，客服只会说「清一下缓存就好」——这句话每周能换来五条客诉。问题的根子是缓存只管存、不管换：没有版本号，没有失效条件，改价靠用户自己发现。正确做法是按 URL 规则匹配缓存哪些接口、按版本号触发失效、活动下线主动清理，三件事配套才叫「管理」。配置类页面的骨架数据可先落本地再后台刷新，思路与 离线缓存方案 一致，预取时机参考 后台预取任务。
二、规则怎么写：哪些能缓存、哪些碰都不能碰
规则写得宽，缓存就变成事故源；规则写得窄，弱网优化等于白做。按资源类型划边界，一张表定死：
| 检查项 | 达标口径 | 常见错误 |
|---|---|---|
| 可缓存资源 | 活动列表、类目配置、页面骨架等公共数据 | 把个性化价格、券码一起缓存 |
| 禁存内容 | 用户隐私明文、支付结果一律不落缓存 | 图省事全量缓存接口返回 |
| 失效机制 | 版本号驱动，改价先升版本再发 | 只靠过期时间，改价延迟数小时 |
| 清理入口 | 店长端提供强制刷新按钮 | 清理逻辑只写在小程序里没出口 |
| 双轨口径 | 管理器管规则化资源，Storage 管键值配置 | 两套各存一份互相覆盖 |
最容易翻车的是规则过宽：把带个性化券价的接口也匹配进缓存规则，不同顾客看到同一份旧券，比不缓存还糟。规则上线前先在测试环境跑一遍「同一接口、两个账号」的比对。
三、改价发布流程：升版本、抽检、留话术
缓存策略不是开发一个人的事，运营改价的动作必须写进 SOP。活动变更按固定三步走：第一步改价完成先升数据版本号，第二步在至少三台真机上抽检活动页价格与库存展示，第三步客服话术同步更新——遇到顾客问价格不一致，先引导刷新再核对，而不是把「清缓存」当万能答案。活动下线当天要做一次显式清理，否则下线页面的骨架数据还挂在本地，用户点进去看到的是已结束的活动。库存口径与活动边界另见 活动库存余量管理，改价引发的对账问题可对照 支付对账日常 的口径。
四、落地步骤：五步把缓存管起来
顺序别颠倒：先划边界，再写规则，最后才是预取。按这五步执行：
- 盘点接口：列出活动页、配置页所有接口，标注哪些公共可缓存、哪些含个人信息禁止落盘。
- 写匹配规则：按 URL 前缀与参数特征写规则，规则表进代码仓库，改规则走变更单。
- 接版本失效：配置下发带版本号，客户端发现版本变化即刷新缓存，改价流程绑定升版本动作。
- 给清理出口：店长端做「强制刷新」按钮，验收时演示改价后旧价清掉的完整链路。
- 弱网验收：把弱网场景写进提审前用例，验证缓存命中时页面可交互、缓存未命中时降级提示可接受。
五、避坑清单
三条坑都出在「没闭环」：下线不清、双轨混用、规则写死。
- 活动下线必须清缓存：把「下线即清理」写进活动 SOP 的最后一步，谁下线谁确认，不靠用户自行刷新。
- 别和管理器外的 Storage 双轨并存：同一份数据两处存储必然出现新旧打架，先定分工再动手。
- 规则别写死在代码里：规则要可配置可灰度，紧急修正缓存策略不该等一次发版。
- 别缓存支付相关结果：支付状态永远以服务端为准，本地缓存只做展示优化，对账口径以 支付流程教程 为准。
六、常见问题 FAQ
缓存管理器和 Storage 有什么区别？
管理器偏规则化的资源缓存：按 URL 规则匹配、按版本号失效、批量清理；Storage 偏单个键值的持久存储。各管一摊，同一份数据只存在一处。
缓存多大合适？
按平台存储限额预留余量，优先缓存配置与列表骨架这类公共数据，单条大响应考虑裁剪字段再落缓存，别原样整包存。
店长怎么强制刷新？
店长端做一个显式的「强制刷新」入口，触发后清理管理器缓存并重新拉取；验收时店长要亲手操作一遍，不能只看开发演示。
缓存策略和 GEO 地理位置配置有关系吗？
没有。GEO 指地理位置配置：门店地址、经纬度、服务类目，决定附近检索展示，不是按城市做地域 SEO；门店列表这类接口是否缓存，才属于本文的规则范畴。
改价后多久用户能看到新价格？
版本号机制下发后，用户下次进入页面即触发刷新；对价格敏感的活动，配合抽检真机确认，目标是从改价到展示生效控制在分钟级，而不是等缓存自然过期。
