5.3 搬进主流语言：Java、JavaScript、Python 的移植四件套

5.3 搬进主流语言：Java、JavaScript、Python 的移植四件套

本节摘要：绝大多数读者的战场不是 Haskell，而是存量 Java、JavaScript、Python 代码库。好消息是函数式思想可以拆成四个可独立移植的组件——不可变模型、纯函数核心、表达式风格、结果类型——每一件都能在主流语言找到落点，每一件的落地阻力都可预估。本节给出四件套的移植手法、三语言对照案例，以及一个按团队现状定深度的引入路线。

移植的总体策略：按组件拆，不按范式搬

"我们要函数式化"这种口号式目标注定失败，因为范式无法整体搬家，组件可以。四件套按收益与阻力排序：

组件            内容                          收益              阻力来源
──────────────────────────────────────────────────────────────────────
不可变模型      数据类只读、更新即构造新值     消灭别名事故       习惯与框架绑定
纯函数核心      业务规则无状态、IO外移         可测性暴涨         存量代码纠缠
表达式风格      用映射管道替代循环语句         意图显形           性能敏感路径
结果类型        用类型表达可能失败             异常变契约         异常体系惯性
​

四件相互独立：只做第一件也完全成立，做到哪件算哪件。下面逐件给出三语言的落点。

一、不可变模型：从 final 到 frozen 的梯度

三个语言的可用工具呈明显梯度。Python 用 frozen dataclass（构造后修改直接抛异常）；JavaScript 用 Object.freeze 加约定（浅冻结，嵌套要递归或用库）；Java 用 record（JDK 16 起内建）——record 是三家里最像"语言级不可变建模"的：

# Python：frozen dataclass —— 修改即异常
from dataclasses import dataclass, replace

@dataclass(frozen=True)
class Money:
    cents: int
    currency: str = "CNY"

    def add(self, other: "Money") -> "Money":
        assert other.currency == self.currency, "币种不一致"
        return replace(self, cents=self.cents + other.cents)  # 返回新值

m1 = Money(1000)
m2 = m1.add(Money(250))
print(m1.cents, m2.cents)   # 1000 1250 —— 旧值安然无恙
​

// Java：record —— 组件自动只读，天然值语义
public record Money(long cents, String currency) {
    public Money add(Money other) {
        if (!currency.equals(other.currency)) throw new IllegalArgumentException("币种不一致");
        return new Money(cents + other.cents, currency);
    }
}
// Money m2 = m1.add(new Money(250, "CNY"));  // m1 不可变
​

// JavaScript：freeze + 展开构造（约定浅层）
const money = (cents, currency = "CNY") => Object.freeze({ cents, currency });
const add = (a, b) => {
  if (a.currency !== b.currency) throw new Error("币种不一致");
  return money(a.cents + b.cents, a.currency);
};
​

移植要点两条：其一，集合字段是重灾区——record 与 frozen dataclass 都不冻内容，record Tags(List<String> tags) 里的列表照样可变；处理办法是构造时包一层不可变视图（List.copyOf、tuple）。其二，ORM 与序列化框架按"可变 JavaBean"设计时，不可变模型要配适配层——阻力预告里说的"框架绑定"就在这里。

二、纯函数核心：把规则从服务类里请出来

拿 Spring 风格的一段真实代码开刀。移植前：

@Service
public class FeeService {
    @Autowired private RateClient rateClient;   // 远程汇率

    public BigDecimal settle(BigDecimal amount, String level) {
        BigDecimal rate = rateClient.fetch(level);        // 逻辑与IO纠缠
        BigDecimal fee = amount.multiply(rate);
        if (fee.compareTo(new BigDecimal("0.5")) < 0) {   // 规则埋在IO之后
            fee = new BigDecimal("0.5");
        }
        return fee.setScale(2, RoundingMode.HALF_UP);
    }
}
​

移植手法与第 2.1、3.4 节同源——先提纯，再注边界：规则部分不碰任何客户端，汇率作为参数传入：

// 纯核心：无状态、无依赖注入、毫秒级可测
public final class FeeRules {
    private static final BigDecimal MIN_FEE = new BigDecimal("0.5");

    public static BigDecimal calc(BigDecimal amount, BigDecimal rate) {
        BigDecimal fee = amount.multiply(rate);
        if (fee.compareTo(MIN_FEE) < 0) fee = MIN_FEE;
        return fee.setScale(2, RoundingMode.HALF_UP);
    }
}

// 外壳：保留原接口，调用方零感知
public BigDecimal settle(BigDecimal amount, String level) {
    return FeeRules.calc(amount, rateClient.fetch(level));
}
​

收益立竿见影：费率规则的单测从"起容器、mock 客户端"变成一行静态调用，边界用例（恰等于最低费、汇率极端值）得以补齐。JavaScript 与 Python 同构：React 生态的"纯组件加 hooks 副作用"、Python 的"纯函数加薄路由"，都是同一架构母题的方言版。

三、表达式风格：管道化的度

三语言都有映射管道设施：Java Stream、JavaScript 数组方法、Python 生成器表达式。移植建议不是"消灭所有 for"，而是认意图——第 3.1 节的意图判别法直接可用：

# 语句版：意图要靠执行模拟
result = []
for o in orders:
    if o.status == "paid" and o.amount > 100:
        result.append({"id": o.id, "sum": o.amount * 1.0})

# 表达式版：筛选变换聚合一目了然
result = [
    {"id": o.id, "sum": o.amount}
    for o in orders
    if o.status == "paid" and o.amount > 100
]
​

度的把握：简单遍历保持 for（无变换无筛选，管道化是负收益）；两层以上嵌套循环、复合筛选聚合，优先管道化；性能热路径（每秒百万级的循环）先测再改——Python 的生成器链与 Java Stream 在热路径上的开销特征各不相同，第 6.3 节会专门算这本账。

四、结果类型：让异常变成签名的一部分

结果类型在主流语言的落地梯度最明显。Python 3.12 没有内建 Either，社区库（如 returns 模块的 Result）可用，或用自定义轻量版：

from dataclasses import dataclass
from typing import Union, Generic, TypeVar

E = TypeVar("E"); V = TypeVar("V")

@dataclass(frozen=True)
class Ok(Generic[V]):
    value: V
@dataclass(frozen=True)
class Err(Generic[E]):
    error: E

Result = Union[Ok[V], Err[E]]

def parse_amount(raw: str) -> Result[str, float]:
    try:
        v = float(raw)
        if v <= 0:
            return Err(error="金额必须为正")
        return Ok(value=v)
    except ValueError:
        return Err(error="金额格式非法")

match parse_amount("12.5"):
    case Ok(value=v): print("解析成功：", v)
    case Err(error=e): print("解析失败：", e)
​

Java 用 Optional 表达"可能缺失"（内建），"带原因失败"则用密封接口（sealed interface）加 record 模拟 Either；JavaScript 无类型层的 union，用 TypeScript 的可辨识联合补齐：

// TypeScript：可辨识联合 —— 编译期强迫处理两种结局
type Result<V, E> = { ok: true; value: V } | { ok: false; error: E };

function parseAmount(raw: string): Result<number, string> {
  const v = Number(raw);
  if (Number.isNaN(v) || v <= 0) return { ok: false, error: "金额非法" };
  return { ok: true, value: v };
}

const r = parseAmount("12.5");
if (r.ok) console.log(r.value); else console.log(r.error);
// 不写 else 分支？error 字段访问直接编译报错
​

移植阻力主要来自异常体系惯性：调用方习惯 try-catch，团队要约定"业务规则拒绝走结果类型、基础设施故障走异常"的边界，否则两套错误机制并行会把调用方逼疯。这个约定本身就是第 2.1 节副作用清单里"异常逃逸"的治理条款。

图：移植四件套的落地阻力与收益地图

五、引入路线：按团队现状定深度

三档路线收束本章。轻量档（两周可见效）：新代码强制不可变模型与纯函数规则层，存量不动；评审清单加两条"入参可变吗、规则可测吗"。中档（一季度）：核心域模块按第 3.4 节四步重构一到两个，团队获得一手经验；管道化与结果类型限定在新代码。重量档（半年以上）：引入 JVM 系函数式语言（Scala 或 Clojure）承载核心域，与 Java 主库互操作——这一档只有在轻中档跑通、团队尝到甜头之后才值得考虑。判断当前档位的一句话测试：团队评审时能不能自然说出"这个函数不纯"并达成共识——能，说明你已经在中档了。

💡 关键直觉：主流语言的函数式化，本质是用架构纪律补语言的短板。语言没给的（强制纯度、类型围栏），团队用约定、评审清单与模块边界补——补到什么程度算什么档位，不必追求补成 Haskell。

本节要点回顾

• 按组件移植不按范式搬家：四件套相互独立，做到哪件算哪件，口号式"全面函数式化"注定失败。
• 不可变模型有三档工具：Java record 最完备、Python frozen dataclass 次之、JS freeze 靠约定，集合字段都要额外设防。
• 纯函数核心零语言依赖：提纯加注边界的手法在任何语言立即生效，收益最高阻力最低。
• 管道化认意图不认语句：复合筛选聚合才值得管道化，简单遍历保持 for。
• 结果类型要与异常分工：业务拒绝走结果、基础设施故障走异常，边界写进团队约定。

思想的移植路线图交货了。下一章进入函数式最能兑现承诺的领域：并发——不可变数据如何让锁退居二线，四种并发模型如何在语言光谱上各据一方。