数字变货币函数怎么实现？银行核心系统的千分位与币种格式化实战

数字变货币函数怎么实现？银行核心系统的千分位与币种格式化实战

把原始数字变成带币种符号、千分位分隔的货币字符串，是财务系统最易出错的环节。我在银行核心系统干了十五年，光这个格式化函数就改过二十多个版本。

最朴素的做法是手动拼接：取整除得千分位，逐层加逗号，前面拼上"¥"。但写进生产代码后，浮点数精度立刻成为大坑——0.1加0.2不等于0.3，用double存金额迟早出事。正经做法是用BigDecimal，或者直接拿整数存"分"数字变货币函数怎么实现？银行核心系统的千分位与币种格式化实战，显示时再除以100。

负数和零的处理远比正数麻烦。-1234567该显示"-¥1,234,567"还是"¥-1,234,567"？零写"¥0.00"还是"¥—"？看着是细节，审计来了全是问题。我见过某银行因为负号位置不统一，被监管直接点名要求整改。

多币种场景下，函数签名就不能只收一个数字了。日元没有小数位数字变货币函数，英镑用GBP，某些非洲货币小数位是四位。我后来把参数设计成币种代码、精度、符号位置三个字段，配一张数据库里的格式配置表，新增币种不用改代码。

真正让我头疼的是性能。批量对账一次要格式化几千万条流水，纯字符串拼接跑起来CPU直接拉满。改成预分配缓冲区、去掉多余的String对象创建之后，耗时降了将近七成。别小看一个格式化函数，高并发下的GC压力往往就藏在这些不起眼的小方法里。

你们项目里金额是float还是整数存的？评论区聊聊。