排查double转int错账需先验证问题：列出所有(int)xxx或intvalue()位置，对小数输入源补日志打印原始值、转换值及差值，差值持续0.4–0.9即为错账信号；金额类必须用math.round()或bigdecimal，禁用强转；拦截excel、json、数据库等精度陷阱源头；加断言与监控实现前置防控。
排查 double 强转为 int 导致的错账，核心是识别“本该四舍五入或向下取整，却用了向零截断”这一逻辑偏差，尤其在金额、计数、分页、比例换算等业务场景中极易引发肉眼难察的系统性偏差。
确认是否真发生了截断式错账
先验证问题是否存在，而非直接修改代码：
- 把所有涉及
(int)xxx或intValue()的地方列出来，重点检查输入来源含小数（如 Excel 导入值、API 返回的浮点数、计算中间结果）的位置 - 对每个转换点补日志：打印原始 double 值、强转后 int 值、两者差值（
Math.abs(d - (int)d)），若差值长期稳定在 0.4–0.9 之间，大概率是错账信号 - 人工抽样比对：比如某笔订单实付 299.99 元 × 100 = 29999.0，但强转后变成 29999；而 299.50 × 100 = 29949.999999999996（二进制精度误差），强转得 29949 —— 少了 1 分钱，积少成多就成错账
区分业务语义，选对取整方式
不是所有 double→int 都该改，关键看业务含义：
- 金额类（如分转元、元转分）：必须用
Math.round()或BigDecimal，禁用(int)。例如int fen = (int) Math.round(yuan * 100) - 页码/索引/分组编号：需向下取整（
Math.floor()），因为第 3.9 页应显示第 3 页，不是第 3 页或第 4 页随机跳变 - 阈值判断（如“满 3.2 件打 9 折”）：应向上取整（
Math.ceil()），3.2 件即按 4 件计，否则优惠不生效 - 纯计数（如用户填写的“期望购买数量”）：若输入框限制为整数，后端不应再做 double 转 int，而应校验原始字符串或用
Long.parseLong()
拦截典型精度陷阱源头
很多错账不是写错转换逻辑，而是上游数据已失真：
-
Excel 导入值：Apache POI 读 numeric cell 默认返回 double，2.3×100 可能得 229.99999999999997 → 强转为 229。改用
cell.getNumericCellValue()后立刻套BigDecimal.valueOf(d).setScale(0, RoundingMode.HALF_UP).intValue() -
JSON 解析：Jackson/Fastjson 对数字字段默认解析为 double，即使前端传 "123" 也可能变 123.0。配置
DeserializationFeature.USE_BIG_DECIMAL_FOR_FLOATS强制走 BigDecimal -
数据库浮点字段：避免用
DOUBLE存金额，改用DECIMAL(10,2)；若无法改表结构，查出后立即用BigDecimal构造，再执行 round 或 truncate
加防御性断言与监控
让错账在上线前暴露，而非等财务对账才发现：
- 在关键转换处加断言：
if (d - (long)d > 0.999) throw new IllegalStateException("double 精度异常: " + d); - 对金额类转换，统一封装工具方法，内部强制走
BigDecimal并记录 traceId，便于事后审计溯源 - 在日志平台配置告警规则：连续 5 次同接口出现
Math.abs(d - (int)d) > 0.1且业务类型为“支付”“结算”，立即通知负责人
