函数式设计模式（FP 与类型驱动设计）

• compose 与 pipe 的组合
• 纯函数与无副作用
• 数据流

• 纯函数：无副作用（不修改外部状态、不依赖可变外部、相同输入相同输出），是函数式数据流的基础。
• 组合（compose）：compose(f, g)(x) = f(g(x))，从右到左，把多个函数组合成一个函数，函数输出作为下一个函数输入。
• 管道（pipe）：pipe(f, g)(x) = g(f(x))，从左到右，f 的输出流入 g，数据像在管道中流动。
• 无副作用数据流：因为每个函数是纯函数，数据沿 compose/pipe 流动时，每个环节只做转换、不修改外部状态，输入输出清晰，可预测、可测试。数据流整条链由纯函数组成，无副作用。
• 应用：函数式编程中常用 compose/pipe 组合数据处理链（如集合处理、请求处理管线），实现"声明式数据流"。

compose/pipe 把纯函数组合成数据流，每个函数无副作用、输入输出清晰，数据沿链流动。纯函数保证无副作用，组合实现复用与声明式。

• 快速失败原则
• 吞错/默认值的危害
• 错误及早暴露

• 快速失败（fail-fast）：在出现错误时立即抛出异常/失败，而不是继续执行或返回含混结果，让错误尽早暴露。
• 为什么优于吞掉错误/返回默认值：① 吞掉错误（catch 后忽略）会让错误隐蔽，后续逻辑基于错误数据继续，产生难以定位的深层 bug；② 返回含混默认值（如返回 0/null/空）掩盖了失败，调用方无法区分"正常结果"与"失败结果"，错误被延迟；③ 快速失败让错误在发生处立即暴露，栈信息清晰、定位快，符合"错误尽早暴露"。
• 快速失败的价值：让问题显性化、可追踪，避免"错误被掩盖、扩散、最终爆炸"。配合 Result/异常类型，让错误显式传播，而不是静默吞掉。
• 结论：快速失败在错误发生时立即暴露，让错误可见、可定位；吞错/默认值掩盖错误，延迟故障，产生难排查的深层 bug。

快速失败让错误在发生处立即暴露，清晰可定位；吞错/默认值掩盖错误，延迟故障、难以排查。优先快速失败，让错误显式传播。

• 不可变数据的共享安全
• 持久化结构（结构共享）
• 并发安全

• 不可变数据：创建后不可修改，更新产生新版本。多线程可安全共享同一不可变实例，无共享可变状态，天然无竞态。
• 持久化数据结构（Persistent Data Structure）：更新时保留旧版本，通过结构共享（新版本复用旧版本不变的部分）实现高效更新，避免整体拷贝。典型如持久化 List/Map、immutable.js、Haskell 数据结构。
• 并发安全：不可变 + 持久化结构让并发访问安全——读线程可安全共享不可变数据，写线程创建新版本（不破坏旧版本），无需加锁。结构共享让更新高效（O(log n) 或 O(1) 摊还）。
• 价值：并发时无需锁、可共享、可回滚（保留历史版本），适合函数式/并发场景。
• 结论：不可变数据结构天然线程安全（无共享可变状态），持久化结构用结构共享高效更新，并发访问无需锁、可安全共享。

不可变数据无共享可变状态，天然并发安全；持久化结构用结构共享高效更新（保留旧版本）。并发下可共享、无需锁、可回滚。

• 小函数（单一职责）
• 纯函数（无副作用）
• 利于测试与并行

• 小而纯：函数式偏好把逻辑拆成小函数（单一职责），每个函数是纯函数（无副作用、相同输入输出）。
• 利于测试：纯函数无外部依赖、无副作用，输入输出确定，可独立单元测试（传参断言结果），无需 mock 外部依赖，测试简单、稳定、可组合。
• 利于并行：纯函数无共享可变状态，调用不相互干扰，可安全并行/并发执行（map/reduce 并行化），无需加锁，天然适合并行计算。
• 组合：小纯函数可组合成大逻辑，复用性与可读性高。
• 结论：小且纯的函数无副作用、输入输出确定，测试简单可靠、并行安全高效，是函数式编程的核心优势。

小而纯的函数无副作用、确定性强，测试无需 mock、并行无需锁，可组合复用。这是函数式偏好小纯函数的根本原因。

• enum 表达有限状态
• 类型约束非法状态
• 状态迁移

• 用 enum 表达状态：把状态定义为 enum（如 OrderState { PENDING, PAID, SHIPPED, DONE }），状态类型是有限的、编译期已知的，非法状态（不在枚举中）无法被构造——编译器保证状态只能是枚举中的值。
• 无法被构造：使用 enum 后，状态变量只能是 enum 定义的合法状态，无法用任意字符串/整数表示非法状态，从类型上排除非法状态。
• 状态迁移：配合状态机逻辑（如 transition(OrderState) 校验合法迁移），结合 enum 表达状态，非法迁移在编译期/运行时被拒绝。
• 类型驱动：enum 用类型系统表达"合法状态集合"，让非法状态无法被构造，是类型驱动设计（make illegal states unrepresentable）的体现。
• 结论：enum 用类型表达有限状态集合，非法状态无法被构造，类型系统保证状态合法性，配合状态机实现安全迁移。

enum 把状态建模为有限类型集合，编译器保证状态只能是合法值，非法状态无法被构造。是"make illegal states unrepresentable"的典型。

• 类型驱动设计（make illegal states unrepresentable）
• 用类型约束状态
• 编译器证明

• 类型驱动设计：用类型系统建模领域，让非法状态在类型层面不可表示（make illegal states unrepresentable），编译器在编译期拒绝非法状态。
• 方法：① 用枚举/代数数据类型（ADT/sum type）表达有限可选状态，避免任意值；② 用不同类型区分不同状态（如 DraftOrder vs SubmittedOrder，类型不同，不能混用）；③ 用非空类型/Option 表达可选性，避免 null；④ 用 newtype 区分语义（如金额 vs 数量）。
• 编译器证明：一旦类型设计正确，非法状态（如"未验证的邮箱"、"负数金额"）根本无法构造出对应类型，编译器在编译期（静态检查）就拒绝，无需运行时校验。类型系统即"证明"。
• 收益：大幅减少运行时错误，代码在编译期自证正确性，重构更安全。
• 结论：类型驱动设计用类型建模领域，让非法状态无法表示，编译器在编译期证明并拒绝，减少运行时错误。

类型驱动设计用 ADT/区分类型/非空类型建模，让非法状态类型上不可表示，编译器编译期拒绝。类型系统是正确性的证明工具。

• parse-don't-validate 思想
• 三段式流程
• 类型保证已校验

• parse-don't-validate：与其"先校验后到处传原始数据（每次用再校验）"，不如在入口处解析，把原始输入转换成"已校验的强类型"，此后类型保证数据合法，无需再校验。
• 三段式：① 解析（parse）：把原始输入（字符串/请求）解析为强类型结构；② 校验（validate）：在解析过程中校验规则（如邮箱格式、范围）；③ 构造（construct）：校验通过则构造"已校验类型"（如 Email vs String），构造失败返回错误。
• 为什么更稳健：① 校验只做一次（入口），此后类型保证合法，避免"到处校验、漏校验"；② 用类型区分"未校验"与"已校验"（如 Email 类型），非法数据无法构造出 Email 类型，编译器保证；③ 错误在入口集中处理，管线清晰。
• 结论：parse-don't-validate 在入口解析校验并构造强类型，此后类型保证合法，减少重复校验与漏校验，更稳健。

parse-don't-validate 在入口把原始数据解析校验为强类型，此后类型保证合法，避免重复校验与漏校验。类型区分"已校验"状态，更稳健。

• 惰性求值
• 迭代器链式操作
• 零成本抽象

• 惰性求值（Lazy Evaluation）：操作不立即执行，而是延迟到真正需要结果时才执行。迭代器风格的链式操作（map/filter）是惰性的——调用链只是构建操作"流水线"，终端操作（如 collect/forEach）才触发实际遍历。
• 迭代器链式操作：stream.map(...).filter(...).reduce(...) 构建一条惰性流水线，元素一次流过每个操作，避免创建中间集合（不产生中间 list）。
• 零成本抽象：惰性求值 + 链式操作避免中间结果分配，且每个元素只处理一次（单次遍历），性能接近手写循环；配合内联/优化，抽象（链式、声明式）几乎无额外开销——"零成本抽象"。
• 收益：代码声明式、可读，同时性能接近手写循环（无中间集合、单次遍历）。
• 结论：迭代器惰性求值把链式操作构建成惰性流水线，终端操作触发执行，避免中间集合、单次遍历，实现声明式且接近零成本的高阶操作。

惰性求值让链式操作延迟到终端触发，避免中间集合、单次遍历，性能接近手写循环，实现零成本抽象的声明式高阶操作。

• Either/Result 类型
• 显式失败
• 与异常对比

• Either/Result 类型：Either<L, R> 或 Result<T, E> 表示"成功值（R/T）或失败（L/E）"，是值，不是异常。失败作为返回值的一部分，用类型系统表达。
• 表达失败：函数返回 Result<T, E>，成功返回 Ok(value)，失败返回 Err(error)。调用方必须处理两种情况（匹配/解包），失败是显式的，类型上强制处理。
• 与异常对比：异常是"控制流跳转"，异常可能被忽略/吞掉，调用方不必须处理；Result 是"返回值"，类型系统强制调用方处理失败分支，失败显式、可组合（map/flatMap 链式传播错误）。
• 应用：Rust 的 Result<T,E>、Java 的 Either/Validation、函数式语言。配合 ? 操作符（Rust）显式传播错误。
• 结论：Either/Result 用类型表达失败，失败作为返回值显式、类型强制处理，比异常更可追踪、可组合。

Result/Either 把失败建模为返回值，类型系统强制处理失败分支，失败显式、可组合；异常是隐式控制流，可能被忽略。Result 更可追踪。

• Option/Maybe 类型
• 消除 null 歧义
• 强制处理缺失

• Option/Maybe：Option<T> 表示"可能不存在"的值，Some(value) 表示有值，None 表示无值。是类型，不是 null。
• 消除 null 歧义：null 无法区分"值缺失"与"值为空/无意义"，且 null 可以出现在任何地方，导致 NPE 与歧义。Option 用类型明确表达"可能缺失"，缺失（None）是显式的、类型可见的。
• 强制处理：用 Option 后，调用方必须处理 Some/None 两种情况（匹配/解包），缺失被显式处理，避免 NPE。map/flatMap/orElse 链式处理缺失。
• 收益：Option 让"缺失"成为类型的一部分，编译器/调用方强制处理，消除 NPE 与 null 歧义；Optional（Java）、Option（Scala/Rust）都是实现。
• 结论：Option 用类型表达"可能缺失"，缺失显式、强制处理，消除 null 的歧义与 NPE。

Option 把"可能缺失"建模为类型，Some/None 显式，调用方强制处理，消除 null 歧义与 NPE。用 map/flatMap/orElse 链式处理。

• 代数效应
• 副作用与逻辑分离
• 可组合/可替换处理器

• 代数效应（algebraic effects）：一种语言特性，把"执行副作用"与"业务逻辑"分离——逻辑中声明"我要执行某种效果"（effect），具体如何执行由外部的**效果处理器（handler）**提供。
• 分离：逻辑只描述"需要什么效果"（如 fetch、log、ask），不关心实现；副作用实现（具体 IO、日志、依赖）由 handler 注入。逻辑是纯的、可测试的，副作用在处理层。
• 可组合/可替换：handler 可替换（测试用 mock handler，生产用真实 handler），效果可组合（多个 handler 叠加）。逻辑不依赖具体 IO，便于测试与复用。
• 应用：Kotlin 的 coroutines、Eff、某些 FP 语言。类似"依赖注入/类型class"的副作用抽象。
• 结论：代数效应让逻辑声明"需要什么效果"，handler 提供副作用实现，副作用与逻辑分离，逻辑可测试、handler 可替换。

代数效应把"声明效果"与"执行效果"分离：逻辑只声明，handler 实现副作用。逻辑纯、可测试，handler 可替换、可组合。

• ADT（product + sum type）
• sum type 表达互斥状态
• 精确建模与穷尽匹配

• 代数数据类型（ADT）：由 product type（积类型，如 struct/类，同时包含多个字段）与 sum type（和类型，如 enum/union，互斥的多选一）组成。
• sum type 建模状态：sum type 表达"互斥的多种可能"——如 OrderState = Pending | Paid | Shipped，状态是这些枚举值之一，精确建模"状态"这一互斥概念。
• 精确建模：sum type 让状态的每个case 是类型的一部分，可携带不同数据（如 Paid(amount)），精确表达"不同状态有不同数据"；配合穷尽匹配（exhaustive match），编译器要求处理所有 case，保证不遗漏状态。
• 应用：Rust 的 enum、Haskell 的 data、Scala 的 sealed trait。用于建模状态机、错误类型、表达式树。
• 结论：ADT 的 sum type 用互斥枚举精确建模状态，每个 case 可携带数据，穷尽匹配保证所有状态被处理。

sum type 用互斥枚举表达"多选一"的状态，精确建模状态机；穷尽匹配强制处理所有 case。ADT 让状态在类型层面精确、完整。

• Functor 的 map
• Monad 的 flatMap
• 抽象与组合

• 函子（Functor）：有 map 操作的类型类——map(f) 把函数 f 应用到容器/上下文内的值，保持上下文（如 List.map、Option.map、Future.map）。本质是"在上下文中应用纯函数"。
• 单子（Monad）：有 flatMap（bind）操作的类型类——flatMap(f) 把返回"新上下文"的函数 f 应用到上下文内的值，并把结果扁平化（避免嵌套上下文）。本质是"在上下文中组合返回上下文的操作"。
• map 与 flatMap 区别：map 的函数返回普通值（A -> B），flatMap 的函数返回上下文值（A -> M[B]）。flatMap 用于顺序组合依赖上下文的操作（如依次处理可能失败/异步的步骤）。
• 抽象：Functor/Monad 抽象了"上下文中的计算"，让组合（map/flatMap 链）可复用，用于处理可选、错误、异步、副作用等。
• 结论：Functor 的 map 在上下文中应用纯函数，Monad 的 flatMap 组合返回上下文的操作并扁平化，二者抽象"上下文中的计算"。

map 应用普通函数，flatMap 组合返回上下文的函数并扁平化。Functor/Monad 抽象上下文中的计算，用于可选/错误/异步等组合。

• Strategy 模式 vs 高阶函数
• 函数作为参数
• 等价替代

• 命令式 Strategy 模式：定义策略接口 + 多个策略实现类，通过对象注入替换算法，消除 if-else。
• 函数式等价：策略即"函数"，用高阶函数（接收函数作参数）直接替代策略对象——pay(Function<Order,Result> strategy) 或把策略作为函数传入，无需定义策略类与接口。
• 等价：Strategy 的"算法可替换"在函数式中就是"函数可作参数"，List.parallelStream().map(fn) 之类。函数式语言中策略就是函数，可以定义、传递、组合。
• 应用：策略（算法）、模板方法（回调）、命令（函数/闭包）等命令式模式在函数式中常被高阶函数/闭包等价替代，更简洁。
• 结论：Strategy 等命令式模式在函数式中等价于高阶函数（函数作参数），用函数替换策略对象，更简洁、可组合。

Strategy 的"算法可替换"在函数式就是"函数作参数"（高阶函数），无需策略类/接口。命令式模式常被高阶函数/闭包等价替代。

• 动态语言的类型约束不足
• 轻量类型驱动做法
• 运行时校验

• 动态语言（Python/JS）缺静态类型，类型驱动需靠约定与运行时校验的轻量做法。
• 轻量做法：① 命名与文档：用清晰命名/类型标注（Python 类型注解、JSDoc）表达意图；② 运行时校验：在入口处校验（如 schema 校验、dataclass/Pydantic 验证），把非法数据尽早拒绝；③ 用类/枚举建模状态：用 enum/类封装状态与属性，避免裸字符串/字典；④ 工厂/构造函数校验：在构造时校验不变式，避免非法状态；⑤ 测试：用测试约束行为，弥补类型不足。
• 借助类型标注与工具：typing、Pydantic、mypy（Python）、TypeScript（带类型）提供静态检查，借鉴类型驱动的"非法状态不可表示"。
• 结论：动态语言借类型驱动用"命名/类型标注 + 入口运行时校验 + 枚举/类建模 + 测试"等轻量做法，弥补静态类型不足。

动态语言无静态类型，用类型标注、入口运行时校验、枚举/类建模状态、测试等轻量做法借鉴类型驱动思想，尽早拒绝非法数据。

• newtype 定义新类型
• 防止单位/语义混淆
• 类型安全

• newtype：基于已有类型定义新类型（如 struct Meters(f64)、type UserId = Int），让同一底层类型的不同语义在类型上区分。
• 防止单位/语义混淆：Meters 与 Seconds 都是 f64，但用 newtype 定义为不同类型后，编译器禁止把 Meters 传给需要 Seconds 的函数（类型不匹配），避免单位混淆（米/秒）、语义混淆（金额/数量、ID 类型）。
• 类型安全：newtype 让"不同语义"在类型层面区分，编译器在编译期防止混淆，错误提前暴露。如 UserId 与 OrderId 都是 Int，newtype 区分，避免传错。
• 应用：Rust 的 newtype、Haskell 的 newtype、Scala 的 value class。配合类型别名（type alias）区分。
• 结论：newtype 用新类型区分同底层类型的不同语义，编译器禁止类型混淆，防止单位/语义混淆，提升类型安全。

newtype 把同底层类型的不同语义定义为不同类型，编译器禁止混用，防止单位/语义混淆。是类型驱动中防混淆的轻量手段。

• Option/Result 的类型强制
• 无法忽略错误
• 穷尽处理

• Option/Result：把"可能缺失/失败"建模为类型，调用方必须处理（解包/匹配）才能拿到值，无法忽略错误分支。
• 无法忽略：函数返回 Result<T,E>，调用方要得到 T 必须处理 Err（解包、匹配、? 传播），编译器/类型系统强制"处理了错误分支才能继续"，否则无法提取值。错误分支无法被静默忽略。
• 穷尽处理：配合模式匹配，编译器要求穷尽处理 Ok 与 Err（或 Some/None）两种情况，遗漏会编译报错。
• 对比：异常/返回 null 可被忽略（不处理也能编译），Option/Result 在类型层面强制处理，让错误显式、不可忽略。
• 结论：Option/Result 用类型系统强制调用方处理缺失/失败分支，穷尽处理保证错误分支无法被忽略。

Option/Result 把失败建模为类型，调用方必须解包/匹配才能得到值，穷尽处理强制覆盖错误分支，错误无法被静默忽略。