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