适合缓存的是更新频率低、实时性要求不高的系统级字典（如订单状态）、地域类数据（如省市区）和业务常量（如支付方式）；需通过版本号或时间戳控制更新，封装存取逻辑并校验localStorage可用性、数据完整性与有效性。
网页应用用 localStorage 缓存静态配置字典，核心是把接口返回的字典数据（如城市列表、状态枚举、权限类型等）存下来，后续直接读取，跳过重复请求。但必须加版本或时间控制，否则数据永远不更新。
哪些字典适合缓存
只缓存那些更新频率低、对实时性要求不高的数据：
- 系统级字典：如“订单状态”“用户角色”“审批流程节点”
- 地域类数据：省市区三级联动、国家/货币/语言列表
- 业务常量：支付方式、发货渠道、工单优先级
- 不建议缓存：用户个人设置、消息未读数、库存余量等动态数据
缓存前先做基础校验
每次读取前不能直接用，要检查三件事：
- localStorage 是否可用（隐私模式下可能报 SecurityError）
- 对应 key 是否存在且能 JSON.parse() 成功（避免因格式损坏导致白屏）
- 是否带版本号或过期时间，且当前仍有效
推荐结构示例：{"version":"20261005","expires":1728921600000,"data":[{"id":1,"name":"待审核"},{"id":2,"name":"已通过"}]}
带过期机制的存取封装
不要裸用 setItem / getItem，用一个轻量封装统一处理时效逻辑：
- 存入时自动加上当前时间戳和预设过期时长（比如 24 小时）
- 读取时先比对时间，超时就自动清除并返回 null
- 写入失败（如超出 5MB 限制）时捕获异常，降级为直接请求
例如：cache.set('dict_order_status', data, 24 * 60 * 60 * 1000)，cache.get('dict_order_status') 内部自动判断是否过期。
服务端配合做版本同步
光靠时间戳不够可靠，尤其在灰度发布或紧急回滚时。更稳妥的方式是让后端在响应头或响应体中返回一个稳定标识：
- 构建时生成的 hash（如 menu-v2.3-abc123）
- 数据库字典表的 max(update_time) 时间戳
- 接口返回字段如 {"version":"v2.4","data":[...]}
前端存的时候把 version 拼进 key 或存进 value，下次请求前先比对 version —— 不一致就清旧缓存、重新拉取。
