ArrayList不能直接add(123)是因为编译器根据泛型声明进行静态类型检查，add(Object)虽经类型擦除，但编译器拦截int向String等不兼容类型的赋值，确保类型安全仅在编译期生效。
为什么 ArrayList 不能直接 add(123)？
Java 泛型在编译期做类型检查，ArrayList<string></string> 的 add() 方法签名实际被擦除为 add(Object)，但编译器会拦截不匹配的字面量或变量——比如你写 list.add(123)，编译器立刻报错：「incompatible types: int cannot be converted to String」。这不是运行时保护，而是编译器根据泛型声明做的静态校验。
注意：这种检查只对明确类型起作用。如果用反射、原始类型（raw type）或泛型通配符绕过，仍可能插入非法对象。
- 别把
ArrayList声明为原始类型：ArrayList list = new ArrayList();—— 这会关闭所有泛型检查 - 避免用
Object强转绕过：比如((ArrayList) list).add(123)，编译通过但破坏类型契约 - 泛型不保留运行时信息，所以
list.getClass() == ArrayList.class，无法靠instanceof检查泛型参数
如何让自定义集合类支持泛型安全？
写一个泛型容器类，关键是在类声明和方法签名中正确使用类型参数。例如实现一个简单泛型栈：
public class GenericStack<T> {
private final List<T> data = new ArrayList<>();
<pre class="brush:php;toolbar:false;">public void push(T item) { // 编译器据此推断入参必须是 T 类型
data.add(item);
}
public T pop() {
if (data.isEmpty()) throw new EmptyStackException();
return data.remove(data.size() - 1); // 返回值自动适配为 T
}}
立即学习“Java免费学习笔记（深入）”；
这样调用时：GenericStack<integer> stack = new GenericStack();</integer>，stack.push("abc") 就会编译失败。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 构造器里不要写
new T[10]—— 类型擦除后无法实例化泛型数组，改用new Object[10]+ 显式转型（并加@SuppressWarnings("unchecked")） - 静态方法若需泛型，必须独立声明类型参数：
public static <u> U getFirst(List<u> list)</u></u>，不能复用类级别的T - 泛型类不能继承
Throwable，也不能是异常类型本身（Java 语法限制）
泛型通配符怎么避免「add 失败但 get 安全」的困惑？
常见陷阱：声明 List extends Number> list = new ArrayList<integer>();</integer> 后，list.add(3.14) 报错，但 Number n = list.get(0) 却合法。这是因为 ? extends Number 表示“某个未知的 Number 子类”，编译器无法确认你 add 的具体是哪个子类，所以禁止写；但读出来一定是 Number 或其子类，向上转型安全。
- 需要「只读」场景用
? extends T（PECS 中的 “Producer”） - 需要「只写」场景用
? super T（如往List super Integer>里 addInteger或Long都可以） - 完全不确定时，宁可用
List<object></object>而非List>，后者连add(null)都受限（虽语法允许，但语义模糊）
泛型与集合方法重载冲突的真实案例
当你在一个泛型类里同时定义 void process(List<string> list)</string> 和 void process(List<integer> list)</integer>，编译失败：「method is already defined」。因为类型擦除后两者都是 process(List)，JVM 无法区分。
解决办法只有两个：
- 改名，比如
processStrings(List<string>)</string>和processNumbers(List<integer>)</integer> - 用不同参数数量或非泛型参数打破重载歧义，例如加一个
boolean flag
这个限制常被忽略，尤其在封装工具类时——看似合理的重载，一编译就报错，根源就是泛型擦除抹平了类型差异。
真正难的不是写对泛型语法，而是理解它在哪一刻「消失」、在哪一刻「生效」。类型安全只存在于编译期，而运行时的集合依旧裸奔。
