1.3 适用边界与代价：什么时候别用函数式

1.3 适用边界与代价：什么时候别用函数式

本节摘要：任何范式推广的失败，多数不是"技术不好"，而是"边界不清"。本节给出一份诚实的场景适用矩阵：函数式在哪些领域是主力架构、哪些领域是局部调味、哪些领域是负资产；同时把代价摆上台面——抽象税、性能账单、学习曲线、生态成熟度。读完本节，你应当能为自己的项目画出函数式的引入边界，而不是拿着锤子看什么都像钉子。

一个真实项目的踩坑开场

某团队读完一本函数式教材后热血上头，把一个高吞吐行情推送服务从 Java 重写成了"纯函数式架构"：所有消息处理函数化、所有状态不可变、所有变更走事件溯源。三个月后上线，延迟毛刺比旧版高了一截，团队里能维护这套代码的人从八个变成三个。问题出在架构选错了吗？只对了一半——消息处理核心确实受益于纯函数化，但热路径上每一帧都分配新对象的不可变纪律，把 GC 压力推到了临界点，而团队没有预算做性能调优。教训不是"函数式不行"，而是"没算代价就全面铺开不行"。本节就是那份没来得及算的代价清单。

一、场景适用矩阵：三个梯队

把常见后端与前端场景按函数式的适配度分三个梯队。第一梯队，函数式是主力架构：数据处理管道（ETL、流式计算）、规则引擎与风控决策、编译器与解释器、配置管理与领域建模、并发服务器的业务逻辑层。这些场景的共同点是"输入到输出的映射关系清晰、状态演化可以用事件序列表达"。第二梯队，函数式是局部调味：Web 业务的 Controller 与 Service 层（用不可变模型与纯函数组织逻辑，IO 留在边缘）、前端 UI 层（React 的本质就是 UI 等于状态函数）。第三梯队，函数式纪律慎重或部分放弃：游戏引擎的每帧热循环、高频交易的超低延迟路径、驱动与嵌入式近裸机代码。不是不能写，而是"每帧零分配"这类硬约束会与不可变纪律正面冲突，需要专门技术（对象池、mutation 局部化）才能调和。

图：函数式场景适用矩阵

二、代价清单：四笔账要提前算

第一笔，抽象税。 函数式代码的抽象层次更高，读代码的人需要持有更多"间接层"在脑子里。一个判断团队承受力的土办法：拿一段用了函子变换的真实业务代码给团队讲十分钟，一周后回访，能独立写出同风格代码的比例过半，抽象税就可承受；过低就先从"不可变数据加纯函数"这种无门槛子集开始。

第二笔，性能账单。 不可变意味着分配与拷贝，惰性意味着间接与内存驻留（第 2 章的空间泄漏案例就是典型）。这些不是不可解——持久化数据结构的结构共享、编译器的严格性分析、按需 strictness 标注都是解法——但每个解法都需要有人懂。预算里没有"性能调优"这个科目，就别在热路径上赌。

第三笔，学习曲线。 函数式的门槛不在语法在转换：把"如何做"翻译成"是什么"的转换思维，多数工程师需要四到八周的刻意练习才顺。招聘市场供给也确实少于主流栈，团队连续性要有预案。

第四笔，生态成熟度。 具体到集成：冷门函数式语言的某个数据库驱动、某个监控探针，可能只有社区维护，升级断档无人接盘。选型时把"所有依赖的维护活跃度"列成表过一遍，比看语言基准测试更接近真相。

三、两个真实的错配案例

案例一：报表系统的过度函数化。某 BI 团队把所有 SQL 拼接逻辑改成 Monad 组合风格，代码行数减了四成，但团队里两位资深 DBA 从此看不懂查询构造过程，调优建议只能靠猜。复盘结论：查询构造的本质是"描述性声明"，SQL 本身已经是函数式表达，再包一层抽象是给翻译加翻译。改成"SQL 模板加纯函数参数化"就停手了。

案例二：该用而没用的遗憾。一个营销规则引擎，需求是"运营可自由组合几十个投放条件"。团队最初用继承树加策略模式实现，每加一个条件要动五个类；半年后用函数式重写为"谓词函数加组合子"：条件就是一个个返回布尔的纯函数，and、or、not 是三个组合子，运营后台把条件配置翻译成函数组合树。新增条件从"改框架"变成"加一个函数"，测试从"搭环境"变成"喂参数"。这两个案例放在一起，恰好说明函数式不是面积问题，是形状问题——映射关系清晰的模块，用；状态机复杂的模块，慎。

四、决策流程：一张自查表

给选型者一个可操作的决策顺序。第一步，问模块的核心复杂度是"转换"还是"协作"：转换类（解析、计算、过滤、聚合）倾向函数式；协作类（多对象状态互动、生命周期管理）倾向保持对象风格。第二步，问性能预算有没有调优余量：没有，就限制在非热路径。第三步，问团队能否付出四周的练习期：不能，从不可变数据这一个习惯开始渗透。第四步，问依赖生态的维护密度：关键依赖单人维护的，一票否决。四步走完，引入面积自然浮出来——通常是"核心域全量函数式，外围保持现状"，这正是第 2.1 节副作用分层架构的雏形。

五、快速问答：边界判断的常见追问

问：老项目能不能只做"半套"函数式——用不可变数据但保留大量循环？可以，而且这是最常见的落地形态。四件套（见第 5.3 节）相互独立，不可变数据一项的收益（别名事故归零）就已经值回票价，循环不必强改。半套的真正风险只有一个：团队把"半套"当"全套"，在评审里用全套标准互相对立——所以半套也要写进约定（第 7.4 节）。

问：业务逻辑天然是状态机（如审批流、订单状态机），是不是就和函数式无缘？不是无缘，是换部件。状态机领域更适合"事件溯源"的函数式形态：状态不是被修改的对象，而是事件序列折叠出的结果（第 3.3 节的 fold 视角）。审批流的每次流转是一条不可变事件，当前状态由折叠事件序列得出——这个建模天然带审计能力，比就地修改状态字段的表达力更强。

问：团队只有两三个人，值得立这些边界吗？值得，但可以简化到一条：新代码的规则层必须纯。小团队没有评审战争，约定的作用是给未来的自己留备忘——三人的团队一年后可能是八人，边界的缺位在小团队阶段欠下的债，会在扩张时连本带息偿还。

问：怎么向管理层证明这笔投入的回报？用第 7 章的可测数字说话：测试耗时与用例数的对比、线上问题平均处置时长的对比、变更引入缺陷率的对比。范式辩论赢不了汇报，工程指标可以。

本节要点回顾

• 范式匹配形状而非面积：转换关系清晰的模块优先函数式，状态协作复杂的模块保持原范式。
• 四笔代价账：抽象税、性能账单、学习曲线、生态成熟度，任何一笔没预算就缩小引入面积。
• 梯队判断法：数据处理、规则引擎、编译器是主力区；游戏热循环、超低延迟路径要慎重。
• 反面案例同样重要：SQL 之上再包一层函数式抽象是过度设计；规则引擎的谓词组合则是教科书级契合。
• 渐进引入是常态：从不可变数据加纯函数子集开始，比全面重写的成功率高一个量级。

边界划清了，下一章进入机器内部：同一段"纯"代码，严格求值与惰性求值会走出完全不同的执行节拍，而副作用是如何被语言识别、圈禁、管制的——那是函数式编译器最核心的一套魔法。