TypeScript 的泛型参数支持两个看似独立、实则紧密关联的能力：约束和默认值。约束用 extends 限制类型参数必须满足某个结构，默认值则在调用方没有提供类型信息时兜底。真正容易让人困惑的是，当两者同时出现在同一个类型参数上时，类型推断既不是简单取默认值，也不是完全由约束推导，而是遵循一条清晰的优先级链路。
回顾约束与默认值各自的行为
先看约束。下面这个函数要求 T 必须包含 length 属性为 number 的对象。调用时无论传入数组、字符串还是自定义对象，只要结构匹配即可，编译器会根据实参把 T 推断为具体类型。
function getLength<T extends { length: number }>(value: T): number {
return value.length;
}
getLength("hello");
getLength([1, 2, 3]);
getLength({ length: 10 });
这里没有默认值，所以调用实参完全决定了 T。若传入一个不含 length 的原始类型，TypeScript 会立刻报错，因为实参不满足约束。约束的本质是一种下限检查，它不会改变推断出的具体类型，只是阻止不符合条件的类型进入泛型。
再单独看默认值。默认值用于在无法从调用中推断类型时补位。比如下面这个函数，如果没有默认值，调用 create() 时 T 只能被推断成 unknown，有了默认值后 T 会回退到 string。
function create<T = string>(): T {
return null as unknown as T;
}
const a = create(); // a: string
const b = create<number>(); // b: number
默认值允许类型参数在没有显式传入、也没有可推断位置时获得一个具体类型。它并不影响显式类型参数，也不影响已经能推断出类型的场景。理解这一点很重要，因为当约束加入后，默认值变成了约束范围内的候选类型，而不是独立决策。
推断顺序：实参优先，默认值兜底，约束始终把关
当类型参数同时声明约束和默认值时，编译器处理流程可以总结为三步。第一步，检查调用点是否有显式类型参数，如果有，就直接用该类型并检查它是否满足约束。第二步，如果没有显式类型参数，则尝试从函数参数或返回类型上下文中推断类型。第三步，如果推断失败或没有足够信息，才考虑默认值，并在默认值不满足约束时产生编译错误。
下面用一段代码验证。我们定义一个函数，T 被约束为具有 name 属性的对象，同时默认值为一个具体的结构。
interface Named {
name: string;
}
const fallback: Named = { name: "fallback" };
function resolve<T extends Named = Named>(source?: T): T {
return source ?? fallback as T;
}
const r1 = resolve(); // r1: Named
const r2 = resolve({ name: "ok" }); // r2: { name: string }
const r3 = resolve({ name: "x", id: 1 }); // r3: { name: string; id: number }
r1 没有传实参，所以推断不到任何信息，默认值 Named 生效。r2 传入了对象，T 被推断为字面量扩展后的 { name: string }。r3 传入更丰富的对象，T 被推断为 { name: string; id: number }，即使默认值是 Named，也没有把 T 收窄。这说明默认值只在推断失败时触发，而不是在推断结果满足约束的情况下参与联合或收窄。
再看一个返回类型上下文参与推断的情况。当泛型函数返回值被赋值给一个预期类型时，TypeScript 会同时从参数和返回类型两端推断，这时默认值仍然只会在完全没有信息时生效。
function pick<T extends object = { id: number }>(): T {
return { id: 1 } as T;
}
const p1: { id: number } = pick(); // T 从返回上下文推断为 { id: number }
const p2 = pick(); // T 使用默认值 { id: number }
如果在 p1 中把返回类型换成 string，编译器会报错，因为 string 不满足 object 约束。这就是约束“始终把关”的含义：无论类型来自实参、默认值还是上下文，最终都要经过 extends 检查。
默认值依赖其他类型参数时的推断链
TypeScript 允许默认值引用同一泛型列表中更早出现的类型参数。这种写法在工具类型中很常见，比如 Pick、Record 或者自定义映射类型。当默认值依赖前一个参数时，推断链路会变得更复杂，因为前一个参数没有推断成功，后一个参数可能继承它，也可能回退到自己的默认值。
function wrap<T extends object, U = T>(value: T, extra?: U): [T, U] {
return [value, extra ?? value];
}
const w1 = wrap({ a: 1 }); // w1: [{ a: number }, { a: number }]
const w2 = wrap({ a: 1 }, { b: "x" }); // w2: [{ a: number }, { b: string }]
w1 中 U 的默认值是 T，而 T 被实参推断为 { a: number }，因此 U 也为 { a: number }。w2 中 U 从第二个实参直接推断为 { b: string }，默认值不参与。这里需要特别注意，U 虽然默认等于 T，但它并没有 extends T 的约束，所以 w2 中 U 和 T 可以完全不同。如果希望 U 必须兼容 T，应该写 U extends T = T，这样 w2 的第二个参数 { b: string } 不包含 a 属性就会报错。
再看一个默认值依赖约束条件本身的例子。有时我们希望默认类型就是约束本身，但在泛型函数声明中直接写 extends 后面那个类型作为默认值，可能产生语义偏移。例如下面这种写法：
type Base = { kind: string };
function handle<T extends Base = Base>(input: T): T {
return input;
}
const h1 = handle({ kind: "a" }); // h1: { kind: string }
const h2 = handle({ kind: "b", value: 2 }); // h2: { kind: string; value: number }
handle 的默认值 Base 只在无实参或推断失败时出现，实际调用只要传了对象，T 就会尽量保留字面量结构。很多开发者误以为默认值会像约束一样限制返回类型，实际上返回类型仍然由推断出的 T 决定。如果希望返回值只保留 Base，可以手动返回 Base 类型，或者在使用处写 handle<Base>。
推断失败与约束冲突的典型错误
理解上面的顺序后，可以更清楚地解释一些常见报错。比如下面这个声明，默认值不满足约束，TypeScript 会在声明阶段就直接提示错误：
function broken<T extends { id: number } = { name: string }>(): T {
return null as unknown as T;
}
这段代码无法通过编译，因为 { name: string } 不能赋值给 { id: number }。默认值必须落在约束允许的范围内，否则泛型声明本身就是矛盾的。修复方式是让默认值也包含 id 属性，或者放宽约束。
另一个容易踩坑的地方是函数重载与泛型默认值的交互。当同一个函数有多个调用签名时，TypeScript 会按顺序匹配重载，而不是合并所有推断信息。默认值只在匹配到具体泛型签名后才参与推断，如果前面的重载匹配成功但推断不出类型，后续重载不会继续尝试。因此建议把更具体的签名放在前面，把带有默认值的宽泛签名放在最后。
function convert<T extends number | string = number>(value: T): T;
function convert(value: unknown): unknown {
return value;
}
const c1 = convert(42); // c1: number
const c2 = convert("x"); // c2: string
这个例子中 T 从 42 推断为 number，从 "x" 推断为 string，默认值没有机会触发。如果调用时传入一个布尔值，编译器会在匹配到第一个签名时失败，因为 boolean 不满足约束，即便有默认值也不会回退。这是实际项目中需要特别注意的一点：默认值不是万能兜底，它只解决“无信息”，不解决“信息不合法”。
实际开发中的几个判断准则
当你在函数签名中同时使用 default 和 extends 时，可以先问自己三个问题。这个类型参数有没有可能从实参推断？如果可能，默认值大概率只是为了处理可选参数或者无参数调用。默认值是否就是约束本身？如果是，注意它不会收窄已经被推断出的具体类型。是否存在多个类型参数互相引用？如果存在，明确谁先推断、谁后兜底，必要时给后面的参数也加上约束。
对于工具类型库作者来说，建议将默认值设计成约束的一个具体实现，并且尽可能保持最小结构。这样做既能提供良好的类型提示，又不会在用户传入更具体结构时丢失字段。例如下面这个配置读取函数：
interface Config {
debug: boolean;
retries: number;
}
const defaultConfig: Config = {
debug: false,
retries: 3
};
function loadConfig<T extends Config = Config>(overrides?: Partial<T>): T {
return { ...defaultConfig, ...overrides } as T;
}
const cfg = loadConfig({ debug: true });
这里 T 从 overrides 推断并不完整，因为 Partial 只提供了 Config 的一部分字段，TypeScript 无法推出 T 的全貌，所以默认值 Config 会介入，最终 cfg 的类型是 Config。如果传入更完整的对象，推断结果会保留额外属性。这种模式在配置合并场景中非常实用。
最后需要注意的是，默认值只负责类型层面的回退，不会在运行时生成任何值。如果你希望通过默认值构造对象，必须在函数体内显式处理，就像 loadConfig 里的 defaultConfig 一样。类型层面的默认值和运行时默认参数是完全不同的两件事，混在一起很容易写出看似合理但实际返回 undefined 的代码。
TypeScript泛型类型推断泛型默认值修改时间：2026-09-21 03:18:34