neverthrow对异步函数有什么作用？是否需要改用ResultAsync返回值

你的疑问是很多刚接触neverthrow的开发者都会遇到的，是否需要把异步函数都改成返回ResultAsync，核心差异和收益主要体现在下面几个点：

• 类型安全的错误签名：Promise的泛型只定义了resolve的类型，reject的错误是完全无类型的，Typescript不会做任何校验。你调用返回Promise的函数时，永远无法从类型层面知道它可能抛出什么错误，catch块拿到的error默认是unknown类型，每次都要手动做类型收窄，漏判断的话很容易出运行时问题。而ResultAsync会把成功类型和错误类型都明确定义在返回签名里，调用方可以直接获得所有可能的错误类型提示，类型系统会强制你做对应处理，完全不需要手动做类型校验。
• 全链路错误处理语义统一：你已经把所有同步函数改成了Result形式，如果异步函数还是用try/catch处理，代码里就会同时存在两种错误处理范式，一会要处理Result的ok/err分支，一会要写try/catch块，心智负担更高，代码风格也不一致。全量使用Result/ResultAsync后，不管同步还是异步逻辑，错误处理都可以用统一的map、andThen、match等链式方法完成，代码可读性和可维护性都会高很多。
• 从类型层面强制错误处理：未捕获的Promise reject会直接抛出运行时错误，在Node环境下甚至会导致进程退出，而且这类问题只能在运行时发现，静态检查根本识别不出来。但ResultAsync是普通的返回值，你要拿到成功态的内容就必须处理错误分支，哪怕你想忽略错误也要显式写对应的处理逻辑，从静态类型层面就杜绝了漏处理错误的问题。
• 更灵活的错误组合能力：neverthrow提供了combine、combineWithAllErrors等内置方法，可以非常方便的组合多个同步/异步Result结果，不管是要短路返回第一个错误，还是要收集所有错误再统一处理，都只需要调用简单的API即可，不需要自己写大量的判断逻辑，也不用嵌套多层try/catch块。

两种写法的简单对比 #

// 普通异步函数写法，错误类型完全不透明
async function fetchUser(id: number): Promise<User> {
  const res = await fetch(`/api/user/${id}`)
  if (!res.ok) throw new HttpError(res.status)
  return res.json()
}

// 调用时需要手动处理unknown类型的错误
try {
  const user = await fetchUser(1)
} catch (e) {
  // 你需要自己记住fetchUser可能抛出HttpError，还有fetch自带的TypeError
  if (e instanceof HttpError) {
    // 处理请求错误
  } else if (e instanceof TypeError) {
    // 处理网络错误
  } else {
    // 处理其他未知错误
  }
}

// ResultAsync写法，错误类型显式定义在返回值中
function fetchUser(id: number): ResultAsync<User, HttpError | TypeError> {
  return ResultAsync.fromPromise(
    fetch(`/api/user/${id}`),
    e => e as TypeError
  ).andThen(res => res.ok ? okAsync(res.json()) : errAsync(new HttpError(res.status)))
}

// 调用时自动获得错误类型提示，无需手动收窄
const userRes = await fetchUser(1)
userRes.match(
  user => console.log(user),
  err => {
    // 这里err的类型已经被推导为HttpError | TypeError，不需要额外的实例判断即可获得类型提示
    if (err instanceof HttpError) {
      // 处理请求错误
    } else {
      // 处理网络错误
    }
  }
)

当然也不要求你必须把所有异步函数都做改造，如果是仅在局部使用的简单工具函数，你能保证错误处理没有遗漏的话也可以保持原有写法，但在大型项目的核心业务逻辑里，全量使用ResultAsync带来的类型安全和可维护性收益，远高于你做一层包装的开发成本。

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