Angular 状态管理指南

你在解决什么问题

Angular 应用里状态往往散落在组件、BehaviorSubject 服务和 HTTP 回调之间：局部 UI 与全局业务数据边界不清，Signals 与 RxJS 混用导致订阅泄漏或重复渲染，乐观更新与 NgRx Effects 的取舍也缺少统一参照。本技能把「该放哪一层、该用哪套 API」写成可执行的决策与模式，而不是泛泛介绍库名。

技能如何组织内容

状态分类与选型用表格区分局部、共享、全局、服务端、URL 与表单状态，并对应到 signal()、Signal 服务、NgRx/Akita/Elf、ActivatedRoute、Reactive Forms 等方案。

快速上手路径从三种 Signal 模式入手：简单 Signal 服务、功能级 Signal Store、以及 NgRx 的 SignalStore；再覆盖 NgRx Store 的功能切片（feature slice）与组件消费方式，以及 Component Store 这类基于 RxJS 的局部功能状态。

服务端状态单独讲 HTTP 与 Signals 的组合，避免把远程缓存误当成全局 reducer。

最佳实践与反模式强调：computed() 承载派生数据、用 set()/update() 改信号、复杂流程才上 NgRx；避免在 store 里存可计算字段、在组件里手动 subscribe 而模板不用信号，以及 RxJS 与 Signals 无桥接地混写——文档给出 toSignal / toObservable 的迁移与桥接思路。

适用边界

任务与 Angular 状态无关时不要启用；需要 React 状态管理应改用对应 React 技能。技能不替代官方文档细节，而是帮你在 Signals、NgRx、Akita 之间做架构级选择并落地常见模式。