装饰器标准落地意味着什么？

最近在技术群里，大家都在聊“装饰器标准落地”。有的同事一听到“装饰器”，立刻想到老版本的 @Component 那套写法；有的则担心升级后会不会把现有代码全砸了。其实，这事儿跟我们平时写业务代码的日常关系挺大，尤其是那些靠装饰器实现依赖注入、路由注册或者数据校验的项目。

装饰器标准到底干了啥？

从技术层面看，装饰器已经从 TypeScript 的实验特性变成了 ECMAScript 正式提案，浏览器、Deno 甚至 Node.js（通过原生支持）都能直接识别。换句话说，装饰器不再是编译器自己“偷偷”把代码改写，而是运行时原生执行的元编程工具。它带来的最大变化是：

• 装饰器的调用顺序和上下文对象（context）与标准保持一致，能拿到方法名、属性键等元信息。
• 装饰器的返回值会直接影响目标对象的行为，像 defineProperty 那样在运行时生效。
• 不再需要 experimentalDecorators 编译选项，旧版装饰器代码如果不做改动会报错。

老项目的搬家攻略

面对已经上线的业务，直接把装饰器切换成新标准会有点手足无措。下面是一套实战经验，帮助大家把坑踩得更少：

• 先把 tsconfig.json 里 "experimentalDecorators" 设为 false，让编译器报出不兼容的地方。
• 把装饰器函数的签名改成标准形式：(target, context) => { … }，其中 context 会提供 name、kind 等属性。
• 把原来依赖 Reflect.metadata 的写法改成直接在装饰器里返回元数据对象，IDE 能即时提示。
• 跑一遍单元测试，特别是那些自动注册路由或模型的模块，确保装饰器执行顺序没有被意外打乱。

业务层面的直接收益

标准装饰器把“编译时的魔法”搬到了运行时，这让我们在跨平台（前端、后端、Deno）之间复用同一套代码成为可能。举个最常见的例子，使用 @Entity 标记一个类，框架能在启动时自动读取类的属性类型并生成对应的数据库表结构；在浏览器里，同样的装饰器还能帮我们把表单字段映射成验证规则，省去手写校验函数的步骤。

// 简单的日志装饰器（符合 ECMAScript 标准）
function Log(target, context) {
  const methodName = String(context.name);
  return function (...args) {
    console.log(`调用 ${methodName}`, args);
    const result = target.apply(this, args);
    console.log(`返回 ${methodName}`, result);
    return result;
  };
}

class Calc {
  @Log
  add(a, b) {
    return a + b;
  }
}

“装饰器正式上路后，我把之前写的七层嵌套验证器全部删了，直接靠装饰器把规则写在模型里，代码行数直接从 200 行压到不到 80 行。”——一线前端工程师小张

说白了，这波标准化让装饰器从“偷偷摸摸的实验玩意”变成了“大家都能直接用的官方工具”。如果你正好在为项目的元数据、跨模块注入或者运行时校验头疼，赶紧把目光投向这套新装饰器吧，省时省力的感觉，真的很爽。