是的，optionalint 更省内存——它用原生 int 字段存储，无装箱开销；而 optional 依赖 integer.valueof() 装箱，必多分配对象，高频场景下 gc 与堆内存差异显著。
OptionalInt 比 Optional 真的更省内存吗？
是的，而且省得非常实在——OptionalInt 完全不装箱，底层用 int 原生字段存值；而 Optional<integer></integer> 一旦有值，就必然触发 Integer.valueOf() 装箱，至少多分配一个对象。在高频调用或大数据量场景下，GC 压力和堆内存占用差异明显。
常见错误现象：Optional.of(42) 返回的是 Optional<integer></integer>，不是 OptionalInt；想用原生类型可选值，必须从源头就用 IntStream 或显式构造。
-
OptionalInt.empty()和OptionalInt.of(42)是唯二推荐的创建方式，避免用OptionalInt.ofNullable(null)（它会抛NullPointerException） - 不能直接把
int变量传给Optional.of()——编译器会自动装箱，掉进陷阱 - 如果上游是
List<integer></integer>，别试图“转成”OptionalInt：先stream().mapToInt(i -> i).findFirst()，否则白搭
什么时候该用 OptionalInt，什么时候不该用？
适用场景很明确：你操作的本身就是原始 int 流水线，比如数组索引查找、数值计算结果、位运算返回值。不适用的典型情况是：值来自 JSON 解析、数据库映射、HTTP 响应体——这些天然就是引用类型，硬套 OptionalInt 反而要多一次拆箱判断，代码更啰嗦且无收益。
性能影响：OptionalInt.isPresent() 是纯字段读取，零开销；OptionalInt.orElse(0) 是直接返回字段值，没有方法调用开销；但 OptionalInt.getAsInt() 在空值时抛 NoSuchElementException，这点比引用版更严格，容易漏处理。
立即学习“Java免费学习笔记（深入）”；
- 用
IntStream.range(0, 100).filter(...).findFirst()→ 天然返回OptionalInt，直接接 - 用
Map.get("key")返回Integer→ 别强转，老实用Optional.ofNullable(map.get("key")) - 函数参数类型是
Optional<integer></integer>→ 不要改成OptionalInt，接口契约变了，调用方得全改
orElse / orElseGet / ifPresent 的行为差异
OptionalInt 的这三个方法签名和语义跟引用版基本一致，但关键区别在参数类型和执行时机：所有 orElse* 方法只接受 int 字面量或变量，不接受函数式接口里的装箱操作；ifPresent 的 Consumer 参数是 IntConsumer，接收原生 int，不是 Consumer<integer></integer>。
容易踩的坑：optionalInt.orElseGet(() -> Integer.valueOf(42)) 编译不过——lambda 必须返回 int，不能返回 Integer；写成 () -> 42 才对。另外，ifPresent(System.out::println) 会调用 IntConsumer 版本，输出的是原始 int，不会触发 Integer.toString()。
-
orElse(0)：立即求值，适合常量默认值 -
orElseGet(() -> computeDefault())：仅在空值时执行，且computeDefault()必须返回int -
ifPresent(val -> System.out.println(val * 2))：val是int，不是Integer，乘法无装箱
和 Optional 混用时最危险的操作
最危险的是隐式自动装箱 + null 检查错位。比如写 OptionalInt opt = ...; Optional<integer> ref = opt.isPresent() ? Optional.of(opt.getAsInt()) : Optional.empty();</integer>——看着合理，实则每次有值都新建一个 Integer 对象，彻底废掉 OptionalInt 的意义。
兼容性注意：OptionalInt 没有 map 或 flatMap 方法（因为没法泛型化到其他原始类型），想转换类型只能先 orElse 出 int，再手动包装；反过来，从 Optional<integer></integer> 转 OptionalInt 只能靠 .mapToInt(Integer::intValue).boxed().findFirst() 这种绕路写法，不推荐。
- 不要用
OptionalInt存Integer的 null 安全包装——它压根不设计干这事 - 日志打点时别写
log.debug("value={}", optionalInt)：toString()会触发装箱再 toString，建议显式optionalInt.isPresent() ? String.valueOf(optionalInt.getAsInt()) : "empty" - 单元测试里验证空值行为，别只测
isPresent()，一定要测getAsInt()抛异常的路径
原始类型可选值的收益，只在“整条链路都坚持用原始类型”时才真正兑现。中间任何一环偷偷装箱，前面省下的内存就白费了。
