将实体类中基本类型字段全部替换为对应包装类并配合显式空值处理，是解决高并发反序列化“字段类型黑洞”的最有效重构路径：避免Jackson静默填充伪默认值，确保null语义一致，并通过禁用自动设值、显式校验、DTO/领域模型分离及边界测试实现全覆盖防控。
直接说结论：把实体类里所有基本类型字段（int、long、boolean等）全部替换成对应包装类（Integer、Long、Boolean），并配合显式空值处理逻辑，是解决高并发反序列化“字段类型黑洞”的最有效重构路径。
为什么基本类型会成为类型黑洞的源头
Java反序列化时，如果字段声明为int age，而JSON中该字段缺失或传了null，Jackson默认会用0填充——这不是业务意图的“空”，而是强制兜底的“伪默认值”。在高并发场景下，这种静默覆盖极易掩盖真实数据缺失、引发金额归零、状态误判等线上事故。更危险的是，下游服务若用Integer接收同一字段，反序列化结果直接是null，两端语义彻底断裂。
重构三步法：从声明到校验全覆盖
-
统一字段声明为包装类：将
private int status改为private Integer status，private boolean enabled改为private Boolean enabled。这是语义回归的第一步——让“不存在”和“存在但为假/0”可区分。 -
禁用Jackson自动设默认值：全局配置
mapper.configure(DeserializationFeature.FAIL_ON_NULL_FOR_PRIMITIVES, true)，确保遇到null写入基本类型字段时直接报错，不给黑洞留缝隙。 -
在构造/Setter中做显式空值决策：例如
public void setStatus(Integer status) { this.status = Objects.requireNonNullElse(status, DEFAULT_STATUS); }，把“空值如何解释”从框架黑盒移到业务可控逻辑中。
配套必须做的两件事
仅改字段类型不够，还需同步落地：
-
DTO层与领域模型分离：对外暴露的DTO用包装类+
@JsonInclude(JsonInclude.Include.NON_NULL)，内部领域对象按需使用基本类型——避免把传输层的不确定性污染核心逻辑。 -
加字段级单元测试：用
{"id":"123","status":null}这类边界JSON反序列化，断言结果中status为null而非0；再用{}空对象测试，验证是否抛出预期异常。
别踩这个坑：不是所有地方都要改
数据库实体类若已用JPA映射且@Column(nullable = false)强约束，可保留基本类型——因为DB层已保证非空，反序列化只是还原已存值。黑洞真正高发区是RPC接口DTO、MQ消息体、缓存value这些直面外部输入的“边界类”。聚焦这里重构，收益最大。
