咱们先来聊聊一个让不少 Java 开发者感到困惑的细节：为什么不能直接写 List 这种多重上界通配符？说到底，根本原因其实就一条——**通配符本身不支持联合类型（intersection type）的语法表达，而且 Java 泛型通配符的设计从一开始就只允许单一上界或下界**。
听起来有点绕对不对？其实核心就一句话：通配符的语法限制是硬性规则，没有商量余地。
语法层面的硬性约束
Java 语言规范写得很清楚，通配符的上界形式只能是 ? extends Type，而这里的 Type 必须是一个**单一、可命名的引用类型**，比如一个类或一个接口，绝不可能是多个类型的交集。
这里有个很有趣的对比：Java 在泛型类型参数中确实支持多重边界，比如
? extends A & B非法，是因为 ? 没有名字、不可推导。编译器在编译期根本无法确认“某个未知类型”是不是真的同时实现了 A 和 B——这在类型检查阶段既不可判定，也缺乏安全语义的支撑。
换句话说，通配符 ? 是一个“未知具体类型”的占位符，它没有类型参数名，也就无法绑定多个约束条件。这是 Java 语言设计者有意为之的取舍。
类型系统不支持通配符的联合推理
再来看看类型系统层面的原因。通配符的核心语义是“只读安全”，也就是大家熟知的 PECS 原则（Producer Extends, Consumer Super）。它的安全性依赖于编译器能**静态保证**所有可读出的元素都属于某一个确定的公共超类型。
如果允许 ? extends A & B，编译器就必须确保两件事：
- 实际容器的元素类型既是 A 的子类型，又是 B 的子类型。
- 从该列表中 get() 出来的对象，既能当 A 用，也能当 B 用。
这个双重承诺听起来很美好，但问题在于 Java 的类型擦除机制和运行时类型信息缺失，使得这种双重约束无法在不引入运行时检查的前提下静态验证。而 Java 泛型设计的一条铁律是：**所有类型安全必须在编译期闭环，绝不妥协**。
所以，这不是 Java 的疏漏，而是一个经过深思熟虑的设计决策：通配符专注解决“协变读取”的简单场景，复杂类型关系交给类型变量和接口继承来承担。
替代方案：用带多重边界的类型变量代替
如果你确实需要“既是 A 又是 B”的能力，正确的做法是避开通配符，改用泛型方法或类，并显式声明类型变量：
void process(List list) { A a = list.get(0); // ✅ 安全 B b = list.get(0); // ✅ 安全 }
另一个更优雅的方式是提前用接口组合来定义契约：
interface AAndB extends A, B {}
List list; // ✅ 合法，因为 AAndB 是一个单一接口类型
这种方式把“多重约束”收束为一个可命名、可继承的接口，巧妙绕过了通配符的语法限制，同时保持了类型安全。本质上，它把编译器无法直接验证的“交集关系”，转化成了可以通过继承链明确追溯的“单一类型关系”。
`">
所以，说到底，这不是 Java 的 Bug，而是特性。理解了这个设计取舍，以后遇到类似场景，就知道该用哪种方式去绕开这个限制了。
