颜不糙先讲一件让我排查到凌晨的事。上周写一个内存缓存组件，内部有个泛型方法：
csharp复制public T GetOrAdd<T>(string key, Func<T> factory)
{
if (_cache.TryGetValue(key, out T? value))
return value;
return default;
}
编译能过，单测能过，上线后却出现一批诡异数据：缓存 miss 时，有的返回 0，有的返回 null，还有的直接把下游调用方的数据清空了。我在开发环境怎么都复现不出来，最后意识到问题不在缓存，而在我对“泛型约束和默认类型”的理解上。
这个标题听起来像教科书里的两个孤立概念，但实际踩过一次坑就会明白，约束决定了你能在类型参数 T 上执行什么操作，而默认值、默认类型边界则决定这个 T 在没有实际类型信息时到底会得到什么。两个概念一旦被拆开记忆，写出来的泛型 API 就容易出现“运行时才爆炸”的隐患。
这篇文章我想用多语言对比的方式，把泛型约束、默认类型参数、以及 default(T) / default / new() 这些容易被混为一谈的东西从头理一遍。适合正在写通用组件、缓存、仓储、注册中心这类代码的开发者，也适合读源码时看到一连串 where 约束就头大的人。
1. 约束的本质：它是在声明“我对 T 能做哪些假设”
泛型的初衷是让代码摆脱具体类型，但自由是有代价的。当你写了个 T，编译器并不知道 T 到底长什么样，因此它不敢让你调用任何 T 上特有的方法。这不是编译器在给你设障碍，而是在避免一个致命风险：如果调用方传入一个没有该方法的类型，程序可能运行时崩溃。
1.1 没有约束时，T 其实是一个“毫无能力”的不透明类型
C# 里一个完全不加约束的 T，你只能使用所有对象都有的成员：
csharp复制public static string Describe<T>(T input)
{
return input?.ToString() ?? "null";
}
ToString() 能调用，是因为编译器知道所有类型最终都有 object 的 ToString()。但如果你是这么写的：
csharp复制public static T Max<T>(List<T> items)
{
...
if (items[i].CompareTo(max) > 0) // 编译不过
}
编译器会直接报错。它不知道 T 有没有 CompareTo，就像面试官只看到简历上写着“这人会编程”，但不知道他会的是 C# 还是 Python，自然不敢让他直接接手一个 C# 项目。
这正是约束的第一层价值：约束是在编译器层面，把“不知道有没有”变成“我知道一定有”。
给上面的 Max 方法加上约束：
csharp复制public static T Max<T>(List<T> items) where T : IComparable<T>
{
if (items.Count == 0)
throw new InvalidOperationException("集合不能为空");
T max = items[0];
for (int i = 1; i < items.Count; i++)
{
if (items[i].CompareTo(max) > 0)
max = items[i];
}
return max;
}
加了 where T : IComparable<T> 后，编译器就允许调用 CompareTo 了。约束真正干的事不是运行时做检查，而是在编译期告诉你：这个泛型方法只承接具备某种能力的类型，不具备这种能力的调用方在编译阶段就会被拦下。
1.2 C# 里能写的约束，远比大多数人常用的多
很多开发者熟悉 where T : class、where T : struct、where T : new() 这三个，就以为约束到头了。实际上 C# 从 7.3 之后约束能力扩张了不少，我整理了一张常用表：
| 约束写法 | 约束内容 | 典型场景 |
|---|---|---|
where T : class |
引用类型 | 仓储、缓存中避免装箱 |
where T : struct |
值类型 | 数值统计、高性能容器 |
where T : notnull |
不可为空的值或引用类型 | 字典 key 等禁止 null 的场景 |
where T : unmanaged |
非托管类型 | 内存操作、Span 相关场景 |
where T : new() |
必须有公共无参构造函数 | 由泛型代码内部创建实例 |
where T : Enum |
必须是枚举类型 | 枚举通用解析/校验 |
where T : Delegate |
必须是委托类型 | 事件总线包装 |
where T : BaseClass, IInterface, T2 |
基类、接口、类型参数多重组合 | 领域模型约束 |
有几个点值得单独说明。
where T : new() 和 where T : struct 一起用，在之前的 C# 版本里是冗余的，因为所有值类型都有默认构造函数；但如果 T 是引用类型，new() 要求它必须有公共无参构造。实际开发中不少团队会把 where T : class, new() 一股脑加到所有工厂方法上，这个习惯要谨慎：它等于是在发布一个额外契约，调用方传入的类必须有公共无参构造函数，做不到就只能编译失败。
where T : Enum 和 where T : Delegate 是 C# 7.3 才正式支持的。在那之前，想写一个通用的枚举工具，只能把约束写成 where T : struct，然后在方法内部反射判断 typeof(T).IsEnum，不符合就抛异常。加了约束之后，错误可以在编译期暴露，这是整体体验的一大提升。
1.3 约束是“契约”，不是“运行前检查”
有一个高频误解：加约束只是让代码更早报错，或者在运行时多一道检查。
如果你写：
csharp复制public static void Save<T>(T entity) where T : IEntity
调用的地方传入一个没实现 IEntity 的类，编译器在你编译调用方代码时就会报错，根本到不了运行阶段。即使你通过反射硬调用，运行时也会因为泛型类型实参不满足约束而抛异常。
把约束类比成招聘 JD 会更准确：不是入职那天才检查你会不会写代码，而是在简历筛选阶段就把能力不对口的人筛掉了。这个筛选依据必须写在方法签名上，是因为泛型方法内部无法提前知道调用方会传入什么，它需要签名为自己建立一个“安全操作边界”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 泛型约束在不同语言里的面貌：语法差异背后藏着泛型实现的差异
“约束”并不是某一门语言的独有概念，但各语言的写法和语义差别很大。差别最大的点是：约束是写在类型参数声明的位置，还是写在函数/类定义的尾巴上；约束在运行时还剩不剩。
2.1 Java：extends 上限与多边界“第一个类、其余接口”
Java 泛型的约束写法是 <T extends Bound>，这里的 extends 既表示继承类，也表示实现接口。一个类只能继承一个父类，但可以实现多个接口，所以 Java 里最多只能有一个类边界，接口边界可以有多个：
java复制public static <T extends Number & Comparable<T>> T max(List<T> items) {
// ...
}
为什么要强制“只能有一个类边界”？看过 Java 泛型擦除机制就明白了。Java 泛型在字节码层面会把类型参数擦除到它的左边界，也就是第一个边界。如果允许两个类边界，运行时不知道该把泛型类转换成哪一个，所以只能在语法层面禁掉。
这个细节在实际写代码时很有用：多边界里第一个位置写哪个类或接口，不只是风格问题。比如 <T extends Serializable & Comparable<T>> 和 <T extends Comparable<T> & Serializable> 语义差不多，但使用 “Serializable” 作为首个边界会影响编译器对类型检查。尽管日常通常不会导致大问题，但理解了擦除机制再去看这些规则，心里会踏实很多。
Java 泛型的另一个特点是，约束在运行时是“被大部分擦除的”。泛型类拿到的是左边界类型，调用方真正传入的类型信息只保留在反射的 TypeVariable 等结构里。所以 Java 里常见补一个 Class<T> 参数，用 clazz.newInstance() 来创建实例，本质是在运行时把丢失的类型信息找回来。
2.2 TypeScript：extends 背后是纯类型层面的“子类型宽窄”关系
TypeScript 的泛型约束也用 extends：
typescript复制function logging<T extends { length: number }>(arg: T): T {
console.log(arg.length);
return arg;
}
这里 { length: number } 是一个结构类型，只要传入的字符串、数组，或者任何包含 length 属性的对象都可以满足约束。TypeScript 的 extends 并不是“继承自某个运行时类”，而是表示“类型 T 是这个结构的子类型，至少拥有该结构包含的所有属性”。
这也带出了 TypeScript 约束的一个核心特性：约束完全存在于编译期，运行时根本不存在任何类型信息。它的类型系统像在一张草稿纸上做计算，编译成 JavaScript 后，所有泛型和约束都会消失。所以在 TypeScript 里你不能依赖约束做运行时校验，只能用类型守卫、参数校验等手段在运行时补齐。
2.3 C++ 模板的默认值，与 C#/Java 的思路完全不同
C++ 模板在早期没有真正的“约束”，写错了只能等模板实例化时爆出一大串晦涩错误。C++20 引入 concept 之后，情况改善了：
cpp复制template<typename T>
requires std::integral<T>
T add(T a, T b) {
return a + b;
}
C++ 的模板和 C#/Java 泛型最大的差异是：模板在编译时会针对每种类型参数重新生成代码，因此约束更像是一个“编译期过滤规则”，而不是一套运行时元数据约定。这也导致 C++ 里允许“模板参数默认值”，并且默认值可以是一个具体类型：
cpp复制template<typename T = int>
T getDefault() {
return T();
}
这种默认值能力放到 C# 和 Java 里是不存在的，我后面会专门展开。
2.4 各语言约束对比
| 语言 | 约束写法 | 边界在运行时是否保留 | 是否支持默认类型参数 |
|---|---|---|---|
| C# | where T : IInterface, new() |
约束由 CLR 元数据保留，实例化时校验 | 否 |
| Java | <T extends B1 & B2> |
擦除到左边界 | 否 |
| TypeScript | <T extends { ... }> |
完全擦除，运行时不存在 | 是 |
| C++ | template<typename T> requires ... |
编译期概念，运行时不保留 | 是 |
看到没，C# 和 Java 在“默认类型参数”这条上是同一阵营的。写惯了 TypeScript 或 C++ 的开发者第一次回 C# 时，经常会发出灵魂拷问：为什么 C# 参数类型不能写默认值？这个问题放到第 5 节细说。
3. 不写约束时，默认边界是什么：Object 与 unknown 的差别才是关键
“默认类型”这个词在中文技术社区里含义比较模糊。有些人指的是泛型参数上面的默认值，比如 <T = string>；有些人指的是运行时返回的默认值，比如 default(T)。但还有一个更基础但也更容易被忽略的“默认”概念：当你不在泛型参数上写任何约束时，编译器默认的限制边界是什么。
3.1 Java 无界类型参数的默认上界是 Object
Java 里写：
java复制public static <T> T getValue(T input) {
return input;
}
看起来 T 没有任何约束，但它在编译期是有默认边界的，等价于：
java复制public static <T extends Object> T getValue(T input) {
return input;
}
这个默认上界决定了你能在方法内部对 T 调用哪些方法。因为边界是 Object，所以能调 toString、eqauls、hashCode，但不能调字符串、集合、数值等类型特有的方法。你甚至可以直接写 T x = null;，因为 Java 里所有引用类型都允许 null，这本身就是一种默认值。
Java 无界类型参数通常配合 null 作为“空结果”返回。但这也是个经典坑：调用方并不知道泛型方法返回的是 null，还是有效实例。所以现代 Java 实践里，涉及泛型方法的返回，尽量用 Optional<T> 来表达“可能没有值”。
3.2 TypeScript 的默认约束是 unknown，而不是 any 或 Object
TypeScript 中如果不写约束，类型参数是什么样：
typescript复制function doSomething<T>(arg: T): T {
return arg;
}
这里 T 的默认约束是 unknown，不是 any。unknown 比 Java 的 Object 更严格：unknown 类型上的任何属性访问和方法调用都不被允许，你只能把它从一个地方搬运到另一个地方，想做任何操作都必须先收窄。
Java 的 Object 好歹还有 toString、hashCode、equals；TypeScript 的 unknown 几乎就是一块“无法解包的石头”。这样设计是为了迫使开发者显式写出约束，如果没有足够信息，就不该对类型参数做任何操作。
对写库的开发者来说，这个差异很值得留意。如果默认类型是 unknown，那么一个未约束泛型函数想打印日志，都要先把 T 收窄成 unknown 再判断。反过来，Java 开发者习惯在泛型方法里调用 Object 方法，TypeScript 里这套完全行不通。
3.3 C# 无约束 T 的“伪 object 边界”
C# 里不写约束的 T，直观表现跟 Java 的默认上界比较接近：ToString()、Equals()、GetHashCode() 这些 object 成员都能用。但它还有一个 Java 和 TypeScript 没有的特殊能力，就是配合 default(T) 拿到该类型的默认值。
而无约束 T 和“可空性”结合时会出现更微妙的语义。比如下面这个方法返回的既可能是引用类型的 null，也可能是值类型零值：
csharp复制public T? FirstOrNull<T>(IEnumerable<T> source)
T? 在泛型中的解释取决于 T 是值类型还是引用类型，这导致泛型方法的可空标注比普通方法复杂一个级别。如果你在这个方法里用 default 表示“没有找到”，调用方又无法区分泛型参数究竟是值类型还是引用类型，就只能写“如果结果是默认值就当没有”——这句话本身就有模糊地带：值类型的默认值 0 完全可能是合法数据。
这里就引出了第 4 节的核心：泛型里的“默认值操作”远没有看上去那么简单。
4. default(T)、default 与 new()：泛型场景里的三种“默认值操作”别混用
C# 中跟默认值相关的元素特别多，而且是新人最容易栽跟头的地方。我在第 1 节说过 default(T) 能拿到未知类型的默认实例。但 C# 7.1 之后又引入了无类型 default 字面量，加上 new() 约束，很容易让初学者混淆：这三个不都是返回一个“默认实例”吗？还真不是。
4.1 default(T)：拿到的是“类型的零值状态”
default(T) 的语义是返回 T 类型的默认值：
- 如果 T 是值类型，它返回零位模式对应的值，比如
int的 0、DateTime的0001-01-01、枚举的 0 值。 - 如果 T 是引用类型，它返回 null。
- 如果 T 是
Nullable<T>，也就是int?，它返回 null，而不是 0。
这个语义放到泛型约束环境里会变得很有意思：
csharp复制public static T GetDefaultValue<T>()
{
return default(T);
}
这个方法对任何 T 都能编译。但你猜调用 GetDefaultValue<int>() 和 GetDefaultValue<string>() 分别得到什么？前者是 0，后者是 null。同一个代码路径，因为类型实参不同，运行时拿到的“默认值”形态完全不同。
这也是很多缓存组件出问题的根源。一个看起来无伤大雅的 return default;，对于 int 是合法数据 0，对 string 是 null，如果调用方把这两个东西混在一个统计系统里，很容易把合法的 0 当成空值处理