Go 交易系统里那个隐藏的性能杀手

做 Go 开发的人估计都踩过这个坑：代码热点路径优化了又优化，不必要的 allocation 删了又删，结果一碰到小数运算，整个系统就崩了。单个 decimal 操作就能触发一堆堆内存分配，在最不该运行的时候把 GC 唤醒。

这种情况在金融系统、交易平台里太常见了。精度要求高，性能也不能丢，两头都得顾着。

传统 Decimal 处理的问题

Go 里的标准浮点类型大家都很熟，用着顺手，大多数场景够用。但说到底，它们就是把小数用二进制来表示的。

真正做金融计算的时候，麻烦就来了。需要精确的十进制运算？妥协就开始了。

很多人会想到 shopspring/decimal 这个库，确实好用，精度随便调。但问题在于——它每次运算基本上都会分配内存，这是设计决定的。

想象一下高频交易引擎在跑，每秒处理几千笔订单：

• 每次价格计算都要分配内存
• GC 迟早要跑
• 延迟峰值偏偏在最糟糕的时刻出现
• P99 延迟完全没法预测

普通 App 忍一忍也就过去了。但对 HFT 系统来说，微秒级延迟直接跟钱挂钩，这就受不了了。

零分配：说起来容易做起来难

概念很简单：所有运算都不在堆上分配新内存，全部用栈上的数据或者预分配的缓冲区。好处显而易见：性能稳定，没有 GC 带来的停顿。

但真要实现，得在设计上花心思：

• 能用固定大小的 decimal 就用固定大小的
• 运算尽量原地修改，别返回新对象
• 溢出和精度处理要提前想好
• 正常运行路径上绝对不能触发 panic

最后这点对交易系统特别重要。热点路径上一个 panic，可能就是错过机会、交易失败，后果很严重。靠谱的系统要把各种边界情况都处理好。

不只是 HFT 的事

虽然各种宣传都在说"HFT 级别性能"，但其实影响面广得多：

游戏后端 —— 玩家余额计算要精确，高峰期也不能卡。

电商平台 —— 秒杀或者过年过节那种大流量，得扛得住。

实时分析 —— 仪表盘上的指标计算要跟上数据流的速度。

支付通道 —— 延迟稳定直接影响用户体验和转化率。

说白了，热点路径上砍掉不必要的 allocation，这个原则在系统编程里是通用的。

Go 语言的优势

Go 的设计理念让零分配技术比很多语言都更容易实现。显式的错误处理逼着你去想边界情况。值语义是默认的，一不小心就在堆上分配的情况少了很多。pprof 这种工具能直接把 allocation 的热点可视化，开发阶段就能看到问题。

现在库也开始往这个方向靠拢了，说明 Go 生态在性能敏感领域越来越成熟。同一个需求，不同的库做不同的取舍，开发者可以根据自己的约束选合适的工具。

往后看

Go 在金融服务和交易基础设施领域用得越来越多，以后专门针对某类性能指标的库肯定会更多。"直接用 big.Float 得了"或者"随便精度够用就行"这种想法，慢慢会被更精细的方案取代。毕竟不同的系统有不同的需求，一刀切的方案越来越难满足大家了。

对于那些毫秒级甚至纳秒级延迟都重要的系统来说，零分配的 decimal 运算不是锦上添花，是刚需。

你在 Go 项目里遇到过 decimal 运算的性能问题吗？评论区聊聊你的经历和解决办法。