应避免将 Optional 塞入集合，因其非为此设计；正确做法是在数据入集前过滤 null，如用 stream().filter(Objects::nonNull) 或 removeIf(Objects::isNull)，确保集合仅含有效值。
别把 Optional 塞进集合里——它不是为这个设计的。集合中出现 null 元素，真正要解决的是数据入集前的清理问题，而不是用 Optional 包一层再绕着走。
为什么 List> 是个坏主意
很多人试图用 List<optional>></optional> 来“防护”可能为 null 的元素，结果代码变得臃肿难读：遍历时得反复调用 opt.isPresent() 和 opt.get()，还容易漏判；Optional 本身不可序列化、不重写 equals/hashCode，放进集合会增加内存开销、破坏语义一致性；更关键的是，这违背了 Optional 的设计本意——它专用于方法返回值，用来声明“这个结果可能没有”，而不是充当集合元素的“防弹衣”。
真正该做的：在数据进入集合前就过滤 null
让集合本身只装有效值，是最干净、最高效的做法：
- 上游是流式数据（如数据库查询、API 响应）？优先在源头加非空约束，比如 SQL 中写
WHERE field IS NOT NULL，或接口层做校验 - 已有含 null 的 List？用
stream().filter(Objects::nonNull)一行清洗：list = list.stream().filter(Objects::nonNull).collect(Collectors.toList()); - 注意：别写
filter(x -> x != null)，虽然等价，但Objects::nonNull更明确，还能避开部分 IDE 的空值警告误报 - 如果后续还要往结果里
add()，建议显式构造新 ArrayList：new ArrayList(list.stream().filter(Objects::nonNull).collect(Collectors.toList()))，避免 JDK 16+ 后Collectors.toList()返回不可变紧凑列表导致运行时报错
大数据量时，原地清理更省资源
当集合规模达百万级、且允许修改原集合时，removeIf(Objects::isNull) 比流式过滤更优：
- 它直接操作原集合，不创建中间 Stream 或临时容器，GC 压力小，实测快 20%~40%
- 写法极简：
list.removeIf(Objects::isNull); - 但要注意副作用：原始引用内容被修改，若其他逻辑依赖旧状态，需先拷贝：
new ArrayList(originalList) - 不支持所有集合类型——
Arrays.asList()返回的集合调用它会抛UnsupportedOperationException - 并发场景下禁止使用，无线程安全保证
特殊情况：上游返回的是 Optional>
这是另一类常见场景——比如 DAO 方法返回 Optional<list>></list>。这时要区分三层语义：
- Optional 为空 → 查询无结果（如 ID 不存在）
- Optional 非空但 List 为空 → 查询有结果，但没匹配到数据（如 status=‘DRAFT’ 的订单为零）
- List 有元素 → 正常业务数据
- 推荐处理方式：
optionalList.filter(list -> !list.isEmpty()).orElse(defaultList)，简洁且语义清晰 - 避免连环判空：
if (optionalList.isPresent() && optionalList.get() != null && !optionalList.get().isEmpty())—— 这种写法既冗长又易出错
核心就一条：null 不该在集合里“潜伏”，而应在它落进集合前就被识别、拦截或转换。Optional 是信号灯，不是保险柜。
