Java泛型不能直接创建T[]因类型擦除导致运行时无T信息，数组需具体组件类型，故new T[10]编译报错；强制转型可能引发ClassCastException；正确做法是用Array.newInstance或让调用方传入Class，优先使用ArrayList等泛型集合。
Java泛型为什么不能直接创建T[]
因为JVM的类型擦除机制，T在运行时不存在，而数组需要在创建时知道具体组件类型，否则会抛出Generic array creation编译错误。
常见错误现象：new T[10] 直接报错；用(T[]) new Object[10]看似能过编译，但可能在后续强转时触发ClassCastException（尤其当集合被传给其他泛型方法后）。
- 正确做法是用
Array.newInstance(componentType, length)配合Class<t></t>参数，例如：Arrays.copyOf(elements, newSize, clazz) - 更推荐绕开数组——优先用
ArrayList<t></t>等泛型集合，它们不依赖运行时类型信息 - 如果必须返回数组，让调用方传入
Class<t></t>（如toArray(T[] a)的惯用法），避免内部硬编码类型
Collection extends Number>能add什么？
什么也不能add（除了null）。这是逆变的典型约束：上界通配符只允许读取，不允许写入。
使用场景：当你只需要遍历、计算或消费元素（比如求和、打印），且希望接受ArrayList<integer></integer>、LinkedList<double></double>等任意Number子类型的集合时。
立即学习“Java免费学习笔记（深入）”；
-
add(42)→ 编译失败：编译器无法保证42属于该集合实际的底层类型（可能是Integer，也可能是BigDecimal） -
get(0)→ 返回Number，安全；你可以调用doubleValue()等父类方法 - 想同时读写？别用
extends，改用原始类型Collection<number></number>，或明确指定具体类型如Collection<integer></integer>
为什么List<string></string>不能赋值给List<object></object>？
因为泛型是不变的（invariant），哪怕String是的子类，<code>List<string></string>和List<object></object>之间也没有继承关系。
容易踩的坑：误以为“子类型元素 → 子类型容器”成立，结果写出类似processStrings((List<object>) stringList)</object>，导致运行时ClassCastException（比如往里面加了File对象，后续按String取就会崩）。
- 安全替代方案：用通配符
List extends Object>（等价于List>），只读可用 - 如果函数真正需要的是“能往里塞任意
Object”，那它本就不该接收List<string></string>，接口设计就有问题 - 协变仅适用于生产者（Producer）场景，比如
Collection extends T>；逆变适用于消费者（Consumer）场景，比如Collection super T>
Comparator super String>为什么比Comparator<string></string>更灵活？
因为? super String表示“能比较String及其父类的对象”，比如Comparator<charsequence></charsequence>或Comparator<object></object>都能传进来——这是PECS原则（Producer Extends, Consumer Super）里的“Consumer Super”。
使用场景：Collections.sort(List<string>, comparator)</string>这类方法声明为Comparator super T>，才能兼容更宽泛的比较器实现。
-
Comparator<string></string>只能比较两个String，但Comparator<charsequence></charsequence>可以比较"abc"和new StringBuilder("def") - 如果你自己写工具方法，接收比较逻辑时，优先用
super T>而非<t></t>，提升复用性 - 注意：不能反过来——
Comparator extends String>毫无意义，因为String是final类，没有子类
泛型的协变/逆变不是语法糖，而是类型系统对“读写权限”的显式建模。很多人卡在“为什么这里不能传进去”，其实是在忽略谁在消费这个引用、是否可能破坏类型契约。
