Angular Services与sessionStorage的区别及适用场景有哪些？

这两个是完全不同维度的存储方案，不存在互相替代的关系，核心差异在于：Angular Services 属于运行时内存存储，sessionStorage 属于浏览器会话级持久化存储，这也是为什么有了 Services 还需要用到 sessionStorage 的核心原因。

为什么有 Angular Services 还需要 sessionStorage？ #

Angular Services 本身有两个不可避免的限制，刚好可以被 sessionStorage 补足：

• Services 里的数据是存在应用运行时内存里的，只要页面刷新、标签页关闭，应用实例销毁，所有存在 Services 里的数据会直接丢失
• Services 是单标签页实例隔离的，同一个应用开多个标签页访问时，每个标签页的 Services 是独立实例，数据完全不互通
  而 sessionStorage 只要当前标签页不关闭，哪怕多次刷新页面，存储的数据都不会丢失，刚好解决了页面刷新数据丢失的问题。

各自适用场景 #

优先使用 Angular Services 的场景 #

• 需要存储响应式状态：比如全局导航选中态、实时更新的通知数、临时交互状态，配合 RxJS 的可观察对象可以做到状态更新时所有订阅组件实时响应，这一点是 sessionStorage 无法实现的，总不能靠轮询读取存储来同步状态
• 需要存储不可序列化数据：比如函数、DOM 引用、RxJS 订阅实例、类实例对象等无法转成 JSON 字符串的内容，sessionStorage 只能存字符串，无法存储这类数据
• 需要存储高敏感临时数据：比如短期有效接口令牌、临时操作权限，Services 里的数据会随应用销毁直接清除，相比存储在 sessionStorage 里被 XSS 攻击盗取的风险更低
• 存储全局运行时配置：比如应用启动时拉取的字典表、枚举值、全局功能开关，只需请求一次存在 Services 里全应用通用，不需要反复读取存储或者调用接口

优先使用 sessionStorage 的场景 #

• 需要页面刷新后保留的临时状态：比如多步骤表单半完成数据、用户未提交的编辑内容，存在 Services 里刷新就丢，存在 sessionStorage 里刷新后可以直接读取恢复，且用户关闭标签页后会自动清除，不会残留垃圾数据
• 需要跨路由留存的状态：比如列表页的筛选条件、分页位置、搜索关键词，用户跳转到详情页再返回时可以直接读取 sessionStorage 恢复之前的浏览状态，比把参数全塞在路由 URL 里更整洁，也不需要在 Services 里堆大量用完就忘的临时状态
• 需要减少重复接口请求：比如不常更新的用户基础信息、页面级配置，存在 sessionStorage 里，页面刷新后不需要重新调用接口拉取，直接读存储即可，降低服务器压力

实际开发中两者经常配合使用：比如把需要刷新留存的状态同时存在 Services 和 sessionStorage 里，组件直接订阅 Services 里的响应式状态，每次状态更新时同步写入 sessionStorage，应用初始化时优先读取 sessionStorage 的数据初始化 Services 状态，兼顾响应式体验和刷新留存的需求。

内容的提问来源于stack exchange，提问作者2727