将长周期对象字段从包装类改为基本类型不能消除扫描死角，因“死角”源于弱/虚引用识别不足、线程局部变量或JNI全局引用等隐式强引用链，与字段类型无直接因果；但可改善null分支覆盖、减少对象逃逸、避免拆箱NPE中断路径分析。
把长周期对象字段从包装类改成基本类型，不能“消除扫描死角”，这个说法存在概念错位。扫描死角通常指安全扫描工具（如SAST、DAST）或JVM GC Roots遍历中遗漏的不可达对象路径，而包装类本身不会制造这类盲区；真正影响可达性分析和扫描覆盖的是对象引用关系、生命周期管理、以及是否被GC Roots强引用。
关键要分清：
- 包装类（如
Integer、Boolean）是普通Java对象，只要被持有，就会参与GC Roots可达性分析，不会天然成为“死角”； - 所谓“死角”，多源于弱引用、虚引用未被工具识别，或对象被线程局部变量、JNI全局引用、未注销监听器等隐式强引用链保护，导致本该回收的对象滞留——这和字段用
int还是Integer无直接因果。
但重构确实能改善三类容易被扫描忽略的实际问题：
减少因空值引发的逻辑跳过
很多静态扫描工具对null分支覆盖不足，若字段声明为Integer status且常为null，工具可能漏检if (status == null)后的异常路径或默认行为：
- 改成
int status后，语义明确为“总有值”，扫描更易覆盖所有分支； - 配合
@NonNull注解或Lombok@RequiredArgsConstructor，可让SAST识别出构造缺失场景； - 数据库映射层若字段定义为
NOT NULL，实体用int能与DDL语义对齐，避免ORM静默补0掩盖空数据问题。
切断非必要对象逃逸路径
长周期对象（如缓存中的DTO、配置Bean、单例状态容器）若含大量Long lastModified、Double weight等包装字段：
- 每个包装类实例都是独立堆对象，即使值相同也不共享；
- 若该对象被多个线程访问，又未做同步，某些扫描工具可能因无法追踪跨线程引用而漏报竞态风险；
- 改用
long lastModified、double weight后，字段压入对象头内联存储（JVM 17+ ZGC下支持），不再产生额外堆对象，引用图更扁平，扫描路径更清晰。
避免自动拆箱触发的隐式异常中断
以下代码在运行时抛NullPointerException，但多数SAST工具难以推断user.getAge()返回null后== 18会崩溃：
if (user.getAge() == 18) { ... } // user.getAge() 返回 Integer改成int getAge()后：
- 方法契约强制非空，调用方无需判空；
- 扫描工具能更准确建模控制流，不因潜在NPE中断路径分析；
- 单元测试覆盖率也更容易打满，减少“看似覆盖实则跳过”的假象。
真正需要关注的扫描盲区不在字段类型，而在：
- 使用
ThreadLocal<SomeWrapper>却未重置，导致对象长期驻留； - 回调注册后忘记反注册（如
addWindowFocusChangeListener）； - JNI层创建的全局引用未释放；
- 日志框架中
MDC或MappedDiagnosticContext残留键值。
所以，重构字段类型是夯实基础，不是扫盲捷径。先统一语义（非空→基本类型，可选→包装类），再配合-Xlog:gc+ref=debug观察引用链，用jcmd <pid> VM.native_memory summary查JNI引用，才能真正收窄扫描死角。
