必须用ResultSet.getBigDecimal()替代getDouble()，因Oracle NUMBER是十进制高精度类型，double为二进制浮点（IEEE 754），语义不兼容导致必然精度丢失；需判空、禁用new BigDecimal(double)、运算时指定scale与RoundingMode。

直接用 ResultSet.getBigDecimal() 替代 getDouble() 或 getFloat()，这是最根本、最可靠的解法。不是“推荐”，而是必须——Oracle 的 NUMBER 是十进制高精度类型，double 是二进制浮点，语义不兼容，丢精度是必然的，不是偶然。

为什么 getDouble() 一定会丢精度

Oracle 的 NUMBER(10,2) 存的是精确的十进制值，比如 0.1 或 9999999999999999.99；而 double 按 IEEE 754 存储，它根本无法精确表示大多数十进制小数。0.1 在 double 里实际是 0.10000000000000000555...；超长整数（如 19 位 ID）超出 2^53 范围后，末尾数字直接归零。这不是 JDBC 驱动 bug，是底层数据模型冲突。

常见错误现象包括：

• rs.getDouble("amount") 返回 12345678901234568.0，而数据库里明明存的是 12345678901234567.99
• 金额计算前后对不上，尤其在累加、四舍五入后差异肉眼可见
• 前端展示 ID 字段变成 12345678901234568（最后一位被改写）

getBigDecimal() 怎么用才安全

Oracle JDBC 驱动默认将 NUMBER 映射为 BigDecimal，只要你不主动调用 getDouble()，这个保护就生效。但要注意几个实操细节：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

立即学习“Java免费学习笔记（深入）”；

• 别写 rs.getDouble("price")，统一改成 rs.getBigDecimal("price")
• 字段可能为 NULL：先判空再操作，BigDecimal price = rs.getBigDecimal("price"); if (price != null) { ... }
• 绝对不要用 new BigDecimal(rs.getDouble("price")) —— 这是在已损坏的数据上再套一层壳，精度回不来了
• 如果下游接口强制要 double（比如老系统或某些数学库），只能显式调用 bigDecimal.doubleValue()，并清楚这是有损转换，仅限非关键路径

BigDecimal 后续运算容易踩的坑

拿到 BigDecimal 只是第一步，后续计算若不注意，照样引入新误差：

• 构造时别用 double 参数：new BigDecimal(0.1) 实际传入的是 0.10000000000000000555...；该用字符串：new BigDecimal("0.1")
• 除法必须指定精度和舍入模式，否则抛 ArithmeticException：val1.divide(val2, 2, RoundingMode.HALF_UP)
• 比较大小用 compareTo()，不用 equals()：new BigDecimal("1.0").equals(new BigDecimal("1")) 返回 false（因 scale 不同）
• 数据库定义为 NUMBER(16,2)，业务加减也应统一保留 2 位小数，避免中间结果多出无效精度干扰最终展示

真正麻烦的从来不是“怎么换方法”，而是整个链路——从 JDBC 获取、到内存运算、再到序列化传输——每一步都可能悄悄把精度吃掉。尤其当团队里有人还在用 getDouble() + setScale() 自欺欺人时，问题会藏得更深。