JDBC驱动对可空整型列调用getInt()会静默返回0而非null，导致业务语义错误；应改用getObject("col", Integer.class)或getInt()+wasNull()判断，ORM需确保字段为Integer类型，并通过IDE/CI拦截、建表约束和工具类实现长效防御。
这个问题核心在于：JDBC 驱动在读取允许 NULL 的整型列（如 INT NULL）时，若使用 getInt() 这类返回基本类型的方法，遇到 NULL 会静默转为 0，而非抛异常或返回 null。在大容量数据场景下，这种“0 替代 NULL”会彻底扭曲业务语义——比如“未填写年龄”变成“年龄为 0 岁”，“未结算金额”变成“已结算 0 元”，后果严重。
确认是否触发了 JDBC 的 int 隐式转换陷阱
先验证问题是否存在，而不是直接假设：
- 检查 Java 代码中是否对可能为 NULL 的整型字段调用了
rs.getInt("col_name")或rs.getInt(index)——这是最常见源头 - 对比数据库原始值与 Java 实体中对应字段：查几条已知含 NULL 的记录，看程序里读出来是不是全成了 0
- 用
rs.getObject("col_name")或rs.wasNull()辅助验证：
int val = rs.getInt("amount");
boolean isNull = rs.wasNull(); // 必须紧跟 getInt() 后立即调用！
如果isNull == true但val == 0，就坐实了该陷阱
区分数据库 NULL 与 Java 基本类型的语义鸿沟
MySQL 中的 NULL 表示“未知/缺失”，而 Java 的 int 是确定值，无法表达“未知”。JDBC 规范要求驱动对基本类型 getter 在遇到 NULL 时返回默认值（int 是 0，boolean 是 false），这不是 bug，是设计行为。关键是要主动规避，而非依赖驱动“做对事”。
- 永远不要用
getInt()、getLong()、getBoolean()等基本类型方法读取可空列 - 改用包装类型方法：
rs.getInt("col")→rs.getObject("col", Integer.class)或rs.getInt("col")+rs.wasNull()判断 - ORM 框架（如 MyBatis、Hibernate）默认映射到包装类型（
Integer），只要实体字段声明为Integer而非int，通常可避免；但需检查自定义 TypeHandler 或 ResultMap 是否误用了基本类型
线上紧急止血与数据修复策略
若已上线且数据已被错误写入（如把 NULL 更新成 0），需分两步处理：
-
立即拦截新污染：回滚或发布 hotfix，将所有相关
getInt()替换为安全读取方式，并加日志告警：“发现 NULL 字段被读为 0，触发风控拦截” -
定位历史脏数据范围：在数据库侧执行抽样比对
SELECT id, amount, updated_at FROM orders WHERE amount = 0 AND updated_at > '2026-05-15' AND (amount IS NULL OR amount = 0);
注意：不能直接WHERE amount IS NULL（因已被覆盖），要结合时间窗口、业务规则（如“金额=0 且无退款标记”可能是异常）人工或脚本识别可疑批次 - 谨慎恢复：若有备份或 binlog，优先回溯原始 NULL；若无，需结合业务上下文判断是否可置为 NULL、或需人工复核——切勿批量“把 0 改回 NULL”，可能误伤真实为 0 的合法数据
长效防御：从开发规范到自动化检测
靠人盯代码不可持续，需嵌入工程链路：
- 在 IDE 检查规则中加入：禁止在可空字段上使用
ResultSet.getInt()，CI 流水线扫描并阻断 - 数据库建表强约束：对真正“不允许缺失”的字段，定义为
NOT NULL并设合理默认值；对“缺失即有意义”的字段，确保应用层全程用Integer接收 - 在 DAO 层统一封装安全读取工具类，例如：
public static Integer safeGetInt(ResultSet rs, String col) throws SQLException {
Object obj = rs.getObject(col);
return obj == null ? null : (Integer) obj;
}
