泛型约束是类型安全的必要前提，new()必须置于where子句末尾且需显式声明；基类约束必须最前；class/struct互斥；多重约束需逻辑自洽，否则编译报错。
泛型约束不是可选项，而是类型安全的必要前提；不加约束的 T 在编译期几乎无法做任何有意义的操作。
为什么 new T() 会报错：CS0304
当你在泛型类里直接写 new T()，编译器立刻报错 CS0304: Cannot create an instance of the variable type 'T' because it does not have the new() constraint。这不是语法错误，而是编译器在告诉你：它无法保证 T 能被实例化。
常见错误现象：
- 明明传入的是普通类，却仍报 CS0304
- 结构体（
struct）能用new T()，但加上where T : class后反而不能用了 - 写了
new()却仍报错——因为new()必须放在where子句末尾，且不能前置
正确写法必须显式声明约束：
public class Factory<t> where T : new()
{
public T Create() => new T(); // ✅ 编译通过
}</t>
注意：new() 约束本身不区分值/引用类型，但若同时要求 class 或 struct，则需组合使用，且 new() 永远在最后：
-
where T : class, new()—— 引用类型 + 无参构造函数 -
where T : struct, new()—— 值类型 + 默认构造函数（结构体天然满足） -
where T : ICloneable, new()—— 接口 + 可实例化（用于工厂返回克隆对象）
where T : BaseClass 为什么必须放最前
基类约束（如 where T : Exception）是唯一强制要求位置的约束类型：它必须出现在 where 子句中该类型参数的所有其他约束之前。
否则编译器报错 CS0453: The type 'T' must be a non-nullable value type... 或更模糊的“约束顺序错误”提示，实际就是位置违规。
原因在于：编译器需要先确认 T 的继承链起点，才能判断后续接口、构造函数等约束是否逻辑自洽。比如 where T : IDisposable, new(), Exception 是非法的，因为 Exception 是类，而 IDisposable 是接口，new() 是构造约束——三者层级不同，必须分层声明。
正确顺序示例：
public class SafeLogger<t> where T : Exception, IDisposable, new()
{
public void Log(T ex) { /* ... */ }
}</t>
关键点：
-
Object、Array、ValueType不能作为基类约束（编译器直接拒绝） -
System.Enum、System.Delegate、System.MulticastDelegate是特例，允许作基类约束 - 在可为 null 的上下文中，
where T : Exception意味着T必须是非空引用类型；若要允许Exception?，得写成where T : Exception?
class 和 struct 约束的实际影响
where T : class 不只是“限制为引用类型”，它还隐含了 T 不能是 null（在启用 nullable context 下），除非你显式写成 where T : class?。
而 where T : struct 表示 T 必须是值类型，但注意：Nullable<t></t>（即 T?）不满足此约束——int? 是引用类型包装，不是真正的值类型。
典型误用场景：
- 想让泛型方法接受
string和int，结果发现无法用同一个where同时覆盖两者（class和struct互斥） - 对
where T : struct类型调用.ToString()安全，但调用.GetHashCode()时若未重写，可能触发装箱 -
where T : notnull是独立约束，它允许int、string、MyClass，但拒绝string?、MyClass?；违反时只发警告，不报错
性能提示：使用 struct 约束时，若泛型方法内频繁调用虚方法（如 ToString()），JIT 可能无法完全内联，实际性能未必优于非泛型版本。
多重约束组合时的常见陷阱
多个约束叠加看似灵活，但容易忽略隐含冲突。例如：
-
where T : class, new(), IComparable—— 合法，但所有约束都必须被实参满足 -
where T : Stream, new()—— 非法，因为Stream是抽象类，无法实例化，new()约束必然失败 -
where T : IDisposable, new()—— 合法，但只有实现了IDisposable且有 public 无参构造函数的具体类才可用（如FileStream不行，StringWriter可以）
最容易被忽略的一点：约束是编译期检查，不提供运行时类型信息。即使你写了 where T : IFormattable，也无法在运行时靠 typeof(T).GetInterfaces() 动态验证——编译器只确保调用 ToString(string) 是合法的，其余全靠你手写逻辑。
另一个坑：where T : U（类型参数作为约束）要求 U 本身也受约束，且必须在泛型声明中先于 T 出现：
public class Mapper<tsource tdest> where TSource : class where TDest : TSource // ✅ 合法
{
public TDest Map(TSource src) => (TDest)(object)src;
}</tsource>
这种写法虽能编译，但强制转换依赖运行时类型兼容性，实际风险很高——约束只保“子类关系”，不保“可转换性”。
