金融产品建模用Decimal还是double？复杂计算场景该如何选型？

首先明确「涉及货币金额用decimal」的共识是有明确适用前提的，仅覆盖台账、清算、对账、资金划转类场景，这类场景的核心要求是10进制表示的绝对精确，避免因二进制浮点的舍入误差导致账目不平，该场景下必须使用decimal，没有折中空间。

二者的核心适用边界 #

你提到的复杂数值计算场景，完全不需要强制遵循decimal的要求，判断标准可以简化为以下两点：

• 如果计算过程本身存在固有误差：三次样条插值、随机模型、微分积分、统计定价这类场景，计算结果本身是基于模型假设的近似值，误差范围通常远大于double类型1e-16级别的精度损失，此时decimal的10进制精度优势完全没有实际意义。
• 如果计算依赖的生态原生不支持decimal：全球主流的数值计算、金融量化库的底层实现全都是基于double类型，强行使用decimal等于要自己重写整套经过行业验证的底层函数，反而会引入更高的人为误差风险，开发和维护成本也完全不成正比。

行业通用落地实践 #

目前全球主流的量化交易、衍生品定价系统的实现逻辑都是「计算层全链路用double，存储/结算层转decimal」，仅在计算结果输出到台账环节做一次类型转换并按照业务规则做精度舍入即可，中间计算过程完全不需要引入decimal。

对于你提到的反复类型转换的问题，完全可以通过分层设计规避：只在计算模块的入口和出口各做一次类型转换，不需要在计算过程中来回切换类型。如果担心精度问题，可以增加简单的校验逻辑：同一输入下，抽样对比double计算后转decimal的结果，和全链路decimal计算结果的差值，只要差值在业务允许的误差范围内（比如小于最小计价单位的1/10），就可以完全放心使用浮点类型做中间计算。

总结来说，「货币就用decimal」是针对记账场景的简化结论，不适用于数值计算类场景，当计算复杂度达到统计模型、数值求解的级别时，强行用decimal确实是弊大于利的。

内容的提问来源于stack exchange，提问作者Guillaume