泛型：把类型约束写进接口

泛型：先约定这里装什么

List<String> 表示按字符串使用的列表。取出元素时，不必先把它当成 Object，再到处强制转换；不少“放错类型”的问题也能提前在编译时发现。

泛型检查类型，不检查业务含义。 字符串即使类型正确，也不一定是合法邮箱，业务规则仍要另外检查。类型参数不能直接写 int，可以使用 Integer。

元素有父子关系，列表不一定有

Integer 是 Number 的子类，但 List<Integer> 不能直接当成 List<Number>。否则，别人就可能通过后一个入口放入 Double，破坏“这个列表只装整数”的约定。这就是这里所说的不变性。

需要更灵活的接口时，可以用通配符表示“具体类型还不知道，但范围已经约定好了”。

下面只是声明片段，用于对照写法，不是完整可运行程序：

List<String> names;
List<? extends Number> numbersToRead;
List<? super Integer> integersToWrite;

先画出数据往哪里走，再选写法

泛型方法可以用 T 这样的类型参数，把多个位置关联起来。例如，把一个“产生 T”的来源复制到一个“能够接收 T”的目标。

• 数据从哪里读出？
• 数据准备写到哪里？
• 这些位置是否必须保持同一个精确类型？

不要只背 extends 和 super 的口诀。 先说清数据流，再选择接口写法。T 这个名字本身没有特别的约束；真正起作用的是它在参数、返回值和边界之间建立的关系。

编译器会根据声明和传入的参数，检查这次调用的类型是否允许。从 extends 来源读取时，你不知道具体类型是不是 Integer，但知道它符合 Number 的要求，所以可以按 Number 使用。

super 目标的实际元素类型可能是 Integer、Number 或 Object，因此放入 Integer 在类型上是允许的；这并不保证容器本身支持修改。null 能赋给这些引用类型是特殊规则，不能据此认为其他任意值也能放进去。

编译时能区分 List<String> 和 List<Integer>，运行时却通常不能只看列表对象，就证明里面每项都是字符串或整数。为兼容旧代码，编译后的大多数类型参数会用上界或 Object 表示，这叫类型擦除；编译器还会补上需要的类型转换，并在必要时生成桥接方法，维持方法重写关系。

面对外部数据，可以先确认它是 List<?>，再逐项检查内容。需要创建 T 对象时，可以显式传入创建方法或 Class<T> 这类类型信息；不能直接写 new T，也不能据此认为所有泛型信息都恢复了。

原始类型和未经检查转换会绕开编译期保护，使错误延迟到后续读取时才暴露。警告的位置与最终 ClassCastException 位置可能不同，所以不应只在抛异常处继续增加强转。图将数据从来源流向目标，强调接口类型约束保护整条传递路径，反序列化等外部边界还需要运行时内容验证。

真实 Collections.copy 把目标声明为 List<? super T>，来源声明为 List<? extends T>，正好对应写入与读取。方法先比较两边 size，目标元素数量不足就失败。这里的目标容量不是关键，new ArrayList<>(100) 仍然 size 为零，不能因此作为已有一百个槽位的目标使用。

真实实现依据规模与 RandomAccess 标记选择按下标或迭代器复制。模型统一使用迭代器，保留替换现有元素的语义，省略阈值优化与分支。它与“把来源追加到目标末尾”的 copyInto 教学方法不同，两个方法即使通配符形状相似，也不能混淆行为契约。

目标列表的具体元素类型虽然未知，但至少能接收 T，所以 writer.set(value) 安全；来源给出的值能按 T 使用，所以可以写 T value。目标读出时只能保证是 Object，这不代表它只能保存 Object，而是调用者没有足够信息认定更具体类型。

泛型签名无法保证目标列表支持 set，也无法证明并发修改不会发生。不可修改列表仍可能在运行时拒绝替换，类型系统只处理它表达的类型关系。理解这一边界有助于避免把通过编译当成所有调用前提都成立；可修改性、尺寸与线程规则仍需 API 文档和测试。

给定两个按同一 Comparator 排序的来源列表，返回合并后的新列表，比较相等时先保留左侧元素。拒绝 null 参数、null 元素和无序输入，不修改来源。

归并不需要知道元素具体类，只需要一个能够比较 T 的比较器。来源只生产值，所以声明为 List<? extends T>；Comparator 消费两个 T，所以使用 Comparator<? super T>。结果由方法创建为 List<T>，把同一个类型变量贯穿读取、比较与返回，便能让编译器检查调用关系。

先验证两侧各自有序，再分别保存两个迭代器的当前元素。比较后把较小的一项追加到结果，并只推进对应一侧；相等时推进左侧，保证来自两侧的相等元素维持确定的稳定顺序。使用迭代器避免对 LinkedList 反复按下标读取而引入额外平方级成本。

当一侧耗尽，另一侧剩余部分已经有序，可以直接追加。null 元素在前面的验证阶段被拒绝，因此内部可以用 null 表示该侧已耗尽，不会与合法数据混淆。若将来允许 null 元素，这个状态表示必须改为额外布尔值或专门包装，不能只删除校验。

校验各扫描一次，归并每个元素只消费一次；通用情形还要乘入或累计比较器真实成本，不能忽略复杂字段比较。

公开泛型 API 应尽量使用能满足职责的最宽参数约束，让 Integer 来源可以安全流向 Number 结果等合理组合；返回类型则应尽量易用，避免把不必要的通配符复杂性推给调用者。类型变量只使用一次且不关联其它位置时，可能需要重新检查是否真有必要。

从 JSON、反射或数据库拿到外部数据时，写了 List<User> 不等于每个元素都已被检查。反序列化要提供正确类型信息，原始 Map 转成对象时也要逐项核对字段。未经检查的强转常让错误到很远的地方才出现，应先在接收位置验证，再交给内部算法使用。

泛型主要保护类型关系，不保护集合可修改性、排序前提、单位或事务一致性。一个 Comparator 也可能读取可变字段，导致同一对对象先后比较结果不同，破坏归并前提。应让比较规则稳定且无副作用，输入在计算期间保持不变，再讨论算法结果与性能。