使用NgRx的项目应如何处理非共享状态？

答案很明确：没必要全程统一使用NgRx，应该根据场景选择性使用。

• NgRx的核心价值是解决跨组件/跨模块的状态共享、复杂异步业务逻辑的集中管控，如果你的数据只是组件内部私用，完全不需要套NgRx的流程。
• 强行把私有数据塞进Store，只会带来无意义的冗余：额外编写Action、Effect、Reducer，让状态模型臃肿不堪，维护成本飙升，却得不到任何实质收益——毕竟这些数据本来就不需要共享，也不需要全局可追溯。
• 所谓“项目用了NgRx就必须全流程统一”是教条主义，真正的最佳实践是让工具匹配场景：
  • 当状态需要被多组件访问、修改，或者业务逻辑涉及多步异步操作、状态依赖复杂时，用NgRx来集中管理，发挥它的优势。
  • 当数据仅组件私有、业务逻辑简单直接时，直接在组件或专属服务里处理API请求即可，代码更简洁，逻辑更直观。
• 如果团队担心规范混乱，可以提前约定NgRx的适用边界，明确哪些场景必须用、哪些可以自主选择，平衡一致性和开发效率。

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