泛型类与方法提升代码安全复用技巧

泛型并非炫技的语法糖，而是编译期严格的类型契约，其核心价值在于安全、精准地复用逻辑——只有当多组类或方法行为完全一致、仅数据类型不同时，才应引入泛型；优先选用泛型方法而非泛型类，合理使用约束（如 where T : IComparable）避免过度限制，警惕Java/Kotlin的类型擦除陷阱与C#的值类型实例化开销，并深入理解协变（out）与逆变（in）在接口中的精妙边界；真正考验功力的，是从需求本质判断“是否值得泛型化”：类型差异必须真实、约束必须可静态验证、且不能给使用者徒增负担。

泛型不是语法糖，是编译期类型契约——用错地方反而会削弱类型安全，而不是增强。

泛型类该在什么场景下定义

当你有一组逻辑完全相同、仅操作的数据类型不同的类时，才值得抽成泛型类。比如 Stack、Repository，而不是为了“看起来高级”把所有类都泛型化。

• 必须能通过 T 约束行为：比如 where T : class 或 where T : IComparable，否则运行时可能抛 InvalidCastException
• 避免过度约束：像 where T : new(), IDisposable, ICloneable 会让调用方难以实现，实际使用率极低
• 字段/属性/构造函数参数中多次出现同一类型占位符，才是泛型类的信号；如果只在返回值里用了一次 T，大概率该用泛型方法

泛型方法比泛型类更常用也更安全

多数类型复用需求其实落在单个操作上，比如转换、查找、映射。这时定义泛型方法比泛型类更轻量、更易推导、更少出错。

• public static T ParseJson(string json) 比 JsonParser 类更合理——你不需要维护状态，也不需要实例化
• 编译器常能自动推导类型：调用 ParseJson("{...}") 时，如果变量已声明为 User user = ...，部分语言（如 C#）可省略
• 注意：泛型方法不能被虚重写（virtual override），若需多态行为，得靠接口 + 泛型约束，比如 void Process(T item) where T : IProcessable

泛型擦除与装箱陷阱（Java / Kotlin 尤其要注意）

Java 的类型擦除会让 List 和 List 在运行时都是 List，导致无法做 instanceof 判断，也无法获取 T.class。

• 不能写 if (list instanceof List) —— 编译不通过
• 反射获取泛型实际类型要用 ParameterizedType，且仅对字段/方法签名有效，对局部变量无效
• Kotlin 的 reified 只在内联函数中生效：inline fun parse(): T，但会增加字节码体积，别滥用
• C# 没有擦除，但要注意值类型泛型实例化会产生独立副本，List 和 List 是完全不同的运行时类型

泛型与协变/逆变容易被忽略的边界

声明 IEnumerable 是协变，允许 IEnumerable 赋给 IEnumerable；但 IList 是逆变，只适用于输入场景（如参数），不能用于返回值。

• 只有接口和委托支持 in/out，类不支持
• out T 要求 T 只出现在输出位置（返回值、get 访问器、委托参数的返回类型）
• in T 要求 T 只出现在输入位置（方法参数、set 访问器、委托参数类型）
• 违反规则会导致编译错误，但错误信息往往不直观，比如 “cannot convert from X to Y” 而不是提示协变问题

真正难的不是写对泛型语法，而是判断某个抽象是否该由泛型承载——它得同时满足：类型差异真实存在、编译期可约束、且约束不会成为调用方的负担。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~