泛型是编译期类型契约而非语法糖，应在逻辑相同但数据类型不同的场景定义泛型类，优先使用泛型方法；需合理约束T，避免过度约束与擦除陷阱，并正确运用协变/逆变。
泛型不是语法糖，是编译期类型契约——用错地方反而会削弱类型安全，而不是增强。
泛型类该在什么场景下定义
当你有一组逻辑完全相同、仅操作的数据类型不同的类时，才值得抽成泛型类。比如 Stack<T>、Repository<TEntity>，而不是为了“看起来高级”把所有类都泛型化。
- 必须能通过
T约束行为：比如where T : class或where T : IComparable<T>，否则运行时可能抛InvalidCastException - 避免过度约束：像
where T : new(), IDisposable, ICloneable会让调用方难以实现，实际使用率极低 - 字段/属性/构造函数参数中多次出现同一类型占位符，才是泛型类的信号；如果只在返回值里用了一次
T，大概率该用泛型方法
泛型方法比泛型类更常用也更安全
多数类型复用需求其实落在单个操作上，比如转换、查找、映射。这时定义泛型方法比泛型类更轻量、更易推导、更少出错。
-
public static T ParseJson<T>(string json)比JsonParser<T>类更合理——你不需要维护状态，也不需要实例化 - 编译器常能自动推导类型：调用
ParseJson("{...}")时，如果变量已声明为User user = ...，部分语言（如 C#）可省略<User> - 注意：泛型方法不能被虚重写（virtual override），若需多态行为，得靠接口 + 泛型约束，比如
void Process<T>(T item) where T : IProcessable
泛型擦除与装箱陷阱（Java / Kotlin 尤其要注意）
Java 的类型擦除会让 List<String> 和 List<Integer> 在运行时都是 List，导致无法做 instanceof 判断，也无法获取 T.class。
- 不能写
if (list instanceof List<String>)—— 编译不通过 - 反射获取泛型实际类型要用
ParameterizedType，且仅对字段/方法签名有效，对局部变量无效 - Kotlin 的
reified只在内联函数中生效：inline fun <reified T> parse(): T，但会增加字节码体积，别滥用 - C# 没有擦除，但要注意值类型泛型实例化会产生独立副本，
List<int>和List<long>是完全不同的运行时类型
泛型与协变/逆变容易被忽略的边界
声明 IEnumerable<out T> 是协变，允许 IEnumerable<Dog> 赋给 IEnumerable<Animal>；但 IList<in T> 是逆变，只适用于输入场景（如参数），不能用于返回值。
- 只有接口和委托支持
in/out，类不支持 -
out T要求T只出现在输出位置（返回值、get 访问器、委托参数的返回类型） -
in T要求T只出现在输入位置（方法参数、set 访问器、委托参数类型） - 违反规则会导致编译错误，但错误信息往往不直观，比如 “cannot convert from X to Y” 而不是提示协变问题
真正难的不是写对泛型语法，而是判断某个抽象是否该由泛型承载——它得同时满足：类型差异真实存在、编译期可约束、且约束不会成为调用方的负担。
