在 Haskell 日常开发中，记录类型的数据组装属于高频操作。无论是构建 HTTP 响应、解析 JSON 对象，还是聚合外部服务的查询结果，开发者都面临一个看似简单却影响深远的决策：使用 do notation 还是 Applicative 风格来完成记录字段的组装。这个问题不仅是语法偏好之争，更涉及代码可读性、执行效率、错误报告机制以及后续维护成本等多个工程维度。
do notation 的适用场景与特征
do notation 本质上是 Monad 的语法糖，它将一系列绑定操作按顺序执行，这种顺序性恰好契合了某些真实世界的业务逻辑。当记录字段之间存在明确的依赖关系时，do notation 能够将这种依赖以最直观的方式呈现出来。例如，从数据库查询用户信息后再根据用户 ID 查询其订单列表，最后将两者组装成完整的用户档案 —— 这种场景下字段之间存在先后顺序，使用 do notation 可以让读者一眼看清数据的流动方向。
从编译器实现角度来看，do notation 会被 desugar 为链式的>>=操作。GHC 在这一过程中会进行严格的类型检查，确保每个绑定表达式的类型与后续使用场景匹配。这种静态检查为代码提供了相当程度的保障 —— 如果在字段组装过程中出现了类型不匹配，编译器会在编译期报错，而非等到运行时才暴露问题。对于大型代码库而言，这种 early failure 特性有助于缩短调试周期。
do notation 还天然支持在绑定过程中引入局部计算逻辑。当某些字段需要经过中间转换才能填入记录时，可以在 do 块内部直接完成这些操作，而无需额外定义辅助函数。如下面的例子所示，字段的获取、清洗、转换可以集中在一个代码块内完成，代码的阅读顺序与执行顺序保持一致，这对于需要频繁修改业务逻辑的项目尤为重要。
Applicative 风格的优势维度
与 do notation 的顺序执行模型不同，Applicative 风格强调操作的并行性与组合性。使用<$>和<*>等运算符时，每个字段的获取操作在理论上可以独立进行，这为运行时优化提供了空间。虽然在单线程环境下这种并行性不会直接转化为性能收益，但它在错误处理层面具有重要意义 —— 当使用 Applicative 组装记录时，所有字段的计算都会尝试执行，收集到的错误信息比 do notation 的短路行为更为丰富。
从类型系统的角度审视，Applicative 的约束比 Monad 更宽松。任何 Applicative 都是 Functor，但并非所有 Monad 都能退化为 Applicative。这意味着使用 Applicative 风格编写的代码在类型推导上通常更加友好，IDE 的类型提示也更加稳定。对于需要与第三方库交互的场景，这种类型稳定性可以减少因类型签名变化而导致的连锁修改。
另一个不可忽视的优势是代码的简洁性。当字段之间确实相互独立时，Applicative 写法可以将原本数行的 do 块压缩为单行表达式的形式。这种紧凑性在某些场景下能够提升代码的可扫描性，尤其是当记录字段数量较多且结构相对扁平时。以常见的 HTTP 响应构建为例，使用 Applicative 可以在一行内完成所有字段的组装，视觉上更加清爽。
工程实践中的权衡参数
在实际项目中选择两种风格时，建议围绕以下几个维度进行评估。第一个维度是字段依赖关系图谱：如果超过半数的字段需要依赖前序字段的计算结果，则优先考虑 do notation；反之如果字段之间基本正交，Applicative 风格更具优势。第二个维度是团队技术栈成熟度：对于新加入 Haskell 项目的开发者，do notation 通常更容易理解，因为它更接近命令式编程的心智模型；而 Applicative 风格需要一定的函数式编程基础才能熟练运用。
错误处理需求也是重要的考量因素。当业务要求收集所有字段验证错误而非遇到首个错误就终止时，Applicative 的求值特性能够更好地满足这一需求。此时可以在每个字段的获取函数中返回 Either 或 Validation 类型，使用<*>组合时自动累积所有错误信息。相反，如果业务逻辑要求快速失败，则 do notation 配合 Monad 的错误处理机制更为自然。
代码可维护性参数同样值得关注。随着记录类型字段数量的增加，do 块的行数会相应膨胀。当单个 do 块超过十五行或嵌套超过两层时，建议评估是否需要拆分为多个辅助函数，或者考虑切换到 Applicative 风格以降低单个函数的复杂度阈值。GHC 的 ApplicativeDo 扩展提供了自动将 do notation 转换为更高效的 Applicative 组合的能力，在保持代码可读性的同时获得一定的性能优化。
落地建议与实践清单
针对不同场景给出以下具体建议。场景一：构建 HTTP 响应或 API 返回值时，如果涉及字段的顺序验证或多步计算，使用 do notation 并在其中嵌入 Validation 逻辑；如果是简单的字段透传，优先选用 Applicative 风格以保持代码简洁。场景二：编写 FromJSON 实例时，do notation 能够清晰展示每个字段的解析过程，便于调试和添加自定义解析逻辑； Applicative 风格则适合字段之间无依赖的标准 JSON 结构。场景三：数据库记录到领域模型的转换场景，通常字段之间存在依赖关系，使用 do notation 可以更好地表达这种依赖链。
在工具链层面，建议启用 GHC 的 ApplicativeDo 扩展（:set -XApplicativeDo），它能够在保留 do notation 写法的同时自动探索字段之间的并行机会。同时，配合 RecordWildCards 扩展可以在 do 块内部直接使用记录字段名称，减少视觉噪音。这些语言特性的组合能够在大多数场景下兼顾可读性与性能。
综合来看，两种风格并非互斥关系，而是针对不同场景的工具。成熟的 Haskell 开发者应该熟练掌握两种写法，根据具体场景的约束条件做出合理选择，而非固守单一风格。理解 do notation 与 Applicative 背后的类型类层级关系，以及它们在编译器层面的 desugaring 机制，是做出明智决策的理论基础。
资料来源：Haskell 社区关于 do notation 与 Applicative 记录的讨论（Reddit r/haskell、 Haskell Discourse）以及 GHC 关于 ApplicativeDo 的官方文档。