RxJS中为何推荐使用lastValueFrom替代即将弃用的toPromise()？

弃用 toPromise() 的核心原因 #

• 行为歧义大，易引发线上隐患
  toPromise() 的核心行为没有在命名上得到体现：当 Observable 正常完成但没有吐出任何值时，toPromise() 会静默返回 resolve(undefined)，这类问题不会触发错误提醒，极难排查。同时如果 Observable 吐出多个值，toPromise() 只会取最后一个值，这一逻辑对不熟悉源码的开发者完全不透明。
  对应的替代方案 lastValueFrom 从命名上就明确表达了「取 Observable 最后一个值」的语义，遇到空 Observable 时会主动抛出 EmptyError，异常场景提前暴露，符合绝大多数业务开发的预期。
• 类型安全性不足
  toPromise() 的返回类型固定为 Promise<T | undefined>，即便你的 Observable 泛型明确声明不会返回空值，也必须额外处理 undefined 的边界情况，增加了不必要的类型判断成本。lastValueFrom 默认返回 Promise<T>，仅在主动配置空流默认值时才会变更返回类型，类型严谨性大幅提升。
• 错误处理逻辑不符合直觉
  大多数开发者默认认为只有 Observable 抛出异常时才会进入 Promise 的 reject 分支，但 toPromise() 把「空流完成」这种明显不符合业务预期的场景也放在了 resolve 分支，和开发者的直觉不符，容易引发 catch 逻辑漏判的问题。

关于语法简洁性的调整考量 #

你觉得 .toPromise() 语法更简洁是非常正常的感受，官方做出这个调整主要是基于 RxJS 整体的生态设计方向：

• 面向 Tree Shaking 优化
  .toPromise() 是挂载在 Observable 原型上的方法，只要项目中引入了 Observable，即便你从来没有用过 toPromise()，这个方法也会被打包到最终产物中，无法被摇树优化。而 lastValueFrom 是独立的纯函数，只有你主动导入使用时才会被打包，能有效减少产物体积。
• 统一 API 设计风格
  RxJS 从 v6 开始就一直在推进「纯函数优先、减少原型链扩展」的设计思路，所有新的操作符、工具方法都采用独立导入的形式，不再往 Observable 原型上挂载额外方法，整个库的 API 风格更统一，也更便于做类型推导和版本迭代。
• 扩展灵活性更高
  独立纯函数的形式更便于后续扩展能力，比如 lastValueFrom 支持通过第二个参数配置空流默认值：

const result = await lastValueFrom(empty$, { defaultValue: 0 })

这类扩展如果要在原型方法上实现，需要修改全局 Observable 的类型定义，灵活性极低，还容易引发不同第三方库的类型冲突。

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