sessionstorage用于缓存静态字典数据而非拦截请求,遵循“先请求→序列化存储→读取解析→失败则重请求”逻辑,建议存入带时间戳的对象并用try/catch防护,读取时校验数据有效性而非仅判null。

SessionStorage 本身不直接缓存请求,而是用来暂存已获取的静态字典配置数据,避免在同个标签页内重复发起相同请求。关键在于“请求—存储—读取”的协同逻辑,而不是让 sessionStorage 自动拦截或管理网络请求。
先请求再存入:首次加载时获取并缓存
页面初始化或首次需要字典时,先发请求(如 fetch),成功后立即将结果存入 sessionStorage。注意必须序列化为字符串:
- 用
JSON.stringify()转换对象后再调用sessionStorage.setItem('dict_roles', data) - 建议加上时间戳或版本标识,便于后续判断是否需刷新(例如
{ data: [...], timestamp: Date.now() }) - 务必包裹
try/catch,防止序列化失败或超出容量导致静默中断
读取优先于请求:每次使用前检查缓存
后续访问字典时,不再无条件发请求,而是先查 sessionStorage:
批量分析录音转写,输出多维度拓客报告。触发词:录音分析、总结、音频总结、拜访记录总结。当用户提及「分析录音」「看看录音数据」「最近的录音」「通话记录」且意图为批量统计/分析时触发。仅出现「录音」或「拜访」时需结合上下文,若仅查看单条详情则不触发。
- 用
sessionStorage.getItem('dict_roles')获取字符串 - 存在则
JSON.parse()解析;解析失败或返回null,再走请求流程 - 不要依赖
=== null判断——空字符串、"null"字符串都可能被存入,应结合业务逻辑校验结构有效性(比如检查是否有length或id字段)
配合简单过期机制:避免长期使用陈旧配置
虽然 sessionStorage 关闭标签页就清空,但用户可能长时间停留。若字典有更新需求,可手动加时效控制:
- 存入时记录时间:
sessionStorage.setItem('dict_roles', JSON.stringify({ data: res, fetchedAt: Date.now() })) - 读取时检查:
if (entry.fetchedAt (例如30分钟) - 不需要复杂 TTL 库,一行时间差判断足够应对多数静态字典场景
不跨 tab 共享是特性不是缺陷
如果多个标签页都需要同一份字典,sessionStorage 不适用——它只对当前 tab 有效。此时应改用 localStorage,并自行处理并发写入和过期清理;但要注意:storage 事件不会在当前 tab 触发,所以不能靠监听自身写入来更新界面,得在 set 后同步更新内存变量或触发重渲染。
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










