应使用包装类（integer、boolean等）替代基本类型以真实感知数据库null，配合orm显式配置（如@nullable、callsettersonnulls=true）确保null穿透至业务层，并在service层按需做空值兜底而非污染实体语义。
要让实体类正确对接旧库中已存的 NULL 字段并支持安全更新，核心不是“抹掉 null”，而是让 Java 层能真实感知、区分并可控处理数据库里的空值。关键在类型语义对齐 + ORM 行为显式化，而不是靠默认值掩盖问题。
用包装类替代基本类型，暴露数据库真实状态
旧库字段允许 NULL，但实体若声明为 int age 或 boolean enabled，JPA/Hibernate 在查询时会静默转成 0 / false；反向更新时，哪怕你传了 null，也可能被忽略或报错。必须改为：
- Integer age、Boolean enabled、LocalDateTime updatedAt
- String 类型本身可空，无需改动；但注意不要把 String code 错误地初始化为 ""，否则无法区分“空字符串”和“未填写”
- 主键、外键、时间戳等业务上非空字段，仍可用基本类型（如 long id），但需确保数据库 DDL 中有 NOT NULL 约束
配置 ORM 显式映射 NULL，禁用隐式兜底
避免框架自动“补零”或“填 false”，让 null 值穿透到业务逻辑层：
- JPA/Hibernate：在字段上加 @Column(nullable = true)，并确认实体类无参构造器不给这些字段赋初值（如 private Integer status = 0; 就是错误的）
- MyBatis：全局设置 callSettersOnNulls=true，确保数据库返回 NULL 时一定调用 setter(null)，而不是跳过
- MyBatis-Plus：在 @TableField 中明确写 fill = FieldFill.DEFAULT 或留空，避免自动填充干扰原始 NULL
更新时保留 NULL 意图，不强行覆盖
前端传参或 DTO 转实体时，若某字段没传（JSON 缺失或为 null），应保持其为 null，而非塞入默认值：
- 禁止在 setter 里写 this.age = age == null ? 18 : age; —— 这会让“用户没填”和“用户明确填了 18”完全不可分
- 更新操作前做判空：if (user.getPhone() == null) { updateWrapper.set("phone", null); }，让 SQL 真正执行 SET phone = NULL
- 使用动态 SQL（MyBatis）或 Example（JPA）只更新非 null 字段，避免把已有值误覆为默认值
兼容旧数据的兜底策略放在 Service 层
真正需要“null → 默认值”的场景（如统计报表要求 age 不为空），应在 Service 或 VO 转换环节做，而不是污染实体语义：
- public int getAgeForReport() { return Objects.requireNonNullElse(age, 0); }
- DTO 构建时用 MapStruct 的 @Mapping(defaultValue = "0") 或自定义转换器
- 数据库迁移脚本可批量补全历史 NULL（如 UPDATE users SET age = 0 WHERE age IS NULL AND status = 'active'），但这是数据治理动作，不应由 Java 实体承担
