Optional不能接受上界通配符类型参数，因其构造方法要求明确泛型类型T，泛型擦除后无法确定实际承载类型，编译器直接报错；正确用法是基于明确类型的Optional<T>，通过map、flatMap、filter等方法安全链式操作。
Java 中 Optional<? extends T> 这种写法不合法，也不能用于转换或映射处理。它不是 Optional 的正确用法，也不具备实际运行能力。
为什么 Optional 不能接受上界通配符类型参数
Optional 是一个具体容器类，其构造方法（如 of()、ofNullable()）要求传入明确的泛型类型 T，而非通配符类型。JVM 泛型擦除后，Optional<? extends User> 无法确定实际承载类型，编译器会直接报错：
Optional<? extends User> opt = Optional.ofNullable(user); // 编译失败- 泛型声明只允许具体类型或无界通配符（如
Optional<?>），但后者失去类型信息，无法安全调用map或get - 源码中
EMPTY是Optional<?>，仅用于内部单例复用，对外 API 不暴露通配符签名
真正可用的 Optional 映射与转换机制
所有安全、可链式调用的映射操作，都基于 明确类型的 Optional<T>，依赖以下核心方法协作：
-
map(Function<? super T, ? extends U>)：对非空值做转换，空值自动跳过，返回Optional<U> -
flatMap(Function<? super T, Optional<U>>)：适用于“返回 Optional 的函数”，避免嵌套Optional<Optional<U>> -
filter(Predicate<? super T>)：按条件保留或清空，不满足则变为空 Optional - 所有操作均在
Optional<User>、Optional<Order>等具名类型上进行，类型推导清晰、IDE 可提示、编译期可校验
常见误用与对应正解
开发者有时试图用通配符“放宽类型限制”，但实际破坏了 Optional 的契约和安全性：
立即学习“Java免费学习笔记（深入）”；
- ❌
void handle(Optional<? extends Product> p)→ 调用方仍可传Optional.empty()，且无法约束子类型业务含义 - ✅ 正确做法：方法签名固定为
Optional<Product>，子类逻辑由业务代码判断（如if (p.filter(p -> p instanceof DigitalProduct).isPresent())） - ❌
List<Optional<? extends Item>>.stream().map(Optional::get)→ 绕过空值防护，NPE 风险重现 - ✅ 正确做法：统一用
map或flatMap处理，或先filter(Optional::isPresent)再提取
替代协变需求的合理方案
若需类似“协变读取”的灵活性（比如统一处理多种子类型 Optional），应通过以下方式实现，而非通配符：
- 定义公共父类型接口或抽象类，让各子类继承，然后使用
Optional<Parent> - 用
instanceof+map分支处理：opt.map(p -> p instanceof A ? ((A)p).toX() : ((B)p).toY()) - 借助 Visitor 模式或策略工厂，把类型分发逻辑从 Optional 容器中解耦出来
- 必要时封装工具方法：
<R> Optional<R> safeMap(Optional<?> opt, Function<Object, R> mapper)，但需自行承担类型安全责任
