排查double转int错账关键在定位转换点与未发现原因，需从数据流、转换点、边界值切入，重点检查元转分乘法后强转、前端JSON解析、报表汇总及负数处理等高危位置。
排查因 double 强转 int 时直接截断小数（而非四舍五入）引发的金额错账，关键不在“怎么转”，而在“哪里转错了”和“为什么没被发现”。这类问题隐蔽性强、复现难、影响准确定价或结算，需从数据流、转换点、边界值三方面系统切入。
定位可疑转换代码段
金额类业务中，所有 double → int 的显式强制转换都应视为高危操作。重点扫描以下位置：
- 涉及“元→分”换算的乘法后强转：如
(int)(amount * 100)—— 这是最常见错账源头； - 前端传入金额经 JSON 解析为 double，后端未校验直接转 int 存库；
- 报表汇总、分页计算、折扣比例取整等中间逻辑中隐含的类型转换；
- 使用
Math.floor()或(int)处理负数金额（如退款、冲正），因向零截断导致结果偏大（例如(int)-1.9得 -1，但业务要求向下取整为 -2）。
复现并验证精度丢失现象
不要依赖“看起来是整数”的 double 值。浮点数在二进制中无法精确表示十进制小数（如 0.1、0.01），看似 4385.73 的字符串，转成 double 后实际可能是 4385.729999999999...。验证步骤：
- 对原始金额字符串（如
"4385.73"）先用BigDecimal构造，再乘以 100 并setScale(0, ROUND_HALF_UP)，记录预期“分”值； - 用相同字符串调用
Double.valueOf()再乘以 100，强制转int，对比是否一致； - 打印中间 double 值的完整字符串表示（用
String.valueOf(d)而非System.out.println(d)），观察尾部是否出现.999999999994类误差。
检查金额流转全链路的数据类型
错账常发生在类型不一致的交接处：
- 数据库字段为
INT（存分为）但 Java 实体类对应int，而服务层却用double接收前端“元”单位参数； - RPC 接口定义返回
double amount，但调用方按整数解析； - 日志中打印金额用了
%.2f格式化，掩盖了底层 double 的真实值，导致排查时误判输入正确。
建议统一在入口层（如 Controller）就将金额字符串转为 BigDecimal，后续全程使用 BigDecimal 运算，仅在最终落库或调用旧接口时按需转为整型（并明确指定舍入模式）。
添加运行时防护与监控
静态扫描无法覆盖动态生成的数值。可在关键转换处加入断言或日志：
- 对
(int)(d * 100)类操作，增加校验：if (Math.abs(d * 100 - Math.round(d * 100)) > 1e-6) { log.warn("Precision loss detected: {} -> {}", d, (int)(d * 100)); } - 在金额相关 DAO 层，对写入前的
int centAmount反向转回元单位（centAmount / 100.0），与原始输入比对误差是否超阈值； - 对账系统中，将“分”字段与“元×100”重新计算值做差值比对，自动告警微小差异（如 ±1 分），这往往是截断问题的早期信号。
