商业结算应避免使用double，因其二进制浮点精度缺陷会导致金额偏差；必须采用定点数或十进制高精度类型（如bigdecimal、decimal、decimal），确保分位精确与舍入确定性。
用 double 进行物理公式计算本身不能规避商业结算中的数值抖动；相反，在商业结算中应避免使用 double，因为它固有的二进制浮点精度缺陷（如 0.1 + 0.2 ≠ 0.3）会直接导致金额偏差、对账不平、审计风险等问题。
物理计算与商业结算的精度需求本质不同
物理建模常允许相对误差（如 1e−12），double 提供约 15–17 位十进制有效数字，基本满足科学计算需求。但商业结算要求精确到分（即小数点后两位）且不可累积误差，必须实现“所见即所得”的确定性运算。
- 例如：199.99 × 0.08（8% 税）用
double计算可能得 15.999199999999999，四舍五入后变成 16.00 或 15.99，取决于底层舍入模式 - 而真实业务要求：严格按“元为单位，保留两位小数，银行家舍入（或指定规则）”执行
商业结算应改用定点数或高精度十进制类型
主流方案不是修复 double，而是绕过它：
-
Java：使用
BigDecimal，构造时用字符串（new BigDecimal("199.99")），避免double构造器引入初始误差 -
C#：用
decimal类型（128 位，专为金融设计，基数为 10） -
Python：用
decimal.Decimal，设置getcontext().prec = 28并指定舍入策略 -
数据库：字段类型选
DECIMAL(12,2)或NUMERIC，而非FLOAT/DOUBLE
若必须混合物理模型与计费逻辑，需明确分层隔离
例如仿真系统输出能耗值（kWh），再折算电费：
- 物理层：可用
double计算 kWh（如积分功率曲线），结果保留足够有效位（如 6 位小数） - 转换层：将物理结果转为整数“厘”（1 元 = 100 分 = 1000 厘），用定点缩放（如 ×1000 →
long）或BigDecimal截断/舍入 - 计费层：所有加减乘除、税率、折扣均在整数或
BigDecimal上完成，最终再格式化为“元.分”字符串输出
警惕常见“伪修复”陷阱
这些做法看似缓解抖动，实则掩盖问题、不可靠：
- 对
double结果调用Math.round(x * 100) / 100.0：仍基于错误中间值舍入，多次运算后误差扩散 - 用
printf("%.2f", x)格式化输出：仅影响显示，内部值未修正，后续参与计算仍出错 - 声称“我们只做一次计算所以没问题”：实际系统存在复核、退款、分摊、日结月结等多阶段叠加场景
不复杂但容易忽略：商业金额不是实数，是离散的、有最小单位（分）、有法定舍入规则的货币量——它需要的是确定性算术，不是近似解。
