代码评审应聚焦自动装箱/拆箱引发的性能损耗、空指针异常及逻辑错误风险：集合操作隐式转换、==误比包装类、null参与拆箱、高频路径装拆箱均需重点审查。
代码评审中识别自动装箱与拆箱，关键不是找“语法糖本身”，而是发现它引发的潜在风险点。Java 编译器会静默处理这些转换，但它们在运行时可能暴露性能、空指针或逻辑错误。评审时应聚焦行为和上下文，而非单纯看赋值语句。
看集合操作中的基本类型直传
当看到 List<Integer>、Map<String, Long> 等泛型集合，且直接使用 add(42)、put("key", 100L) 或 get(0) 赋给基本类型变量时，就存在隐式装箱/拆箱：
- list.add(5) → int 自动装箱为 Integer（每次调用都可能新建对象）
- int value = map.get("count") → 若返回 null，此处直接触发 NullPointerException
- for (int i : list) → 每次迭代都发生一次拆箱
查 == 比较包装类变量的场景
遇到 Integer a == Integer b、Long x == y 这类写法，必须警惕：
- 若数值在 -128～127 范围内，可能因缓存导致 == 偶然为 true，但逻辑不可靠
- 超出该范围，== 实际比较的是引用地址，结果几乎总为 false
- 正确做法应是 a.equals(b)，且需确认 a 不为 null（或用 Objects.equals(a, b)）
盯住可能为 null 的包装类参与运算或赋值
任何涉及拆箱的位置，只要上游来源不可控（如方法返回值、JSON 反序列化字段、数据库查询结果），就是高危点：
立即学习“Java免费学习笔记（深入）”；
- int total = user.getAmount(); —— 若 getAmount() 返回 Integer 且可能为 null，这行会崩溃
- if (status == Status.ACTIVE) 中，status 是 Boolean 类型，null 会导致 NPE
- 建议改为显式判空：int total = user.getAmount() != null ? user.getAmount() : 0;
扫性能敏感路径中的高频装拆箱
在循环体、高频调用方法、流式计算（如 stream().mapToInt(...) 之前用 map()）、或大数据量处理逻辑中，要特别注意：
- for (int i = 0; i —— 百万次装箱，GC 压力明显
- 替代方案：用原始类型集合库（如 Eclipse Collections 的 IntList）或预分配、批量处理
- 流操作中优先使用 mapToInt()、mapToLong() 等原始类型专用接口，避免中间 Integer 对象
