OptionalLong是专为long原生类型设计的空值容器，底层不装箱、无GC压力；仅在处理LongStream等原生数值流或需避免装箱时使用，不可与Optional<Long>混用或隐式转换。
OptionalLong 是什么，什么时候必须用它
它不是 Optional<Long> 的语法糖，而是专为 long 原生类型设计的空值容器，底层不装箱、不 GC 压力小。当你从 IntStream 以外的数值流（比如 LongStream）调用 findFirst()、max()、average() 这类可能无结果的操作时，返回的就是 OptionalLong，不是 Optional<Long>——混用会编译失败。
常见错误现象：long result = stream.max().orElse(0L) 看似合理，但如果 stream 是空的，stream.max() 返回的是 OptionalLong.empty()，而 orElse(0L) 没问题；但若误写成 stream.max().get()，运行时抛 NoSuchElementException。
- 只在处理
long原生流或明确需要避免装箱时用OptionalLong - 别试图用
new OptionalLong(...)—— 构造方法私有，只能靠OptionalLong.of(value)或OptionalLong.empty() - 和
Optional<Long>之间不能隐式转换，要转得显式调.getAsLong()或.mapToObj(Long::valueOf)
判断有没有值，别只用 isPresent()
isPresent() 能用，但容易漏掉“有值但值是 0L”这个合法场景。比如你查某个指标的最近一次上报时间戳（单位毫秒），结果是 0L 完全可能（Unix epoch 零点），这时 if (opt.isPresent()) { use(opt.getAsLong()); } 逻辑正确；但如果你写成 opt.orElse(0L) == 0L 来判断“是否为空”，就错了——它把真实值为 0 和空值全当成“空”。
- 安全判断存在性：优先用
if (opt.isPresent())，而不是靠值比较 - 想合并空/零逻辑？先明确业务：0 是有效值还是占位符？如果是后者，应改数据源，而不是在 Optional 层面 hack
- 链式处理推荐
ifPresent()或map()，避免反复调isPresent()+get()
orElse() 和 orElseGet() 的性能差别真不小
orElse(heavyComputation()) 无论 Optional 有没有值，都会执行 heavyComputation()；而 orElseGet(() -> heavyComputation()) 只在空时才调用 Supplier。这对日志、远程调用、对象构造等代价高的操作很关键。
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
- 常量或轻量值（如
0L、-1L）用orElse()更直白 - 含 I/O、计算、new 对象等逻辑，必须用
orElseGet() -
orElseThrow()接的是 Supplier<Throwable>，不是异常实例，别写成orElseThrow(new RuntimeException())（编译不过）
和传统 null 处理比，它没解决所有问题
OptionalLong 把“空”显式化了，但没消除空指针风险——比如你把它存进 Map<String, OptionalLong>，然后 map.get("key").ifPresent(...)，如果 key 不存在，map.get() 返回 null，直接 NPE。它只管自己这一层，不管上游怎么来的。
- 别把
OptionalLong当万能 null 替代品：方法参数、字段、返回值设计阶段就要决定要不要暴露可空性 - 作为方法返回值合理；作为参数传入（尤其 public API）反而增加调用方负担，多数情况不如直接返回
long并约定特殊值（如 -1）或抛异常 - 和 Jackson / Gson 序列化配合需额外配置，否则默认不支持，会报
Cannot construct instance of java.util.OptionalLong
最常被忽略的一点：它不可序列化（没有实现 Serializable），放进 Redis 缓存或跨 JVM 传输前，得先转成 Long 或自定义包装类。
