应使用compareto()或解包后比较，而非==；==比较包装类地址而非值，缓存范围外失效；非null时优先用intvalue()等解包比较；可能为null时用objects.compare()确保安全。
别用 == 比较包装类的大小，它比的是地址，不是数值。缓存只是 JVM 的优化手段，不是行为保证——-128 到 127 内可能“碰巧” == 成立，一过边界就失效，这不是 Bug，是设计使然。
用 compareTo() 做安全的大小判断
所有数字型包装类（Integer、Long、Double 等）都实现了 Comparable 接口，compareTo() 是专为比较大小设计的方法：
- 返回负数表示前者小，正数表示前者大，0 表示相等
- 内部已处理 null（部分版本会抛 NPE，建议先校验）、类型一致性和特殊值（如 Double.NaN）
- 语义清晰，不依赖缓存，也不触发隐式装箱/拆箱
示例：a.compareTo(b) > 0 表示 a > b；a.compareTo(b) == 0 表示数值相等（比 equals() 更适合排序和条件分支）。
确定非 null 时，优先解包后用基本类型运算
如果能确保两个包装类对象都不为 null，直接转成基本类型再比，既高效又直观：
- a.intValue() > b.intValue() —— 简洁、无歧义、性能好
- 支持混合比较：比如 a.intValue() > 100 或 100L == b.longValue()
- 避免了 equals() 的布尔语义限制（只回答“是否相等”，不回答“谁更大”）
注意：不要在循环或高频路径中对 null 对象调用解包方法，否则会触发 NullPointerException。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
统一用 Objects.compare() 处理 null 安全场景
当无法完全排除 null 时，Java 7+ 提供的 Objects.compare() 是最稳妥的选择：
- 签名是 Objects.compare(T a, T b, Comparator super T> c)
- 自动判空：任一为 null 时按约定规则处理（如 null 视为最小值）
- 可复用现有比较器，也可传入 lambda，例如：Objects.compare(a, b, Integer::compareTo)
这比手动写 a == null ? (b == null ? 0 : -1) : (b == null ? 1 : a.compareTo(b)) 清晰得多。
警惕集合与框架中的隐式比较
HashMap 的 key 查找、TreeSet 排序、Stream.sorted() 等，底层都依赖包装类的 equals() 和 compareTo()，而非 ==：
- 用 == 判断 Map 中是否存在某个 Integer key，一定失败（除非恰好命中缓存）
- MyBatis 映射结果、JSON 反序列化得到的包装类对象，几乎都不走缓存，更不能信 ==
- 日志或断言中写 assert a == b，测试可能通过，上线必翻车
只要涉及业务逻辑判断，一律把 == 替换为 Objects.equals()（相等性）或 Objects.compare()（大小关系）。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
