Angular中已有Services与localStorage，为何仍需使用ngrx/store？

• 单一集中式数据源
  用Services管理状态时，状态往往分散在多个服务、组件中，随着项目迭代，很难追踪状态的分布和流转路径。NgRx将所有应用状态统一存放在一个Store中，任何组件或服务都能以一致的方式访问状态，不用再到处查找状态的存储位置。

• 状态变更的可预测性
  Services里的状态变更通常是直接修改变量值，这类操作没有统一的约束，出问题时根本没法追溯是谁、在什么时机修改了状态。NgRx严格遵循单向数据流规则：只能通过派发Action触发状态变更，所有变更都由纯函数Reducer处理——纯函数的输入输出完全可控，每一次状态变化都有明确的触发源，调试排查问题效率极高。

• 开箱即用的调试追踪能力
  NgRx自带DevTools工具，能实时展示每一次状态变更的详细记录，还支持回滚到历史状态、重播Action序列。用Services的话，你得手动添加大量console.log或者自定义日志逻辑，不仅繁琐，还容易遗漏关键的状态变更细节。

• 跨组件状态共享更可靠
  虽然Services可以通过Subject实现跨组件通信，但多个组件同时订阅、修改服务内状态时，很容易出现竞态条件（比如两个组件同时修改同一个值导致数据不一致）。NgRx的Reducer是纯函数，同一时间只会处理一个Action，从根源上避免了这类问题，状态变更的顺序完全可控。

• 异步逻辑的统一管理
  在Services里处理API请求这类异步操作时，你得自己写订阅、错误处理、加载状态管理逻辑，代码容易冗余且分散在各处。NgRx的Effects中间件可以把所有异步逻辑抽离出来统一管理，还能轻松实现防抖、节流、重试等功能，让组件和Reducer只专注于状态的展示和纯逻辑处理。

• 状态序列化与持久化更简单
  要实现页面刷新后保留状态的需求，NgRx可以通过中间件拦截状态变更，直接序列化后存储到localStorage/sessionStorage；恢复状态时只需将序列化的数据导入Store即可。用Services的话，你得在每个涉及状态的服务里单独写存储、恢复逻辑，重复代码多，还容易出现状态不一致的情况。

• 团队协作的一致性保障
  当团队规模较大时，NgRx的规范（Action、Reducer、Effects的明确划分）能让所有开发者遵循统一的状态管理模式，新人上手更快，代码风格更统一。而Services的写法自由度高，不同开发者可能写出差异极大的状态处理逻辑，长期维护成本很高。

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