泛型约束与默认值：多语言对比下的类型边界与陷阱解析

先讲一件让我排查到凌晨的事。上周写一个内存缓存组件，内部有个泛型方法：

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 : 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 会更准确：不是入职那天才检查你会不会写代码，而是在简历筛选阶段就把能力不对口的人筛掉了。这个筛选依据必须写在方法签名上，是因为泛型方法内部无法提前知道调用方会传入什么，它需要签名为自己建立一个“安全操作边界”。

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# 和 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 当成空值处理