Java自动装箱不导致计算错误，但用==比较包装类、遇null或超缓存范围[-128,127]时易引发逻辑异常；需用equals()或拆箱比较，警惕null导致NPE，集合运算要防null和性能开销，推荐基本类型用于计算、包装类仅用于泛型或空值场景。
Java 中自动装箱本身不会直接导致计算错误，但 在使用 == 比较包装类型、或涉及 null 值、或超出缓存范围时，容易产生意料之外的逻辑结果，看起来像“计算错误”。关键不是算错了，而是比较或运算逻辑被自动装箱/拆箱行为悄悄改变了。
避免用 == 比较 Integer 等包装类的值
Integer a = 127; Integer b = 127;
System.out.println(a == b); // true（因为缓存）
Integer c = 128; Integer d = 128;
System.out.println(c == d); // false（超出 IntegerCache 范围）
这并非计算错误，而是对象引用比较。应统一用 equals() 或先拆箱再比：
- 推荐：a.equals(b) —— 安全，但注意 a 可能为 null
- 更稳妥：a != null && a.equals(b)，或 a.intValue() == b.intValue()
- 若确定非 null，可直接用 a == b 的前提是数值在 [-128, 127] 内（不建议依赖）
警惕 null 值触发的 NullPointerException
Integer x = null;
int y = x + 1; // 运行时报 NPE！自动拆箱时 x 为 null
这是最常见的“隐形错误”。只要参与算术运算、比较（如 x > 0）、甚至条件判断（if (x == 5)），都可能因拆箱失败崩溃。
- 检查是否可能为 null：if (x != null) { ... }
- 提供默认值：int val = (x != null) ? x : 0;
- JDK 8+ 可用 Objects.requireNonNullElse(x, 0)
在集合和泛型中注意类型擦除与装箱开销
List
list.add(1); list.add(2);
int sum = 0;
for (Integer i : list) sum += i; // 每次循环都自动拆箱
虽不会出错，但高频场景（如大数据量循环）可能影响性能；更严重的是，若 list 中混入 null，sum += i 就会崩。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
- 确保集合不存 null（可在 add 时校验）
- 对性能敏感场景，考虑用原始类型集合库（如 Eclipse Collections、Trove、FastUtil）
- Stream 计算时也需防 null：list.stream().filter(Objects::nonNull).mapToInt(Integer::intValue).sum()
统一使用基本类型做计算，包装类型仅用于泛型/空值场景
设计上明确分工：
- 变量、参数、返回值需要表示“不存在”语义时，才用 Integer
- 所有中间计算、循环变量、数学运算，优先用 int、long、double
- 从包装类获取值时，显式拆箱并校验：int value = obj != null ? obj : 0;
这样既规避了自动装箱的陷阱，又保持了代码意图清晰。
