小程序本地存储如何使用？需要注意哪些问题？

简化版

小程序可以用 wx.setStorage、wx.getStorage、wx.removeStorage、wx.clearStorage 进行本地存储，也有同步版本。它适合保存 token、用户偏好、缓存数据等，但不能存敏感明文数据，不能把它当数据库，也要注意容量、过期策略和数据一致性。

详细版

小程序本地存储分异步和同步 API：

异步：wx.setStorage、wx.getStorage。
同步：wx.setStorageSync、wx.getStorageSync。

异步 API 不阻塞主逻辑，更适合大多数场景；同步 API 写起来简单，但不适合频繁或大量读写。

本地存储常用于：

保存登录 token。
保存用户配置。
缓存接口数据。
记录引导页是否展示过。

注意点包括：设置过期时间、处理读取失败、避免存储过大数据、敏感信息不要明文保存、退出登录时清理相关缓存。

完整版教学

一、本地存储解决什么问题

小程序是无页面刷新概念的应用形态，但用户关闭再打开后，内存状态会丢失。本地存储可以保存跨会话数据，比如登录凭证、主题偏好、城市选择。

它和页面 data 不同。data 是当前页面渲染状态，本地存储是持久化数据。

二、同步和异步 API 的选择

同步 API 使用简单：

const token = wx.getStorageSync('token')

但同步读取会阻塞当前 JS 执行。如果频繁操作或数据较大，可能影响体验。

异步 API 更适合业务代码：

wx.getStorage({
  key: 'token',
  success(res) {
    console.log(res.data)
  }
})

项目中也常封装成 Promise，方便配合 async/await 使用。

三、缓存策略怎么设计

缓存不是只存进去就结束，还要考虑何时失效。

常见做法是缓存值时一起保存时间戳：

{
  value: data,
  expireAt: Date.now() + 10 * 60 * 1000
}

读取时判断是否过期。过期就删除并重新请求。

对于列表缓存，还要考虑用户刷新、分页、筛选条件变化。缓存 key 应该包含关键参数，否则容易读到错误数据。

四、面试追问与工程落地

面试官可能问：“token 可以存在 storage 里吗？”

可以存，但要理解风险。小程序本地存储不是绝对安全的保险箱，不能存非常敏感的明文信息。token 应该有有效期，服务端也应支持失效和刷新机制。退出登录时必须清理 token 和用户相关缓存。

工程中建议封装统一 storage 模块，处理命名空间、JSON 序列化、过期时间、异常兜底，避免每个页面直接散落读写逻辑。

五、把缓存设计成带元数据的记录

可靠缓存不只存 value，还应包含版本、过期时间和必要的查询维度。比如商品列表按城市和页码缓存，key 可设计为 v2:product:list:shanghai:1；版本变更时无需遍历修改旧结构，新代码自然读不到旧 key。

{
  version: 2,
  value: data,
  savedAt: 1710000000000,
  expireAt: 1710000600000
}

上例 TTL 为 600000ms = 10 分钟。读取时先检查结构和版本，再比较 Date.now()；过期后可以直接删除并请求，也可以先展示旧值、后台刷新，但后者必须标记数据可能陈旧，不能用于余额、库存等强一致决策。

数据类型	是否适合 storage	失效策略
主题、城市偏好	适合	用户修改时覆盖
接口列表缓存	有条件适合	TTL + 参数化 key
业务 token	可存但有泄露风险	过期、撤销、退出清理
密码、AppSecret、session_key	不适合	不应进入客户端
权威余额、支付状态	不作为事实来源	每次向服务端确认

六、容量、并发与失败恢复

小程序 storage 有平台容量限制，常见官方口径为同一用户同一小程序约 10MB；工程上不要用到临界值才清理，应统计体积、限制单项大小并采用 LRU/按业务清理。图片、视频和超大列表更适合文件缓存或服务端分页，不能因为 API 接受对象就把 storage 当数据库。

同步 API 会阻塞当前逻辑执行，适合启动时少量读取关键配置；大数据和频繁读写优先异步。假设启动阶段连续同步读取 50 个 key，每次磁盘与反序列化平均 4ms，累计就可能阻塞约 200ms；把配置聚合为少量记录或并行异步读取更稳妥。

storage 没有跨多 key 的数据库事务，两个异步流程同时“读旧值 → 加一 → 写回”可能丢失一次更新。计数、库存等权威并发状态必须放服务端；客户端缓存写入失败、空间不足或 JSON 结构损坏时，应捕获错误、删除坏记录并回源，而不是让页面无法启动。

退出登录应按命名空间删除该用户的 token 和私有缓存，不宜随手 clearStorage 清掉设备偏好或其他模块数据。多账号切换时把 user id 纳入 key，避免 A 用户退出后 B 用户读到 A 的缓存。

记忆钩子：storage 是“可丢、可过期、可重建”的客户端缓存，不是可信数据库，也不是保险箱。

七、常见误区与追问

误区：storage 保存成功后数据就永久可靠。 用户可清理、客户端可能淘汰或写入失败，业务必须允许缺失并回源。
误区：同步 API 代码短，所以所有读写都用同步版本。 高频或大数据同步 I/O 会阻塞逻辑执行，影响启动与交互。
误区：退出登录应该直接 clearStorage。 这可能误删主题、引导状态等无关数据，应按用户命名空间精准清理。
追问：token 能否放 storage？ 可以作为常见客户端持有方式，但必须接受客户端可读风险，并依靠短有效期、撤销和服务端鉴权降低影响。
追问：缓存 key 为什么要包含参数和版本？ 避免不同查询互相污染，并让数据结构升级时自然隔离旧缓存。
追问：缓存过期后一定要阻塞页面重新请求吗？ 不一定；非关键数据可先展示旧值再刷新，强一致数据则不能以过期缓存决策。
追问：如何处理缓存解析失败？ 捕获异常、校验 schema，删除损坏项并回源，同时记录不含敏感数据的诊断信息。

八、加强记忆

本地存储按“key、value、元数据”设计：key 带命名空间、用户和查询维度，value 只放可重建数据，元数据记录版本与过期时间。同步 API 只做少量关键读取，容量和失败要有兜底；token 可缓存但不是绝对安全，密码、AppSecret、session_key 和权威业务状态绝不能交给 storage 承担。

简化版

详细版