Java隐式自动装箱的关键在于识别编译器在赋值、集合操作、三元表达式等边界点插入的valueOf()调用；缓存范围外或new构造绕过缓存，易致NPE、性能下降或逻辑错误。
识别 Java 中隐式自动装箱，关键不是“看到代码就怀疑”，而是盯住**编译器悄悄插入转换的边界点**——这些地方不报错、不警告，但运行时可能空指针、性能骤降或逻辑错乱。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
看赋值和初始化语句是否绕过valueOf
写 Integer i = 100 是安全的，它等价于 Integer.valueOf(100)，走缓存；但写 Integer j = new Integer(100) 就绕过了缓存，每次新建对象（该构造器已废弃）。更隐蔽的是框架内部调用，比如某些 JSON 库反序列化时若未配置严格模式，可能直接 new 包装类。检查字节码（javap -c）中是否出现 new java/lang/Integer 或 invokespecial 调用，就能确认是否走了非缓存路径。
查集合操作和泛型边界处的隐式转换
泛型擦除后，所有类型信息归零，装箱拆箱只发生在“进出集合”的那一刻：
• 向 List<integer></integer> 添加 int 值 → 必然装箱
• 从 Map<string integer></string> 取值后直接赋给 int → 必然拆箱
常见陷阱：用 map.get("key") + 1，若 key 不存在返回 null，拆箱即 NPE；又如 Arrays.asList(1, 2, 3) 返回 List<integer></integer> 没问题，但 Arrays.asList(new int[]{1,2,3}) 却返回 List<int></int>，因为 int[] 是原始类型数组，被整体装箱为一个 Object 元素。
抓三元表达式与条件判断中的拆箱风险
这类写法表面无害，实则高危：
• int x = flag ? obj.getValue() : 0 —— 若 obj.getValue() 返回 null，拆箱发生在取值后、比较前，NPE 不可避免
• if (boolFlag) { ... } —— boolFlag 为 null 时，拆箱调用 booleanValue() 直接崩溃
正确做法是显式防御：if (Boolean.TRUE.equals(boolFlag)) 或 if (Objects.nonNull(boolFlag) && boolFlag)。
扫日志、循环、Stream 等高频路径中的“看似无害”操作
这些位置装箱会批量生成短命对象，引发 GC 抖动：
• 日志拼接：log.info("id=" + id)，若 id 是 Long，触发 String.valueOf(Long)，内部 new char[]
• 循环 add：for (int i = 0; i ，每次 i 都装箱为 Integer<br>
• Stream 写法：<code>list.stream().mapToInt(i -> i).sum() 中的 i -> i 仍会触发自动拆箱；应改用 list.stream().mapToInt(Integer::intValue).sum()
用 Memory Profiler 或 JFR 查 “Allocation in TLAB”，按 class 过滤 Integer/Long，若它们在 onDraw、onBindViewHolder 等方法中高频出现，基本就是隐式装箱在作祟。
