integer用==比较在-128~127范围内返回true（因integercache复用同一对象），超出范围则返回false（每次新建对象，引用不同）；应统一使用equals()或objects.equals()比较值。
数值比较必须用 equals()，别碰 ==
Integer a = 127; Integer b = 127; 用 == 比较返回 true，但 Integer c = 128; Integer d = 128; 用 == 却返回 false。这不是 bug，是 IntegerCache 缓存机制在起作用：-128 到 127 的整数装箱后复用同一个对象，超出范围则新建对象。== 比的是引用地址，不是数值本身。
所有包装类（Integer、Long、Boolean 等）都存在类似问题。唯一安全、语义明确的比较方式是调用 equals() 方法。
- 推荐写法：Objects.equals(a, b)——它能自动处理 null，避免 NPE
- 不推荐：
a == b（引用比较）、a.equals(b)单独用（若 a 为 null 会抛空指针） - 注意：
Objects.equals(null, null)返回 true，Objects.equals(128, null)返回 false
有 null 参与时，拆箱前必须校验
自动拆箱本质是调用 intValue()、booleanValue() 等方法。一旦包装类对象为 null，立刻触发 NullPointerException。最危险的场景不是显式赋值，而是隐式参与运算或判断。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 三元表达式陷阱：
int x = flag ? obj.getValue() : 0;——若 getValue() 返回 null，JDK 8u40 之前版本仍会先尝试拆箱，直接报错 - 集合取值后直接运算：
for (Integer num : list) { sum += num; }——list 中只要有一个 null，循环第一轮就崩 - 安全写法：
int x = Objects.requireNonNullElse(obj.getValue(), 0);或显式判空：if (obj != null) sum += obj.intValue();
设计阶段就想清楚：该用基本类型还是包装类型
包装类存在的核心价值是表达“可能为 null”的语义，比如数据库字段允许为空、API 返回可选值、配置项未设置等。如果业务逻辑中数值必然存在、不允许缺失，就该用 int、boolean 等基本类型。
- 用基本类型：性能更好、无空指针风险、语义更清晰（如循环计数器、数组索引、数学计算）
- 用包装类型：仅当需要区分“有值”和“无值”两种状态（如 DTO 字段、Map 的 value、Optional 的替代场景）
- 混用要谨慎：方法参数接收 Integer，但内部做算术运算，必须先非空校验再拆箱
泛型集合和 Stream 处理要特别小心
ArrayList
- 高频数值计算场景，优先考虑 int[] 或 Eclipse Collections 的 IntList
- Stream 求和时，用
list.stream().mapToInt(Integer::intValue).sum()更安全，避免 mapToInt(i -> i) 触发隐式拆箱 - 从 JSON 或 ORM 映射拿到的包装类字段，不要假设非 null——即使数据库设了 NOT NULL，中间层也可能因异常或兼容逻辑返回 null
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
