本文介绍在 typescript 中无需手动重复编写代理方法，即可类型安全地将一个类的实例方法自动委托给内部对象的方法调用，重点对比继承与代理模式的适用场景，并提供可直接运行的类型安全实现方案。
本文介绍在 typescript 中无需手动重复编写代理方法，即可类型安全地将一个类的实例方法自动委托给内部对象的方法调用，重点对比继承与代理模式的适用场景，并提供可直接运行的类型安全实现方案。
在实际开发中，我们常遇到“组合优于继承”的设计需求：Bar 类内部持有一个 Foo 实例（如 this.foo = new Foo()），并希望对外暴露 Foo 的全部方法，但又不能直接继承 Foo——因为 Bar 可能还需继承其他基类、或需独立构造逻辑（例如传入特定参数初始化 Foo），此时手动逐个编写 greet() { return this.foo.greet(); } 显得冗余且难以维护。
遗憾的是，TypeScript 原生不支持运行时方法自动代理的类型安全语法糖（如 Python 的 __getattr__ 或 Rust 的 Deref）。但可通过以下两种类型安全方式优雅解决：
✅ 方案一：优先考虑 extends（当语义上是“is-a”关系时）
若 Bar 在业务语义上确实是 Foo 的一种（例如 AdminUser extends User），最简洁、最类型安全的方式就是直接继承：
class Foo {
greet() { return "hello"; }
sayGoodbye() { return "bye"; }
}
class Bar extends Foo {} // ✅ 零代码，全方法自动继承，100% 类型安全
const bar = new Bar();
console.log(bar.greet()); // "hello" —— 类型推导准确，IDE 自动补全完整
console.log(bar.sayGoodbye()); // "bye"该方案编译后为标准 ES6 继承，无运行时开销，且完全保留 TypeScript 的类型检查、重载支持和泛型推导能力。
完整的Galileo AI平台 TypeScript/JS SDK 参考，用于评估、观察和保护 GenAI 应用。适用于构建 Node.js 或 TypeScript 项目。
⚠️ 方案二：组合 + 显式类型合并（当必须使用组合时）
若 Bar 必须持有 Foo 实例（如需定制化初始化、多实例复用或避免继承链污染），则需借助 TypeScript 的交叉类型与声明合并保证类型安全：
class Foo {
greet() { return "hello"; }
sayGoodbye() { return "bye"; }
}
class Bar {
private foo: Foo;
constructor(foo?: Foo) {
this.foo = foo ?? new Foo();
}
// 手动转发（类型安全）：TS 会校验方法存在性与签名一致性
greet() { return this.foo.greet(); }
sayGoodbye() { return this.foo.sayGoodbye(); }
}
// 关键：通过接口扩展声明，让类型系统知道 Bar 具备 Foo 的所有公有方法
interface Bar extends Foo {}
// ✅ 此时 const bar: Bar 可被当作 Foo 使用，且 IDE 补全/类型检查完整
const bar = new Bar();
bar.greet(); // OK
bar.sayGoodbye(); // OK? 注意：
interface Bar extends Foo {}并非运行时行为，仅增强类型系统认知；所有方法仍需在类体内显式实现（否则调用会报错），但 TS 编译器会严格校验每个代理方法是否与Foo原方法签名一致（含返回类型、参数、重载），杜绝this.foo.missingMethod()类型漏洞。
❌ 不推荐方案：any / // @ts-ignore / 运行时 Proxy
- 使用
Proxy动态拦截虽可实现“全自动转发”，但会丢失所有类型信息，导致bar.greet()返回any，破坏类型安全； -
Object.getOwnPropertyNames(Foo.prototype)等反射操作在 TS 中无法参与类型推导，属于纯 JavaScript 运行时技巧，与本题“类型安全”前提冲突。
总结
| 场景 | 推荐方案 | 类型安全 | 维护成本 | 适用性 |
|---|---|---|---|---|
Bar 是 Foo 的特化子类（is-a） |
class Bar extends Foo |
✅ 完美 | ⭐ 极低 | 最优解 |
Bar 必须组合 Foo（has-a），且需强类型保障 |
class Bar + interface Bar extends Foo
|
✅ 严格校验 | ⚠️ 中等（需同步维护代理方法） | 生产推荐 |
| 追求“零代理代码”且接受类型退化 |
Proxy + any
|
❌ 失效 | ⭐ 极低 | 仅限原型验证 |
最终选择应基于领域建模准确性：优先用 extends 表达真实继承关系；仅当组合不可替代时，再以显式代理 + 接口合并守住类型防线。
