泛型类需规范命名（如T、TKey）、合理约束（避免where T:class等宽松条件）、注意静态字段按闭合类型独立存在；泛型推断易在null、显式转换时失败；约束组合须无矛盾，性能上应避免装箱拆箱混用。
泛型类怎么写，参数命名有讲究
泛型类不是加个 T 就完事，命名直接影响可读性和 IDE 提示效果。C# 官方推荐用单个大写字母（如 T、TKey、TValue），而不是 MyType 这种模糊名。
-
T是最通用的占位符，适合简单场景；多个类型参数时，优先用语义化缩写，比如IList<TItem>比IList<T>更易懂 - 别在泛型约束里写太松的条件，比如
where T : class看似安全，但后续调用.ToString()仍可能空引用——不如明确加where T : notnull或具体基类 - 泛型类的静态字段是按闭合类型独立存在的，
Cache<string>和Cache<int>的静态变量互不干扰，这点常被误当成“全局缓存”用错
泛型方法怎么推断类型，什么时候会失败
编译器能自动推断 Where<TSource> 这类方法的类型，但一遇到显式转换或 null 就容易卡住。
- 调用
Parse<int>("123")没问题，但Parse("123")会报错：无法推断T—— 因为方法体没用到返回值类型参与推导 - 传
null给泛型参数时，如果没加where T : class或where T : struct，编译直接拒绝，不会等到运行时报NullReferenceException - 扩展方法泛型推断更脆弱，比如给
IEnumerable<T>写扩展，输入是new int?[1]，T会被推成int?，但如果你方法里写了default(T)，就得小心它是不是你想要的默认值
泛型约束写不对，编译错误信息很误导
常见错误不是语法错，而是约束组合矛盾，比如同时写 where T : class, new() 和 where T : struct，编译器报的错是“无法同时满足约束”，而不是指出哪条冲突。
-
where T : unmanaged比where T : struct更严格，它排除了DateTime、decimal这些托管结构体，但允许用在Span<T>场景 -
where T : IComparable看似合理，但int实现的是IComparable<int>，不是非泛型IComparable，所以实际要用where T : IComparable<T> - 自定义接口约束时，如果接口本身是泛型（如
IMapper<TIn, TOut>），约束必须写全：where T : IMapper<string, int>，不能只写where T : IMapper
性能陷阱：泛型实例化和装箱拆箱混用
泛型本意是避免装箱，但一旦泛型类型参数被当作 object 或 ValueType 使用，就立刻掉进坑里。
- 对
List<int>调用.ToArray()返回int[]，没问题；但若写成(object)list再转回List<int>，中间会触发装箱（虽然List<T>本身不装箱，但强制转型会） - 用
typeof(T)做运行时判断很常见，但它在 JIT 编译阶段才确定，高频调用会影响内联优化，尤其在循环里别这么干 - 值类型泛型（如
Stack<int>）比引用类型（如Stack<string>）生成的机器码更紧凑，但如果你泛型方法里频繁调用ToString()，而T又没约束为IFormattable，JIT 可能被迫插入装箱指令
泛型真正的复杂点不在语法，而在约束链的传递性——一个泛型方法调另一个泛型方法，约束是否自动继承？不一定。有时候你得手动补一层 where，不然编译器就沉默地拒绝推导。
