泛型不是语法糖，而是编译期类型契约；E表元素、T表通用类型、K/V表键值对，类型擦除是为兼容JVM做的权衡。
泛型不是语法糖，而是编译期的类型契约。它让容器、工具类和接口能“声明自己支持什么类型”，而不是靠运行时强转硬扛——E、T、K、V 就是这套契约里最常用的“角色代号”，而类型擦除则是 Java 为兼容老 JVM 做出的关键妥协。
E 是集合里的元素（Element）
当你看到 List<E> 或 Set<E>，E 不是随便写的字母，它明确告诉阅读者：“这个集合装的是一个个独立的元素”。JDK 源码里全这么用，比如：
-
boolean add(E e)—— 加一个元素 -
E get(int index)—— 取一个元素
用 E 而不用 T，是为了语义清晰：List 不是“任意类型容器”，而是“元素序列”。你写 List<String>，E 就是 String；换成 List<Order>，E 自动变成 Order —— 编译器全程帮你检查，不会混入其他类型。
T 是通用类型占位符（Type）
T 是泛型世界的“默认主角”，没有限定场景，哪儿需要类型参数就往哪儿放。它常见于：
- 自定义通用类：
class Result<T> { private T data; } - 泛型方法：
<T> T findFirst(List<T> list) - 工具类：
class BeanCopier<T>表示“能拷贝任意类型的 bean”
T 的本质是“等你填空”：声明时不指定具体类型，使用时才绑定，比如 Result<User> 中的 T 就锁定为 User，之后所有涉及 T 的地方都按 User 处理。
K 和 V 是键值对的左右手（Key / Value）
Map 类型天生成对出现，K 和 V 就是专为这种结构设计的搭档：
- K 出现在
put(K key, V value)、get(Object key)等方法签名中，代表键的类型 - V 出现在返回值和参数里，代表值的类型
- 例如
Map<Integer, String>：K 是 Integer，V 是 String
分开命名 K/V 而不共用一个 T，是因为 Map 的两个位置逻辑不同——键要能比较、要唯一，值则侧重承载数据。强行统一反而模糊职责。
类型擦除是向后兼容的必然选择
Java 5 引入泛型时，JVM 已经运行了近十年。为了不让已有字节码失效、不强制所有库重编译，Java 采用“类型擦除”：泛型只在编译期存在，到字节码阶段全部抹掉，替换成上界（通常是 Object）。
-
Box<String>编译后变成Box，内部字段是Object value - 所有泛型方法调用都被插入隐式强转，比如
box.get()实际是(String) box.get()
代价是运行时无法获取泛型真实类型（比如不能写 if (list instanceof List<String>)），但换来的是零成本升级——老代码照跑，新代码更安全。
泛型不是炫技，它是把类型约束从“靠人盯”变成“靠编译器管”。E、T、K、V 是约定，不是规则；擦除不是缺陷，而是权衡。写清楚意图，编译器自然帮你守住边界。
