java泛型通配符本质是编译期约束性类型推导机制，基于类型擦除实现读写权限控制：?表示未知确定类型，? extends t允许安全读取为t但禁止写入，? super t允许写入t及其子类但读取仅限object。
Java 泛型通配符的底层原理，本质是编译器在类型擦除框架下，为增强泛型灵活性而设计的一套**约束性类型推导机制**。它不改变运行时行为，只在编译期施加更精细的读写权限控制。
通配符不是真实类型，而是编译期“类型契约”
Java 中的 ?、? extends T、? super T 都不是 JVM 认识的类型，字节码里根本不存在。它们只是编译器用来和开发者“约定规则”的语法标记：
- ? 表示“某个未知但确定的类型”，编译器禁止任何具体类型写入（null 除外），读取时只能当作 Object；
- ? extends T 表示“T 或其任意子类”，编译器允许安全读取为 T（因所有子类都能向上转型），但禁止写入（除 null），否则可能破坏容器原有类型一致性；
- ? super T 表示“T 或其任意父类”，编译器允许写入 T 及其子类（因子类可赋值给父类引用），但读取时只能当 Object（因无法确定具体是哪个父类）。
类型擦除决定了通配符必须“静态限定”
由于泛型信息在运行时被擦除，JVM 看不到 List extends Number> 和 List
- 编译器会为每个通配符表达式生成一组隐式类型边界检查，比如调用 list.add(x) 时，会比对 x 的实际类型是否满足 ? super Integer 的下界约束；
- 读取操作如 for (Number n : list) 中，编译器根据 ? extends Number 推出 n 可安全声明为 Number，自动插入必要的 checkcast 指令；
- 一旦违反规则（如向 ? extends String 的列表 add(new Object())），编译器直接报错，不生成字节码。
PECS 原则是对擦除限制的工程化解法
因为擦除后无法在运行时判断“这个 ? 到底是 String 还是 Object”，所以 Java 不提供动态类型适配。PECS（Producer Extends, Consumer Super）正是针对这一硬约束提出的实践准则：
- 当你只从集合取数据（Producer），用 ? extends T —— 安全读取，靠上界保障返回值类型兼容；
- 当你只往集合放数据（Consumer），用 ? super T —— 安全写入，靠下界保障参数可被接受；
- 如果既读又写，通常不该用通配符，而该用具体泛型类型（如 List
）或重新设计接口。
反射中看不到通配符，也印证其纯编译期属性
通过反射获取 List extends Runnable> 的泛型信息，你拿到的是 ParameterizedType，其实际类型参数是带有 TypeVariable 或 WildcardType 的抽象节点，但运行时调用 getClass() 仍返回 ArrayList.class —— 通配符不参与实例化，也不影响对象布局或方法分派。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
