Oracle NUMBER默认映射为BigDecimal，非bug而是Hibernate保精度的保守策略；实体字段需显式声明Long/Integer等类型并配合类型转换或UserType，否则易触发ClassCastException或空值异常。
Oracle NUMBER 默认映射到 BigDecimal 很容易踩坑
Spring Data JPA（底层 Hibernate）对 Oracle 的 NUMBER 类型默认映射为 BigDecimal，哪怕数据库字段定义是 NUMBER(10,0) 或 NUMBER(1)（即整数型）。这不是 bug，是 Hibernate 为保精度的保守策略。但直接用 BigDecimal 做主键、做条件查询、甚至和 int/Long 比较时，极易触发 ClassCastException 或空值逻辑异常。
- 实体类里写
private int id;映射NUMBER(10,0)→ 启动报错：org.hibernate.MappingException: Unable to determine appropriate JDBC type - 写
private Long status;映射NUMBER(1)→ 查询返回null，但数据库明明存了1，原因是 Hibernate 读取后没自动转型，而你代码里又没判BigDecimal实例 - JPA 查询中用
WHERE status = :status，传入1（Integer），但字段实际是BigDecimal→ 可能查不到，尤其在 Oracle 12c+ 的严格类型匹配模式下
@Column(precision, scale) 不影响 Java 类型选择
@Column(precision = 10, scale = 0) 这类注解只控制 DDL 生成（建表语句），**不参与运行时类型映射决策**。Hibernate 仍按列类型 NUMBER 全局规则走，不会因为你写了 scale = 0 就自动选 Long。
- 想让
NUMBER(10,0)映射为Long，必须显式声明 Java 字段类型为Long或long，且确保数据库值不超范围（否则抛ArithmeticException） -
NUMBER(5,2)必须用BigDecimal或Double；用Float会丢精度，Hibernate 也不推荐 - 如果字段允许
NULL，别用基本类型（如int、long），否则空值会变成默认值（0），掩盖业务语义
自定义 UserType 是最稳妥的映射方案
当项目中大量存在 NUMBER(1) 表示布尔、NUMBER(10,0) 表示 ID、NUMBER(3) 表示状态码等场景时，硬编码 BigDecimal 会让业务层充满 .longValue() 和 .intValueExact()，极易出错。这时应实现 UserType，把 Oracle NUMBER 按精度/标度自动转成目标 Java 类型。
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
例如，一个只处理整数型 NUMBER 的轻量级转换器：
立即学习“Java免费学习笔记（深入）”；
public class NumberToLongType implements UserType<Long> {
@Override
public Long nullSafeGet(ResultSet rs, String[] names, SharedSessionContractImplementor session, Object owner) throws SQLException {
BigDecimal bd = (BigDecimal) rs.getObject(names[0]);
return bd == null ? null : bd.longValue();
}
// ... 其余方法省略，需实现 deepCopy / returnedClass / sqlTypes 等
}
- 注册方式：在实体字段上加
@Type(type = "com.example.NumberToLongType") - 注意：该类型不能用于主键或外键关联字段，除非所有关联方都用同一
UserType，否则 Hibernate 关联解析会失败 - 更安全的做法是配合
@Converter（JPA 2.1+）做属性级转换，但仅限于非主键、非关系字段
Oracle 12c+ 的 NUMBER(*,0) 和 Identity 列要特别小心
Oracle 12c 引入了 GENERATED ALWAYS AS IDENTITY，对应列类型是 NUMBER(38)。Hibernate 默认仍映射为 BigDecimal，但 Spring Data JPA 的 @GeneratedValue(strategy = GenerationType.IDENTITY) 要求字段是数字类型（Long 等），否则启动就失败。
- 解决方案：字段声明为
private Long id;，并确保 Oracle 序列或 identity 列值在Long.MAX_VALUE范围内 - 如果数据库用了
NUMBER(*,0)（无精度限制），Hibernate 会映射为BigInteger，此时必须用BigInteger字段，不能强转 - 测试时务必连真实 Oracle 实例跑，H2/HSQLDB 对
NUMBER的模拟行为差异极大，本地测试通过不代表生产不出问题
NUMBER 映射不是配置开关一开就能解决的事，它横跨 JDBC 驱动行为、Hibernate 类型注册机制、JPA 规范约束三层。最容易被忽略的是：**同一个 NUMBER 列，在不同 Oracle 版本、不同驱动版本、不同 Hibernate 版本下，映射结果可能不同**。上线前一定要用目标环境验证类型推断结果。 
