不能。double因IEEE 754二进制浮点机制无法精确表示0.1等十进制小数，导致商业结算中出现确定性误差，故仅适用于接受舍入误差的物理建模，禁用于货币、利息、对账等契约性场景。
不能。double 不适合用于商业非线性结算，无论你如何“规避”，它本身不具备十进制精确性，抖动不是偶然现象，而是确定性误差。它只适合纯物理公式计算——前提是接受科学精度、允许舍入误差、不涉及货币或契约性结果。
double 的合理定位：物理建模可用，商业结算禁用
double 基于 IEEE 754 二进制浮点标准，天生擅长表达连续量（如速度、温度、力、时间），也支持开方、三角、指数等函数运算。在物理仿真、数值积分、流体力学求解中，其 15–17 位有效数字和宽动态范围是优势。
但它无法精确表示 0.1、0.01、0.05 等常见十进制小数。例如：
- 0.1 + 0.2 == 0.3 → 结果为 false
- 19.99 × 3 → 得到 59.970000000000006
- 日利率 0.01% 复利 365 天 → 理论 10381.03，double 计算可能得 10381.02
这种误差在物理模型中常被归入“离散化误差”或“截断误差”，可接受；但在账单、利息、分润、对账场景中，1 分钱偏差就是逻辑错误，不是“抖动”，是系统缺陷。
若必须用 double 做物理计算：控制误差传播的实操要点
当进行运动学、热传导、信号处理等非商业类计算时，可保留 double，但需主动管理精度风险：
- 避免链式减法（如 a - b - c），改用补偿算法（Kahan 求和）或重组表达式
- 比较浮点数时不写 ==，而用 Math.abs(a - b)
- 对时间步长、网格间距等关键参数，优先选用能被 2 的幂整除的值（如 0.125、0.0625），减少表示误差
- 输出结果前做一次 Math.round(x * 1e6) / 1e6 控制显示位数，但注意这只是格式化，不修正内部值
商业非线性结算必须换类型：三种可靠路径
所谓“非线性结算”，比如阶梯费率、复利计息、按量分润、滑点定价等，其公式本身可能含乘方、条件分支、迭代收敛——这些操作会放大 double 的原始误差。必须切换数据载体：
- 首选 BigDecimal（字符串构造）：用 new BigDecimal("19.99")，不用 new BigDecimal(19.99)；所有运算调用 add/subtract/multiply/divide，除法必须指定 scale 和 RoundingMode.HALF_UP
- 整数放大法（推荐高频交易/支付核心）：金额统一存为“分”（×100）、利率存为“‱”（×10000）、费率存为“‱”或“ppm”（×1000000），全程 long/int 运算，仅展示时除以对应倍数
- 领域专用库（如 Hutool NumberUtil）：封装了安全的字符串解析、四则运算、百分比计算、舍入策略，降低手写 BigDecimal 的出错概率
一个典型误用对比：电商满减+复利券
假设用户有 100 元余额，叠加“满 99 减 5”与“年化 8.5% 日复利券”，T+30 天后应得本息：
- 用 double 计算：初始值 100.0 → 扣减 5.0 → 剩余 95.0 → 每日 × (1 + 0.085/365)，30 次后结果漂移不可控，且无法与财务系统对平
- 正确做法：余额存为 10000（单位：分），满减为 500（分），日利率存为 850（单位：‱，即 8.5% = 850/10000），所有中间值保持整数运算，最终再转回元并保留两位小数
