ngrx store.select()返回的Observable与普通RxJs Observable的差异及转换方法

二者本身都符合RxJS规范的Observable实现，不存在本质类型割裂，你在控制台观察到的两类输出描述差异，来自实现层面的几处核心区别：

• 冷热流属性差异：日常手写的普通RxJS Observable大多是冷流（比如通过of、from或new Observable()创建的实例），每次新订阅都会重新执行流内部的数据生产逻辑；store.select()返回的是热流，它会全局共享内存中的ngrx store状态，新订阅者直接获取最近一次的状态快照，不会重复触发状态计算流程
• 预置管道逻辑差异：store.select()返回的实例并非裸Observable，它内部已经默认挂载了distinctUntilChanged()（基于引用相等判断过滤重复值）、状态切片匹配等内置逻辑，这些是原生普通Observable不具备的
• 实例元数据差异：ngrx在创建这类选择器流时，会给实例附加专属的调试标识、自定义的字符串描述，这是控制台打印输出不一致的直接原因，不代表流的类型不兼容

store.select()的返回值本身就是标准RxJS Observable，可以直接传入所有支持普通Observable的API、操作符或模板异步管道，不需要做强制类型转换。
如果你需要完全剥离ngrx附加的内置行为，拿到和原生创建的Observable行为完全一致的流，可以通过管道简单封装：

const plainCustomState$ = store.select(selectTargetFeature).pipe(
  // 手动控制流的订阅共享、值过滤规则，自定义流行为
  share({ connector: () => new ReplaySubject(1) })
)

注意：不建议随意移除store.select()内置的distinctUntilChanged逻辑，否则会触发不必要的组件变更检测，影响应用性能。

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