应始终用 equals() 或拆箱比较，而非 ==；缓存仅为优化手段，仅对 valueof() 和自动装箱生效，new integer() 绕过缓存；-128~127 外的 integer 用 == 不可靠；集合操作必须依赖 equals()/hashcode()；其他包装类缓存范围各异，统一用 equals() 最安全。
直接用 equals() 或拆箱比较，比纠结缓存范围更可靠。缓存本身是优化手段，不是行为契约；依赖它写代码，反而容易在边界处翻车。
只对自动装箱和 valueOf() 生效
缓存池只响应 Integer.valueOf(100) 或 Integer i = 100; 这类写法。它不会拦截 new Integer(100) ——这个构造器已被弃用，且每次新建对象，哪怕值在 -128~127 内，也绕过缓存。
- ✅ 推荐：
Integer a = 100;、Integer b = Integer.valueOf(100);→ 复用同一对象 - ❌ 避免：
Integer c = new Integer(100);→ 总是新对象，c == a为 false
超出 -128~127 就别信 ==
一旦数值落在 128 及以上或 -129 及以下，Integer.valueOf(200) 返回的是新对象，两次调用不共享实例。此时 == 比较地址，结果不可预测（实际几乎总为 false），但 equals() 始终返回 true。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
Integer x = 127, y = 127;→x == y是 true（巧合，因复用缓存） -
Integer m = 128, n = 128;→m == n是 false（两个独立对象） - 无论范围内外，
m.equals(n)都安全返回 true
集合与 Map 中尤其要小心
HashMap 的 key 如果是 Integer，缓存失效会导致语义错误：比如 map.put(128, "a") 和 map.get(128) 理论上应命中，但如果两次 128 创建的是不同对象（如某次来自 new），而 equals/hashCode 实现正确，仍能工作；但若误用 == 判断 key 是否存在，就会漏匹配。
- Key 比较必须依赖
equals()和hashCode()，这是 HashMap 正常工作的前提 - 不要在业务逻辑里用
==判断两个 Integer 是否“相等”，哪怕你刚确认它们值一样 - 对确定非 null 的场景，可写
i1.intValue() == i2.intValue()，简洁且无陷阱
其他包装类的缓存情况
不是所有包装类都和 Integer 一样。Byte、Short、Long 默认也缓存 -128~127；Character 缓存 0~127；Boolean 只有 TRUE/FALSE 两个常量；Float 和 Double 完全不缓存。
-
Byte b1 = 100; Byte b2 = 100;→b1 == b2为 true -
Double d1 = 1.0; Double d2 = 1.0;→d1 == d2为 false（永远新建对象） - 统一用
equals()能覆盖全部类型，无需记忆各缓存规则
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
