fp-ts 实用错误处理

问题从哪来

在 TypeScript 里，try/catch 让失败路径从类型里「消失」：调用方不知道函数会抛什么，嵌套捕获又容易变成意大利面。表单校验、多步 API、批量处理时，你往往还要收集全部错误，而不是碰到第一个就停——这和「抛一次、捕一次」的模型天然不对盘。

技能在教什么

核心约定很简单：错误只是数据。用 fp-ts 的 Either（同步）和 TaskEither（异步）把失败显式放进返回值，让编译器能追踪 Left / Right。

• Either 基础：E.left / E.right 表示失败与成功；E.tryCatch 把会抛异常的代码包成 Either；E.fromNullable 把可空值转成带错误的分支。
• 链式组合：用 pipe + E.chain 串起可能失败的多步；错误类型不一致时用 E.chainW；第一个 Left 会截断后续步骤，控制流比嵌套 try/catch 清晰。
• 累积校验：表单等场景用 applicative（如 sequenceS(validation)）一次收集字段级错误，而不是只返回第一个。
• 异步与边界：TaskEither 对应「惰性执行的 Promise<Either>」；在系统边界用 TE.tryCatch、TE.fromTask 等把 Promise/抛异常代码收进来，需要对接外部 API 时再用 fold 或转回 Promise 作为逃生舱。

文档里还给了用户输入解析、带完整错误的 HTTP 调用、列表项部分失败、批量部分成功等真实场景示例，以及 Either / TaskEither 的快速对照表。

适用边界

• 适合愿意引入 fp-ts 与函数式组合（pipe、chain）的团队；若项目完全拒绝这类依赖，价值主要在模式理解而非即插即用。
• Either 管同步失败路径；真正 I/O 应走 TaskEither，别混用概念。
• 遗留代码里大量 throw 和裸 Promise 时，需要在模块边界做转换，而不是指望一次重写全库。