Mercury用200万行Haskell代码处理2480亿刀

一家成立7年的金融科技公司，用一门"学术味"极重的编程语言，处理了相当于瑞士年度GDP三分之一的资金流水。更离谱的是，他们的大部分工程师入职前从没写过这行代码。

2025年，Mercury（水星银行）的年化交易规模达到2480亿美元，服务超30万家企业客户，年收入6.5亿美元。支撑这一切的，是一套约200万行的Haskell（一种纯函数式编程语言）代码库。

这个数字本身足以让硅谷的Java信徒倒吸一口凉气。Haskell在业界的名声向来两极：学术圈奉为圭臬，工业界避之不及。Mercury的工程团队负责人却告诉我，这套系统经历过SVB危机期间50亿美元存款5天内涌入的冲击，也扛住了美国货币监理署（OCC）的银行牌照审查，"运转良好"不是客套话。

16岁少年的执念，20年后成了金融基础设施

故事要从一个高中计算机课堂说起。当时作者还在写Java，每周都被NullPointerException（空指针异常）折磨。某天在Reddit上看到一种"根本不可能出现空指针"的语言，"立刻、彻底地沦陷了"。

近20年后，他依然认为当年那个价值判断基本正确。但真正让他重新理解这门语言的，不是 purity（纯函数）的布道，而是"当代码库膨胀、公司增速超过文档更新速度、系统开始触碰真金白银时，那套承诺到底长什么样"。

Mercury的工程师招聘策略很有意思：招通才，入职后现学Haskell。1500名员工里，绝大多数的第一行Haskell是在公司写的。这与传统金融科技的Java/C#路线截然不同，也与硅谷新贵们偏爱的Python/Go栈南辕北辙。

Haskell的护城河藏在类型系统里。它允许你把运维知识封装进API，把危险操作锁进严格的边界，让"安全路径"成为"容易路径"。在快速扩张的公司，这不是审美偏好，而是"当最初理解系统的人离职后，如何让系统继续可被理解"的生存问题。

SVB危机的5天压力测试

2023年3月，硅谷银行（SVB）倒闭引发恐慌性挤兑。Mercury在5天内涌入20亿美元新存款——这相当于其当时管理资产规模的显著比例。作者轻描淡写地称之为"all the ordinary and extraordinary things"，但业内人都懂这种流量突增的杀伤力。

传统银行的核心系统多建于上世纪，用的是COBOL或早期Java，架构文档往往比工程师的工龄还老。Mercury的Haskell系统却在这波冲击中保持了稳定。类型系统的严格性在这里发挥了作用：资金流转的边界被编译器强制检查，许多在传统代码中只能靠人工review发现的错误，在构建阶段就被拦截。

更微妙的是知识传承问题。金融系统的核心风险之一是"部落知识"——关键逻辑只存在于某几位老员工的脑子里。Haskell的类型签名本身就是一种文档：函数能做什么、不能做什么、需要什么前提条件，都写在类型里，无法被忽略。

Mercury正在申请美国全国性银行牌照。OCC的审查流程以严苛著称，技术架构的可审计性是重点考察项。用一门小众语言构建核心系统，理论上会增加监管沟通成本，但作者暗示实际体验并非如此——类型系统的精确性反而让系统行为更容易被形式化验证和解释。

200万行的"恐怖故事"为何没翻车

函数式编程社区有个老梗：Haskell程序员的数量随代码行数增长而指数下降，超过10万行就会进入"无人区"。Mercury的200万行显然打破了这条虚构的定律。

他们的解法并不神秘。首先是模块边界的设计：把危险操作（如资金划转、账户状态变更）封装在受控的核心模块，外围业务逻辑通过类型安全的API调用。其次是工程文化的塑造：新工程师的Haskell培训被纳入标准入职流程，代码审查强制要求类型级别的思考。

一个反直觉的观察是，Haskell的学习曲线在团队规模扩大后反而变得平缓。小团队时期，个人英雄主义可以弥补语言特性和工程规范的缺失；但当1500人需要协作时，编译器的强制一致性成了比"约定俗成"更可靠的协调机制。

作者提到一个细节： elegance（优雅）是令人愉悦的，但 keeping your business alive（让生意活下去）是强制性的。这句话可以视为对整个Haskell工业应用的辩护词——不是为了炫技，而是为了在高压环境下减少认知负担。

Mercury的案例是否会引发跟风？短期内可能性不大。Haskell的生态系统（库、工具链、人才池）与Java或Python相比仍有明显差距，启动成本高昂。但对于已经处于技术债务深水区的金融科技公司，这个案例至少提供了一个反思的锚点：当"稳妥"的技术栈带来的维护成本持续攀升时，"激进"的选择是否反而更可持续？

作者最后留下一个未回答的问题：他们正在申请银行牌照，而审查官会如何审视这套"非标准"技术栈的长期可维护性？