? extends t不能add元素因编译器仅知元素为t或其子类，具体类型不确定，add会破坏类型安全；应仅用于读取，写入需改用? super t或具体类型。
为什么 ? extends T 不能往里 add 元素
因为编译器只知道容器里是 T 或它的某个子类，但具体是哪个子类完全不确定。比如 List extends Number> 可能是 List<integer></integer>，也可能是 List<double></double>，甚至 List<biginteger></biginteger>——你往里 add(new Integer(1))，对后者就直接破坏类型安全。
实操建议：
- 只用
? extends T做「读取」场景：遍历、取值、传给只消费T的方法 - 别试图绕过编译：强制转型或反射写入，等于把类型检查推迟到运行时，出错更难定位
- 如果真要写入，改用
? super T或明确泛型类型，比如List<number></number>
? super T 为什么适合做消费者但不适合取值
它表示“至少是 T 的父类”，所以你可以安全地 add(new T())，因为所有父类都接受子类实例；但取出来只能当 Object 用——比如 List super Integer> 可能是 List<number></number> 或 List<object></object>，你无法保证 get(0) 是 Integer。
典型使用场景：
立即学习“Java免费学习笔记（深入）”；
-
Collection super T> target作为收集结果的参数（如Collections.copy()的 destination） - 回调中接收数据，且后续只做通用处理（如日志、序列化、丢进队列）
- 避免为了适配而频繁新建中间集合，减少 GC 压力
生产代码里什么时候该放弃通配符，老老实实用具体类型
通配符不是银弹。当你需要同时读和写，或者类型关系复杂（比如嵌套泛型、多个边界交叉），硬套 ? extends/? super 会让逻辑变晦涩、IDE 提示变弱、维护成本陡增。
常见信号：
- 方法签名里出现多个通配符，还互相约束（如
<t> void foo(List extends T> src, List super T> dst)</t>）→ 直接上泛型方法<t> void foo(List<t> src, List<t> dst)</t></t></t> - 业务对象本身有明确继承结构，且调用方总是知道具体子类（如
PaymentProcessor<alipayrequest></alipayrequest>）→ 别用PaymentProcessor extends PaymentRequest> - 性能敏感路径（如高频日志聚合、实时风控）→ 通配符擦除后仍需类型检查，不如具体类型零开销
PECS 原则在真实接口设计中的落地难点
《Effective Java》说“Producer Extends, Consumer Super”，听起来干净，但现实里很多类既是生产者又是消费者。比如一个缓存服务，get() 是 producer，put() 是 consumer，没法用同一个通配符覆盖。
这时候得拆开看：
- API 方法粒度决定通配符：单独的
readAll() : List extends Result>和writeAll(Collection super Result>)各自合理 - 不要强求整个类泛型参数用通配符：类定义用
<t></t>，方法再按需放宽（如<u extends t> void accept(U item)</u>） - 团队协作时，过度使用通配符会提高阅读门槛——尤其对 junior 工程师，看到
List super Serializable>第一反应常是懵，而不是立刻理解意图
真正容易被忽略的，是通配符带来的“隐式契约”：它不报错，但悄悄限制了你能写的代码范围。上线后加个新字段、换种调用方式，可能就卡在某个 add 上动不了——不是语法错，是编译器在替你守住边界。
