应统一使用equals()比较integer对象，因其内部已处理null和类型校验；==仅比较引用地址，受缓存范围（默认-128~127）影响，在范围外或含new创建时必然失效，非bug而是设计使然。
直接用 equals() 或先拆箱再比较，是规避缓存边缘 Bug 最简单也最可靠的方式。缓存机制本身没问题，问题出在把 == 当作数值相等来用——它只比地址，不比值。
明确区分 == 和 equals 的语义
== 在包装类上永远是比较对象引用，不是数值。哪怕两个 Integer 都是 127，只要其中一个来自 new Integer(127)，== 就返回 false；而 128 即使都用自动装箱，== 也可能为 false。这不是 Bug，是设计行为。
- 所有数值比较统一走
a.equals(b)，内部已处理null和类型校验（推荐） - 确定非空时，用
a.intValue() == b.intValue()或a == b.intValue()（基本类型与包装类混合比较时自动拆箱） - 集合操作（如
HashMap的 key）、排序、去重等场景，必须依赖equals()和hashCode()，不能靠==
避免在边界值附近依赖缓存行为
缓存范围默认是 -128 ~ 127，但这个边界不是逻辑分界线，而是 JVM 的实现细节。业务代码不应假设 127 一定复用、128 一定不复用——尤其当项目启用了 -Djava.lang.Integer.IntegerCache.high=200 时，行为会变。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 测试用例不要只覆盖
127和128，应包含-128、-129、127、128、Integer.MAX_VALUE等典型边界 - 避免用
==做断言，比如assert a == b→ 改为assert a.equals(b) - CI/CD 中若使用不同 JDK 版本或 JVM 参数，缓存行为可能不同，需确保测试环境与生产一致
控制对象创建方式，减少不确定性
谁创建了对象，决定了它是否进缓存。自动装箱和 valueOf() 走缓存；new Integer() 绕过缓存；JVM 参数可调上限但不可靠。
- 禁止使用
new Integer(x)（已废弃），一律用Integer.valueOf(x) - 赋值语句
Integer i = 100;是安全的（等价于valueOf），但不要因此放松对比较逻辑的审查 - 从外部接收的包装类（如 API 返回、数据库映射），一律视为“可能未缓存”，不做
==假设
性能敏感场景优先用基本类型
高频循环、大量计算、集合遍历时，自动装箱会悄悄新建对象，拖慢速度并加重 GC。缓存只能缓解小范围问题，不能替代类型选择。
- 循环变量、累加器、临时结果，全部用
int、long等原始类型 - 遍历
List<integer></integer>时，用传统 for +get(i)，避免增强 for 触发隐式拆箱+潜在装箱 - 大批量数值处理，考虑用
int[]或IntArrayList（如 Eclipse Collections）代替泛型集合
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
