1. 从一次面试聊起装饰器到底在解决什么问题上周有个朋友去面资深前端岗回来跟我吐槽面试官问我装饰器原理我背了语法但他追问我为什么需要元数据反射一下就懵了。这个场景太典型了。TypeScript 装饰器这两年出现的频率越来越高从 NestJS 的依赖注入到 class-validator 的校验声明从 Vue3 的装饰器提案到微前端框架里的注册逻辑到处都能看到它的影子。但大多数人停留在会用 Component 和 Injectable的阶段真要解释清楚这套机制背后的设计逻辑就卡壳了。先把定义摆清楚。装饰器Decorator是 TypeScript 提供的语法特性本质是一个函数用来在编译期对类、方法、属性、参数做标记和包装。元数据反射机制Metadata Reflection则是配合装饰器的一套运行时 API能做到在运行时获取编译期的类型信息。这两个东西合在一起构成了所谓声明式编程的基石——你不需要写一堆命令式的组装代码只需要在类上打几个标记框架就能自动帮你完成注册、校验、注入这些工作。这篇文章我会从装饰器的执行机制讲起重点剖析元数据反射的底层原理然后手写一个完整的依赖注入容器把元数据驱动框架设计这个思路贯通一遍。最后把面试里常见的追问点、实操中的坑都列出来。适合正在用 TypeScript 写业务但想更深入理解框架原理的中高级开发者也适合准备高级前端面试、需要系统梳理装饰器知识体系的同学。先说个题外话现在 TypeScript 官方文档已经明确标注装饰器是试验性特性Experimental但它的应用场景完全谈不上试验——NestJS、Angular、TypeORM 这些主力框架全都建立在装饰器之上。理解这套机制你才算真正读懂了这些框架的设计源头。2. 装饰器的本质一个被安排执行顺序的函数2.1 核心三问装饰器是什么、何时执行、怎么作用装饰器说起来很简单就是一个接收特定参数的函数。比如这样function MyDecorator(target: any, propertyKey?: string, descriptor?: PropertyDescriptor) { // 根据装饰的位置参数有所不同 console.log(装饰器执行了); } MyDecorator class MyClass {}重点在于装饰器的执行时机是类的定义阶段而不是实例化阶段。用原生 JavaScript 的思维方式理解这句话就相当于执行到class MyClass {}这条语句时装饰器函数同步被调用。我们写个例子实测一下function Log(target: any, key: string, descriptor: PropertyDescriptor) { console.log(2. 装饰器内); } console.log(1. 类定义前); Log class Foo { method() {} } console.log(3. 类定义后); new Foo().method(); console.log(4. 实例方法调用后);控制台输出顺序是1. 类定义前 2. 装饰器内 3. 类定义后 4. 实例方法调用后这个顺序揭示了装饰器的本质它就是一个在类被求值evaluate时同步执行的函数。很多人误以为装饰器是在方法调用或实例化时触发这是第一个认知偏差面试时能把这点说清楚已经超出多数候选人了。2.2 四类装饰器的参数差异与执行顺序TypeScript 装饰器分四类类装饰器、方法装饰器、属性装饰器、参数装饰器。参数签名各有不同我把它们罗列成表方便对照记忆装饰器类型第一个参数 target第二个参数第三个参数返回值的作用类装饰器类的构造函数本身无无替换整个构造函数方法装饰器类的原型对象或构造函数静态方法时方法名属性描述符可修改方法实现属性装饰器类的原型对象或构造函数属性名无返回值被忽略无法直接改属性值参数装饰器类的原型对象或构造函数方法名参数索引返回值被忽略这里的细节差异很容易成为面试陷阱。属性装饰器拿不到属性描述符因为属性定义阶段还没有生成描述符所以它只能做标记不能拦截读写。而方法装饰器能拿到descriptor.value这意味着你可以在装饰器里替换掉原来的函数实现这就是 AOP面向切面编程的基础。再看同一类成员上的多个装饰器的执行顺序function First() { console.log(first); } function Second() { console.log(second); } class Foo { First Second method() {} }输出顺序是second然后是first。装饰器从下往上执行越靠近方法的装饰器先执行。类比一下就是穿衣服你先穿最里面的衬衫再穿外套从程序员视角看代码上写在上方的装饰器是外套后执行。而不同类别装饰器的执行顺序是由 TypeScript 编译器安排好的实例属性装饰器、方法装饰器、参数装饰器按成员声明顺序静态属性装饰器、方法装饰器、参数装饰器构造函数参数装饰器类装饰器这个顺序很像工厂里的流水线先把所有零件分别打标成员装饰器最后出厂前再给整机贴标签类装饰器。实际写代码时不需要死记硬背但面试能说出来绝对加分。3. 元数据反射机制运行时如何看到编译期的类型3.1 Reflect.metadata 与设计时类型装饰器本身只是函数真正让它强大的是配套的emitDecoratorMetadata编译选项和reflect-metadata库。这两者结合才构成完整的元数据反射机制。首先在tsconfig.json中开启两个试验性配置{ compilerOptions: { target: ES5, experimentalDecorators: true, emitDecoratorMetadata: true } }然后项目里引入reflect-metadata库import reflect-metadata;为什么要引入这个库因为ECMAScript 原生并没有反射元数据的 API这属于 Stage 2 的提案reflect-metadata是官方提供的 polyfill。它给Reflect对象挂载了metadata、defineMetadata、getMetadata等全局方法。emitDecoratorMetadata开启后TypeScript 编译器会在装饰器执行前自动把三种元数据注册到被装饰的成员上design:type成员属性的类型构造器引用design:paramtypes方法参数的类型列表design:returntype方法的返回类型这段编译后的 JavaScript 看起来是这个样子的// TypeScript 源码 class UserService { getUser(id: number): User { return new User(id); } }编译简化后加了装饰器的情况下会变成// 伪代码展示编译产物 __decorate([ Reflect.metadata(design:type, Function), Reflect.metadata(design:paramtypes, [Number]), Reflect.metadata(design:returntype, User) ], UserService.prototype, getUser, null);这里的关键点是TS 编译器在生成代码时直接把Number和User这种类型信息的构造器constructor作为元数据塞进了 Reflect.运行时框架就能根据这些类型做动态派发和验证。举个非常直观的场景在运行时判断方法第一个参数的构造函数是不是Number可以做参数校验判断属性的构造函数是Array可以做数组嵌套转换。3.2 手动定义元数据的三种姿势除了编译器自动注入的设计时类型你还可以通过Reflect.defineMetadata手动给对象添加任意元数据// 姿势一直接调 API Reflect.defineMetadata(role, admin, User); Reflect.getMetadata(role, User); // admin // 姿势二用装饰器工厂 function Role(role: string) { return function (target: any) { Reflect.defineMetadata(role, role, target); }; }第三种姿势是利用Reflect.metadata装饰器这个写法在 NestJS 源码中很常见Reflect.metadata(roles, [admin, user]) class User {}三种写法的底层都指向defineMetadata区别只在于调用时机和位置。类比到生活里你可以把元数据看成贴在物品上的标签——直接贴defineMetadata、通过专用工具贴装饰器工厂、批量贴Reflect.metadata装饰器。机制一样封装层次不同。3.3 设计时类型到底存了什么别和值类型搞混这条必须单独强调因为我见过太多人在运行时类型判断上栽跟头。设计时类型存的是构造器不是字符串类型名。function TypeInspector(target: any, key: string) { const type: Function Reflect.getMetadata(design:type, target, key); console.log(type String, type Array, type Object); } class Demo { TypeInspector name: string; // true, false, false TypeInspector tags: string[]; // false, true, false }但要注意design:type只看属性声明时的类型注解。如果你只写public data;没标注类型编译器会推断为Object。还有一个特殊现象接口interface作为泛型设计时类型拿到的可能不是你以为的那个具体类型。因为接口在运行时被完全擦除了interface IPage { page: number; } class Paginator { Inspector current: IPage; // design:type 会是 Object而不是 IPage }这就是 TypeScript 类型系统和元数据反射之间的硬边界。面试官如果追问这个边界你能答出来说明你真的踩过坑。4. 实战从零手写一个依赖注入容器4.1 需求拆解为什么 DI 需要元数据反射聊了这么多原理现在落到最核心的应用场景——依赖注入。依赖注入DI是控制反转IoC的一种实现方式核心思路是对象的依赖不由对象自己创建而是由外部容器在实例化时自动注入。如果不靠装饰器传统写法是这样的class UserController { private userService: UserService; constructor() { this.userService new UserService(); // 手动创建依赖 } }问题很明显控制器直接依赖UserService的具体实现一旦构造方式变更所有调用处都要跟着改。用装饰器加元数据反射就能变成声明式的class UserController { Inject private userService: UserService; // 容器自动注入 }要实现这个目标我们需要几个环节配合装饰器在类上标记依赖关系谁需要被注入元数据记录依赖的类型信息需要注入什么类型容器读取元数据拿到类型构造器完成实例化递归处理依赖的依赖Service 里又依赖了 Repository4.2 容器核心实现注册、读取、实例化先实现一个最简版容器支持按标记注册和自动注入。完整代码分三块。第一块是注入装饰器在属性装饰器里读取design:type把类型存入元数据。import reflect-metadata; const INJECT_KEY INJECT_METADATA; export function Inject(target: any, propertyKey: string): void { const type Reflect.getMetadata(design:type, target, propertyKey); if (!type) { throw new Error(无法解析属性 ${propertyKey} 的类型请确认已开启 emitDecoratorMetadata); } Reflect.defineMetadata(INJECT_KEY, type, target, propertyKey); }第二块是Injectable类装饰器注册该类型本身到容器。export function Injectable(): ClassDecorator { return (target: any) { Reflect.defineMetadata(INJECTABLE, true, target); // 收集该类构造函数的参数类型 const paramTypes Reflect.getMetadata(design:paramtypes, target) || []; Reflect.defineMetadata(PARAM_TYPES, paramTypes, target); }; }第三块是容器核心逻辑。这里最关键的一点是容器拿到构造函数后要以递归的方式解析构造参数和属性依赖。export class Container { private providers new Mapstring, any(); private instances new Mapstring, any(); provide(key: string, clazz: any): void { this.providers.set(key, clazz); } resolveT(key: string): T { // 已有实例直接返回实现单例 if (this.instances.has(key)) { return this.instances.get(key); } const clazz this.providers.get(key); if (!clazz) { throw new Error(找不到 ${key} 对应的 Provider); } const paramTypes Reflect.getMetadata(PARAM_TYPES, clazz) || []; const params paramTypes.map((paramType: any) { // 构造器参数注入 return this.resolveForType(paramType); }); const instance new clazz(...params); this.instances.set(key, instance); // 属性注入 for (const prop of Object.keys(instance)) { const propInjectable Reflect.getMetadata(INJECT_KEY, instance, prop); if (propInjectable) { instance[prop] this.resolveForType(propInjectable); } } return instance as T; } private resolveForType(type: any): any { const matchedName [...this.providers.keys()] .find(name this.providers.get(name) type); if (!matchedName) { throw new Error(依赖类型 ${type.name} 未注册到容器); } return this.resolve(matchedName); } }代码里的resolveForType处理了一个关键问题元数据存储的是类型构造器但容器按字符串 key 管理 provider因此需要先找到 key 再调resolve。这一层间接是 DI 容器的技术核心很多手写 DI 的方案都在这步做文章。4.3 验证容器和参数计算过程写一段完整的使用示例把上面的容器跑起来Injectable() class UserRepository { findById(id: number) { return { id, name: 张三 }; } } Injectable() class UserService { constructor(private repo: UserRepository) {} } Injectable() class UserController { Inject private userService!: UserService; getById(id: number) { return this.userService.repo.findById(id); } } const container new Container(); container.provide(UserRepository, UserRepository); container.provide(UserService, UserService); container.provide(UserController, UserController); const controller container.resolveUserController(UserController); console.log(controller.getById(1)); // { id: 1, name: 张三 }这个例子虽然简单但已经覆盖了三个注入场景构造器参数注入Service 依赖 Repository、属性注入Controller 依赖 Service、单例缓存resolve 两次拿到同一实例。还有一个细节值得注意UserController里我用了非空断言userService!: UserService因为 TypeScript 的严格属性初始化检查会报错。这也解释了为什么很多框架文档里都建议开启strictPropertyInitialization: false或者用!标记——装饰器注入本质上是运行时赋值编译器在这个场景下无法静态分析。4.4 两级缓存的设计意图上面的instancesMap 就是一级缓存保证每个 Provider 在整个容器生命周期内只创建一次实例。这在工程上是必要的因为依赖对象可能持有数据库连接池或 HTTP 客户端重复创建会有严重的资源浪费。但单例缓存也有问题resolve返回的永远是同一个引用如果某些场景需要每次新建实例比如多租户上下文隔离就要在容器里加二级配置。更复杂的容器会维护瞬时作用域和请求作用域这超出了本文范围但思路是一样的用 Map 管理不同作用域下的实例缓存。5. 常见问题与避坑记录5.1 属性初始化顺序装饰器注解被覆盖了这个坑我踩过不止一次。看下面的代码class User { Inject service: UserService new UserService(); // 手动初始化会覆盖注入 }属性装饰器的执行时机在构造函数执行之前但属性初始化赋值语句 new UserService()在构造函数内部运行执行顺序靠后。结果就是装饰器刚注入好的实例立刻被赋值表达式的执行结果覆盖了。这就是为什么 DI 模式下要求把属性初始化的工作完全交给容器不要自己手动赋值。同理Object.defineProperty在装饰器阶段定义属性时writable和configurable的默认值在 ES5 和 ES6 目标下是不同的如果你同时操作描述符很容易踩到意外的表现差异。5.2 忘记开启编译选项design:type 取不到这是最常见的报错Reflect.getMetadata(design:type, ...) 返回 undefined。原因基本都是没在tsconfig.json里开emitDecoratorMetadata。检查顺序建议这样排查确认experimentalDecorators和emitDecoratorMetadata都设为true确认项目里import reflect-metadata在入口文件最先引入确认target不是ESNext个别版本下emitDecoratorMetadata对 ESNext target 支持不完整确认装饰器函数里用到的是getMetadata而不是getOwnMetadata——后者不会读取原型链上的元数据绝大多数场景用前者5.3 类型手柄Token冲突与循环依赖当两个类都注册到了容器但类型本身又在别处被复用字符串 key 管理方式很容易撞名。生产级 DI 框架更常见的方式是直接以类型构造器作为 key不经过字符串中转。这样既免了撞名问题也免了resolveForType里的命名查找。改造也简单把Mapstring, any换成MapFunction, any就行。循环依赖的排查A 构造函数依赖 BB 构造函数又依赖 A会导致resolve无限递归爆栈。方案是在resolve入口先检查实例是否已处于创建流程private resolving new Setstring(); resolveT(key: string): T { if (this.resolving.has(key)) { throw new Error(检测到循环依赖: ${key}); } this.resolving.add(key); try { // ...实例化逻辑 } finally { this.resolving.delete(key); } }5.4 Vue3 与装饰器的现实关系热词里出现了vue3 装饰器这里多说一句。Vue3 官方在 class API 方案上推进过装饰器路线但最终选择了 Composition API script setup的语法很大程度上是因为class 语法配合装饰器在类型推导上远不如函数式组合灵活。函数组合天然能推导出响应式变量的精确类型而装饰器注入的props往往是运行时才知道的。这意味着什么如果你在 Vue3 里找装饰器的大量使用场景主力还是 Element Plus、Ant Design Vue 这些组件库内部业务侧用装饰器写defineComponent的封装很少见。相比之下NestJS 的 controller/service/provider 体系、TypeORM 的实体定义才是装饰器的主战场。这个信息在面试时能体现你对社区技术选型的真实观察。5.5 Python 装饰器的心智模型迁移热词里还有python装饰器顺手做个对比因为很多人从 Python 转 TS 后容易混淆。Python 装饰器是在函数定义阶段执行返回的通常是函数的包装版本wrapper用于在调用期做前置/后置逻辑。而 TypeScript 装饰器是在类成员定义阶段执行对方法的包装要通过改写descriptor.value实现两者执行时机本质相同、改写的目标形式不同。// TS 中的方法包装 function Throttle(ms: number) { return function (target: any, key: string, descriptor: PropertyDescriptor) { const original descriptor.value; descriptor.value function (...args: any[]) { // 这里可以做节流逻辑 return original.apply(this, args); }; return descriptor; }; }Python 里你用functools.wraps保留原函数的元信息TS 里你也需要注意手动复制descriptor上的所有字段否则可能丢失原有属性。两种语言在装饰器设计上殊途同归原理相通细节不同。6. 面试加分从会语法到讲清设计回顾这一整块知识面试时最能体现深度的不是背出四类装饰器的参数表而是回答出下面这几个为什么为什么设计时类型只支持类、函数、枚举不支持接口因为接口是编译期擦除的纯类型结构没有运行时的构造器可存。为什么装饰器执行在属性定义之前因为 TypeScript 的装饰器要确保在类定义语句求值时所有成员上的元数据都已注册完成供类装饰器读取。为什么 DI 容器需要两级 Map因为第一级 Map 管理类型到提供者的注册表第二级 Map 管理类型到实例的缓存池职责分离才能支持作用域隔离。为什么 NestJS 用Injectable()时不需要传任何参数因为装饰器本身只是触发器真正记录元数据的是Reflect.metadata和编译器在emitDecoratorMetadata下自动注入的design:paramtypes。能把这些链条串起来再随手写出一个最小 DI 容器面试官基本就会认定你是真的写过、真的踩过坑、真的理解设计而不是背熟了文档。装饰器和元数据反射的边界在于它是编译器和运行时之间的桥梁理解这个桥梁你看框架源码就能从这行代码干嘛的上升到为什么框架要这么设计。结合我个人多次做框架层封装的经验最后分享一个判断标准如果你的业务只是页面渲染和数据请求装饰器不是必需品但如果你在写框架、写库、写公共模块装饰器加元数据反射就是最优雅的方案——它把配置和行为解耦让工具可以读懂代码的结构化信息。这个维度的代码增强能力值得你花几个小时系统掌握。
1. 从一次面试聊起装饰器到底在解决什么问题上周有个朋友去面资深前端岗回来跟我吐槽面试官问我装饰器原理我背了语法但他追问我为什么需要元数据反射一下就懵了。这个场景太典型了。TypeScript 装饰器这两年出现的频率越来越高从 NestJS 的依赖注入到 class-validator 的校验声明从 Vue3 的装饰器提案到微前端框架里的注册逻辑到处都能看到它的影子。但大多数人停留在会用 Component 和 Injectable的阶段真要解释清楚这套机制背后的设计逻辑就卡壳了。先把定义摆清楚。装饰器Decorator是 TypeScript 提供的语法特性本质是一个函数用来在编译期对类、方法、属性、参数做标记和包装。元数据反射机制Metadata Reflection则是配合装饰器的一套运行时 API能做到在运行时获取编译期的类型信息。这两个东西合在一起构成了所谓声明式编程的基石——你不需要写一堆命令式的组装代码只需要在类上打几个标记框架就能自动帮你完成注册、校验、注入这些工作。这篇文章我会从装饰器的执行机制讲起重点剖析元数据反射的底层原理然后手写一个完整的依赖注入容器把元数据驱动框架设计这个思路贯通一遍。最后把面试里常见的追问点、实操中的坑都列出来。适合正在用 TypeScript 写业务但想更深入理解框架原理的中高级开发者也适合准备高级前端面试、需要系统梳理装饰器知识体系的同学。先说个题外话现在 TypeScript 官方文档已经明确标注装饰器是试验性特性Experimental但它的应用场景完全谈不上试验——NestJS、Angular、TypeORM 这些主力框架全都建立在装饰器之上。理解这套机制你才算真正读懂了这些框架的设计源头。2. 装饰器的本质一个被安排执行顺序的函数2.1 核心三问装饰器是什么、何时执行、怎么作用装饰器说起来很简单就是一个接收特定参数的函数。比如这样function MyDecorator(target: any, propertyKey?: string, descriptor?: PropertyDescriptor) { // 根据装饰的位置参数有所不同 console.log(装饰器执行了); } MyDecorator class MyClass {}重点在于装饰器的执行时机是类的定义阶段而不是实例化阶段。用原生 JavaScript 的思维方式理解这句话就相当于执行到class MyClass {}这条语句时装饰器函数同步被调用。我们写个例子实测一下function Log(target: any, key: string, descriptor: PropertyDescriptor) { console.log(2. 装饰器内); } console.log(1. 类定义前); Log class Foo { method() {} } console.log(3. 类定义后); new Foo().method(); console.log(4. 实例方法调用后);控制台输出顺序是1. 类定义前 2. 装饰器内 3. 类定义后 4. 实例方法调用后这个顺序揭示了装饰器的本质它就是一个在类被求值evaluate时同步执行的函数。很多人误以为装饰器是在方法调用或实例化时触发这是第一个认知偏差面试时能把这点说清楚已经超出多数候选人了。2.2 四类装饰器的参数差异与执行顺序TypeScript 装饰器分四类类装饰器、方法装饰器、属性装饰器、参数装饰器。参数签名各有不同我把它们罗列成表方便对照记忆装饰器类型第一个参数 target第二个参数第三个参数返回值的作用类装饰器类的构造函数本身无无替换整个构造函数方法装饰器类的原型对象或构造函数静态方法时方法名属性描述符可修改方法实现属性装饰器类的原型对象或构造函数属性名无返回值被忽略无法直接改属性值参数装饰器类的原型对象或构造函数方法名参数索引返回值被忽略这里的细节差异很容易成为面试陷阱。属性装饰器拿不到属性描述符因为属性定义阶段还没有生成描述符所以它只能做标记不能拦截读写。而方法装饰器能拿到descriptor.value这意味着你可以在装饰器里替换掉原来的函数实现这就是 AOP面向切面编程的基础。再看同一类成员上的多个装饰器的执行顺序function First() { console.log(first); } function Second() { console.log(second); } class Foo { First Second method() {} }输出顺序是second然后是first。装饰器从下往上执行越靠近方法的装饰器先执行。类比一下就是穿衣服你先穿最里面的衬衫再穿外套从程序员视角看代码上写在上方的装饰器是外套后执行。而不同类别装饰器的执行顺序是由 TypeScript 编译器安排好的实例属性装饰器、方法装饰器、参数装饰器按成员声明顺序静态属性装饰器、方法装饰器、参数装饰器构造函数参数装饰器类装饰器这个顺序很像工厂里的流水线先把所有零件分别打标成员装饰器最后出厂前再给整机贴标签类装饰器。实际写代码时不需要死记硬背但面试能说出来绝对加分。3. 元数据反射机制运行时如何看到编译期的类型3.1 Reflect.metadata 与设计时类型装饰器本身只是函数真正让它强大的是配套的emitDecoratorMetadata编译选项和reflect-metadata库。这两者结合才构成完整的元数据反射机制。首先在tsconfig.json中开启两个试验性配置{ compilerOptions: { target: ES5, experimentalDecorators: true, emitDecoratorMetadata: true } }然后项目里引入reflect-metadata库import reflect-metadata;为什么要引入这个库因为ECMAScript 原生并没有反射元数据的 API这属于 Stage 2 的提案reflect-metadata是官方提供的 polyfill。它给Reflect对象挂载了metadata、defineMetadata、getMetadata等全局方法。emitDecoratorMetadata开启后TypeScript 编译器会在装饰器执行前自动把三种元数据注册到被装饰的成员上design:type成员属性的类型构造器引用design:paramtypes方法参数的类型列表design:returntype方法的返回类型这段编译后的 JavaScript 看起来是这个样子的// TypeScript 源码 class UserService { getUser(id: number): User { return new User(id); } }编译简化后加了装饰器的情况下会变成// 伪代码展示编译产物 __decorate([ Reflect.metadata(design:type, Function), Reflect.metadata(design:paramtypes, [Number]), Reflect.metadata(design:returntype, User) ], UserService.prototype, getUser, null);这里的关键点是TS 编译器在生成代码时直接把Number和User这种类型信息的构造器constructor作为元数据塞进了 Reflect.运行时框架就能根据这些类型做动态派发和验证。举个非常直观的场景在运行时判断方法第一个参数的构造函数是不是Number可以做参数校验判断属性的构造函数是Array可以做数组嵌套转换。3.2 手动定义元数据的三种姿势除了编译器自动注入的设计时类型你还可以通过Reflect.defineMetadata手动给对象添加任意元数据// 姿势一直接调 API Reflect.defineMetadata(role, admin, User); Reflect.getMetadata(role, User); // admin // 姿势二用装饰器工厂 function Role(role: string) { return function (target: any) { Reflect.defineMetadata(role, role, target); }; }第三种姿势是利用Reflect.metadata装饰器这个写法在 NestJS 源码中很常见Reflect.metadata(roles, [admin, user]) class User {}三种写法的底层都指向defineMetadata区别只在于调用时机和位置。类比到生活里你可以把元数据看成贴在物品上的标签——直接贴defineMetadata、通过专用工具贴装饰器工厂、批量贴Reflect.metadata装饰器。机制一样封装层次不同。3.3 设计时类型到底存了什么别和值类型搞混这条必须单独强调因为我见过太多人在运行时类型判断上栽跟头。设计时类型存的是构造器不是字符串类型名。function TypeInspector(target: any, key: string) { const type: Function Reflect.getMetadata(design:type, target, key); console.log(type String, type Array, type Object); } class Demo { TypeInspector name: string; // true, false, false TypeInspector tags: string[]; // false, true, false }但要注意design:type只看属性声明时的类型注解。如果你只写public data;没标注类型编译器会推断为Object。还有一个特殊现象接口interface作为泛型设计时类型拿到的可能不是你以为的那个具体类型。因为接口在运行时被完全擦除了interface IPage { page: number; } class Paginator { Inspector current: IPage; // design:type 会是 Object而不是 IPage }这就是 TypeScript 类型系统和元数据反射之间的硬边界。面试官如果追问这个边界你能答出来说明你真的踩过坑。4. 实战从零手写一个依赖注入容器4.1 需求拆解为什么 DI 需要元数据反射聊了这么多原理现在落到最核心的应用场景——依赖注入。依赖注入DI是控制反转IoC的一种实现方式核心思路是对象的依赖不由对象自己创建而是由外部容器在实例化时自动注入。如果不靠装饰器传统写法是这样的class UserController { private userService: UserService; constructor() { this.userService new UserService(); // 手动创建依赖 } }问题很明显控制器直接依赖UserService的具体实现一旦构造方式变更所有调用处都要跟着改。用装饰器加元数据反射就能变成声明式的class UserController { Inject private userService: UserService; // 容器自动注入 }要实现这个目标我们需要几个环节配合装饰器在类上标记依赖关系谁需要被注入元数据记录依赖的类型信息需要注入什么类型容器读取元数据拿到类型构造器完成实例化递归处理依赖的依赖Service 里又依赖了 Repository4.2 容器核心实现注册、读取、实例化先实现一个最简版容器支持按标记注册和自动注入。完整代码分三块。第一块是注入装饰器在属性装饰器里读取design:type把类型存入元数据。import reflect-metadata; const INJECT_KEY INJECT_METADATA; export function Inject(target: any, propertyKey: string): void { const type Reflect.getMetadata(design:type, target, propertyKey); if (!type) { throw new Error(无法解析属性 ${propertyKey} 的类型请确认已开启 emitDecoratorMetadata); } Reflect.defineMetadata(INJECT_KEY, type, target, propertyKey); }第二块是Injectable类装饰器注册该类型本身到容器。export function Injectable(): ClassDecorator { return (target: any) { Reflect.defineMetadata(INJECTABLE, true, target); // 收集该类构造函数的参数类型 const paramTypes Reflect.getMetadata(design:paramtypes, target) || []; Reflect.defineMetadata(PARAM_TYPES, paramTypes, target); }; }第三块是容器核心逻辑。这里最关键的一点是容器拿到构造函数后要以递归的方式解析构造参数和属性依赖。export class Container { private providers new Mapstring, any(); private instances new Mapstring, any(); provide(key: string, clazz: any): void { this.providers.set(key, clazz); } resolveT(key: string): T { // 已有实例直接返回实现单例 if (this.instances.has(key)) { return this.instances.get(key); } const clazz this.providers.get(key); if (!clazz) { throw new Error(找不到 ${key} 对应的 Provider); } const paramTypes Reflect.getMetadata(PARAM_TYPES, clazz) || []; const params paramTypes.map((paramType: any) { // 构造器参数注入 return this.resolveForType(paramType); }); const instance new clazz(...params); this.instances.set(key, instance); // 属性注入 for (const prop of Object.keys(instance)) { const propInjectable Reflect.getMetadata(INJECT_KEY, instance, prop); if (propInjectable) { instance[prop] this.resolveForType(propInjectable); } } return instance as T; } private resolveForType(type: any): any { const matchedName [...this.providers.keys()] .find(name this.providers.get(name) type); if (!matchedName) { throw new Error(依赖类型 ${type.name} 未注册到容器); } return this.resolve(matchedName); } }代码里的resolveForType处理了一个关键问题元数据存储的是类型构造器但容器按字符串 key 管理 provider因此需要先找到 key 再调resolve。这一层间接是 DI 容器的技术核心很多手写 DI 的方案都在这步做文章。4.3 验证容器和参数计算过程写一段完整的使用示例把上面的容器跑起来Injectable() class UserRepository { findById(id: number) { return { id, name: 张三 }; } } Injectable() class UserService { constructor(private repo: UserRepository) {} } Injectable() class UserController { Inject private userService!: UserService; getById(id: number) { return this.userService.repo.findById(id); } } const container new Container(); container.provide(UserRepository, UserRepository); container.provide(UserService, UserService); container.provide(UserController, UserController); const controller container.resolveUserController(UserController); console.log(controller.getById(1)); // { id: 1, name: 张三 }这个例子虽然简单但已经覆盖了三个注入场景构造器参数注入Service 依赖 Repository、属性注入Controller 依赖 Service、单例缓存resolve 两次拿到同一实例。还有一个细节值得注意UserController里我用了非空断言userService!: UserService因为 TypeScript 的严格属性初始化检查会报错。这也解释了为什么很多框架文档里都建议开启strictPropertyInitialization: false或者用!标记——装饰器注入本质上是运行时赋值编译器在这个场景下无法静态分析。4.4 两级缓存的设计意图上面的instancesMap 就是一级缓存保证每个 Provider 在整个容器生命周期内只创建一次实例。这在工程上是必要的因为依赖对象可能持有数据库连接池或 HTTP 客户端重复创建会有严重的资源浪费。但单例缓存也有问题resolve返回的永远是同一个引用如果某些场景需要每次新建实例比如多租户上下文隔离就要在容器里加二级配置。更复杂的容器会维护瞬时作用域和请求作用域这超出了本文范围但思路是一样的用 Map 管理不同作用域下的实例缓存。5. 常见问题与避坑记录5.1 属性初始化顺序装饰器注解被覆盖了这个坑我踩过不止一次。看下面的代码class User { Inject service: UserService new UserService(); // 手动初始化会覆盖注入 }属性装饰器的执行时机在构造函数执行之前但属性初始化赋值语句 new UserService()在构造函数内部运行执行顺序靠后。结果就是装饰器刚注入好的实例立刻被赋值表达式的执行结果覆盖了。这就是为什么 DI 模式下要求把属性初始化的工作完全交给容器不要自己手动赋值。同理Object.defineProperty在装饰器阶段定义属性时writable和configurable的默认值在 ES5 和 ES6 目标下是不同的如果你同时操作描述符很容易踩到意外的表现差异。5.2 忘记开启编译选项design:type 取不到这是最常见的报错Reflect.getMetadata(design:type, ...) 返回 undefined。原因基本都是没在tsconfig.json里开emitDecoratorMetadata。检查顺序建议这样排查确认experimentalDecorators和emitDecoratorMetadata都设为true确认项目里import reflect-metadata在入口文件最先引入确认target不是ESNext个别版本下emitDecoratorMetadata对 ESNext target 支持不完整确认装饰器函数里用到的是getMetadata而不是getOwnMetadata——后者不会读取原型链上的元数据绝大多数场景用前者5.3 类型手柄Token冲突与循环依赖当两个类都注册到了容器但类型本身又在别处被复用字符串 key 管理方式很容易撞名。生产级 DI 框架更常见的方式是直接以类型构造器作为 key不经过字符串中转。这样既免了撞名问题也免了resolveForType里的命名查找。改造也简单把Mapstring, any换成MapFunction, any就行。循环依赖的排查A 构造函数依赖 BB 构造函数又依赖 A会导致resolve无限递归爆栈。方案是在resolve入口先检查实例是否已处于创建流程private resolving new Setstring(); resolveT(key: string): T { if (this.resolving.has(key)) { throw new Error(检测到循环依赖: ${key}); } this.resolving.add(key); try { // ...实例化逻辑 } finally { this.resolving.delete(key); } }5.4 Vue3 与装饰器的现实关系热词里出现了vue3 装饰器这里多说一句。Vue3 官方在 class API 方案上推进过装饰器路线但最终选择了 Composition API script setup的语法很大程度上是因为class 语法配合装饰器在类型推导上远不如函数式组合灵活。函数组合天然能推导出响应式变量的精确类型而装饰器注入的props往往是运行时才知道的。这意味着什么如果你在 Vue3 里找装饰器的大量使用场景主力还是 Element Plus、Ant Design Vue 这些组件库内部业务侧用装饰器写defineComponent的封装很少见。相比之下NestJS 的 controller/service/provider 体系、TypeORM 的实体定义才是装饰器的主战场。这个信息在面试时能体现你对社区技术选型的真实观察。5.5 Python 装饰器的心智模型迁移热词里还有python装饰器顺手做个对比因为很多人从 Python 转 TS 后容易混淆。Python 装饰器是在函数定义阶段执行返回的通常是函数的包装版本wrapper用于在调用期做前置/后置逻辑。而 TypeScript 装饰器是在类成员定义阶段执行对方法的包装要通过改写descriptor.value实现两者执行时机本质相同、改写的目标形式不同。// TS 中的方法包装 function Throttle(ms: number) { return function (target: any, key: string, descriptor: PropertyDescriptor) { const original descriptor.value; descriptor.value function (...args: any[]) { // 这里可以做节流逻辑 return original.apply(this, args); }; return descriptor; }; }Python 里你用functools.wraps保留原函数的元信息TS 里你也需要注意手动复制descriptor上的所有字段否则可能丢失原有属性。两种语言在装饰器设计上殊途同归原理相通细节不同。6. 面试加分从会语法到讲清设计回顾这一整块知识面试时最能体现深度的不是背出四类装饰器的参数表而是回答出下面这几个为什么为什么设计时类型只支持类、函数、枚举不支持接口因为接口是编译期擦除的纯类型结构没有运行时的构造器可存。为什么装饰器执行在属性定义之前因为 TypeScript 的装饰器要确保在类定义语句求值时所有成员上的元数据都已注册完成供类装饰器读取。为什么 DI 容器需要两级 Map因为第一级 Map 管理类型到提供者的注册表第二级 Map 管理类型到实例的缓存池职责分离才能支持作用域隔离。为什么 NestJS 用Injectable()时不需要传任何参数因为装饰器本身只是触发器真正记录元数据的是Reflect.metadata和编译器在emitDecoratorMetadata下自动注入的design:paramtypes。能把这些链条串起来再随手写出一个最小 DI 容器面试官基本就会认定你是真的写过、真的踩过坑、真的理解设计而不是背熟了文档。装饰器和元数据反射的边界在于它是编译器和运行时之间的桥梁理解这个桥梁你看框架源码就能从这行代码干嘛的上升到为什么框架要这么设计。结合我个人多次做框架层封装的经验最后分享一个判断标准如果你的业务只是页面渲染和数据请求装饰器不是必需品但如果你在写框架、写库、写公共模块装饰器加元数据反射就是最优雅的方案——它把配置和行为解耦让工具可以读懂代码的结构化信息。这个维度的代码增强能力值得你花几个小时系统掌握。
