先记住这个答案
T extends Shape 表示调用者选择的 T 必须满足 Shape 的结构要求，函数实现因而可以使用这些基础成员；但 T 可能还包含额外必需字段或更窄的取值。只有基础字段的 Shape 不一定满足那个具体 T，因此不能随意把它作为 T 返回。可以返回明确的基础类型、保留并修改输入中的必要信息，或接收能构造 T 的工厂。泛型约束主要存在于类型层，与 class extends 建立运行时原型关系和复用实现是不同机制。
- 约束给出最低能力，不列出 T 的全部要求
- 满足基础结构不代表能构造任意受约束类型
- 需要创建具体 T 时应获得相应构造能力
为什么看似满足约束还是不能返回
假设约束只要求 id 字符串，调用者却把 T 选成还必须带 role 的管理员对象。函数若只返回一个 id，就违反了调用者期待。编译器拒绝这种返回，并不是不知道对象有 id，而是必须检查实现对所有合法 T 都成立。
示例保留错误构造函数，并给出接收工厂的版本。工厂由知道具体类型的调用者提供，能够补齐角色等必需信息。函数内部不需要断言，把构造责任交给真正掌握完整契约的位置，返回类型关系也能自然保持。
type Identified = { id: string };
function invalid<T extends Identified>(id: string): T {
// @ts-expect-error T 可能还要求其他成员
return { id };
}
function createWith<T extends Identified>(id: string, factory: (id: string) => T): T {
return factory(id);
}
const admin = createWith('u7', id => ({ id, role: 'admin' as const }));只有 id 的对象不能满足所有可能的 T，而工厂明确返回带角色的具体对象。调用结果保留 role 字段和字面量信息，无需用 as T 掩盖构造证据不足的问题。
约束为什么不要求显式继承
以普通对象结构作为约束时，只要输入满足需要的成员，就可以参与泛型调用，不必先继承某个业务基类。约束并不会创建原型链，也不会让输入自动获得方法实现；这些能力必须真实存在于运行时值上。
如果约束使用含私有或受保护成员的类类型，兼容性还会受到成员来源规则影响。不能因此把所有 extends 都解释成同一种继承。阅读代码时先确认它出现在类型参数、接口扩展、条件类型还是类声明位置，不同位置表达的关系不同。
选择修复方式时保留真正需求
若函数只是产生通用标识结构，直接返回 Identified 可能最诚实，不必保留一个无法兑现的泛型。若它根据传入实体更新字段，需要审查更新值是否仍满足调用者的窄类型，不能假定对象展开后覆盖基础字段总是安全。
接收工厂适合通用流程需要创建具体业务对象的情况，但工厂也必须真实遵守返回契约。外部数据仍应在工厂或解析层验证。设计泛型时，应问清究竟是保留已有具体值、变换结构，还是创建未知具体类型，三者需要的证据不同。
容易答错的地方
- 满足 extends 后基础对象就等于 T
- T 可以比约束更具体，额外字段和字面量限制都可能使基础对象不够用；约束提供最低能力，不提供完整构造说明。
- 返回对象加 as T 就证明实现正确
- 断言只是让编译器接受调用者承担的判断，并不会补齐缺失成员；如果函数无法掌握完整 T，应调整返回类型或增加构造入口。
面试官还会怎么问？
泛型约束会在运行时自动验证 id 吗？
不会，它只参与编译检查；来自网络或动态调用的值可能违反声明，仍要在真实边界执行字段与业务规则验证。
把返回类型改成约束类型会损失什么？
调用者只能按基础契约使用结果，不能再假定保留全部专有字段；如果函数本来就只创建基础结构，这通常是正确而清楚的限制。
可以给 T 设置默认类型来解决构造错误吗？
默认类型只在缺乏其他选择时参与类型参数确定，调用者仍可选择更具体类型；因此默认值不能让基础对象满足所有合法 T。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。