本文对比 java 的使用点方差（wildcards）与 scala 的声明点方差，指出对于单职责接口（如 function），java 的通配符机制是冗余且易错的；而真正需要灵活方差控制的，是像 list 这样多用途、读写混合的复杂类型——但这类设计在现代函数式与面向对象实践中已逐渐被淘汰。
Java 的泛型系统采用使用点方差（use-site variance），即通过 ? extends T 或 ? super T 在方法签名中临时指定类型参数的方差行为。例如，Stream.map() 的声明：
<R> Stream<R> map(Function<? super T, ? extends R> mapper);
此处 ? super T 表达了输入类型的逆变性（子类可替代父类作为入参），? extends R 表达了返回类型的协变性（子类结果可安全视为父类结果）。这看似灵活，实则将本应由类型自身语义承载的方差契约，转移到每一次调用的语法细节中。
以 Function<T, R> 为例：其唯一抽象方法 R apply(T t) 决定了 T 必然处于逆变位置（接受更宽泛的输入），R 必然处于协变位置（返回更具体的值）。因此，任何合法使用 Function 的场景，都天然要求 T 逆变、R 协变。Java 却仍允许用户写出 Function<String, Number> 并传入 Function<Object, Integer>——这在类型安全上虽无问题，但若强制要求每次调用都显式书写 ? super String 和 ? extends Number，就变成了重复、易漏、难以维护的样板代码。
真正体现使用点方差“合理性”的，是像 List<E> 这样的历史遗留泛型类型。它同时包含协变操作（E get(int)）和逆变操作（void add(E e)），导致 E 必须为不变（invariant）——即 List<String> 不能赋值给 List<Object>，反之亦然。此时，通配符提供了实用的窄化能力：
立即学习“Java免费学习笔记（深入）”；
- List<? extends Number>：只读视图，可安全接收 List<Integer> 或 List<Double>，支持 get()，禁止 add()；
- List<? super Integer>：只写视图，可安全接收 List<Number> 或 List<Object>，支持 add(Integer)，但 get() 返回 Object，无法安全转为 Integer。
这种“按需投影接口”的思路，在 Java 5 引入泛型时，是对已有庞大、粗粒度集合 API 的一种妥协性兼容方案。然而，这种设计与现代软件工程原则已明显脱节：
✅ SOLID 原则：今日推荐的是小而专注的接口（如 ReadOnlyList<E>、WritableList<E>），每个仅暴露单一职责的方法集；
✅ 不可变优先：List.of()、ImmutableList、Record 等使“只读”成为默认而非例外；
✅ 声明即契约：Scala 的 trait Function1[-T, +R] 或 trait Seq[+A] 将方差直接锚定在类型定义中，使用者无需记忆或推导每次调用的通配符规则——类型系统自动保障安全。
因此，结论并非“Java 方差机制更灵活”，而是：它曾为兼容旧设计而生，却在新范式下成为负担。对于新接口（如自定义函数式类型、事件处理器、转换器等），应优先采用声明点方差思维——即使 Java 语法不支持，也可通过命名与文档明确约束（如 Consumer<? super T> 作为字段类型），并借助静态分析工具（如 Error Prone）捕获误用。
简言之：通配符不是银弹，而是过渡时期的胶带；而真正的类型安全，来自清晰的接口划分与方差语义的早期绑定。
