JavaScript原生不支持装饰器，因其仍为Stage 3提案；TypeScript通过编译转译实现，需启用experimentalDecorators等配置，适用于权限、日志等横切关注点，但非银弹。

JavaScript 的装饰器（@decorator）目前仍是 Stage 3 提案，**尚未正式进入 ECMAScript 标准**。你在 TypeScript 或 Babel 项目里看到的 @ 语法，依赖的是编译器层面的支持，不是原生 JS 运行时能力。

装饰器在 TypeScript 中怎么写、怎么生效

TypeScript 把装饰器当作一种“语法糖”，在编译阶段把它转成普通函数调用。它本质是接收目标对象（类、方法、属性等）并返回修改后结构的高阶函数。

启用前必须在 tsconfig.json 中打开两个开关：

• "experimentalDecorators": true
• "emitDecoratorMetadata": true（如果要用反射元数据）

常见写法示例：

function readonly(target: any, propertyKey: string, descriptor: PropertyDescriptor) {
  descriptor.writable = false;
}

class User {
  @readonly
  name = "Alice";
}

注意：descriptor 参数只在方法/访问器装饰器中存在；字段装饰器（如 @readonly 修饰 name）实际接收的是 target 和 propertyKey，不带 descriptor —— 这是很多人踩坑的地方。

为什么原生 JavaScript 不支持 @ 装饰器

V8、SpiderMonkey 等引擎至今未实现提案中的运行时语义。即使你用 Babel 编译出装饰器代码，最终也是转为 Object.defineProperty 或闭包包裹逻辑，**没有真正的“运行时装饰器注册表”或元编程钩子**。

这意味着：

• 无法在浏览器控制台直接定义 @log 并使用
• Reflect.getMetadata() 在纯 JS 环境下无意义，除非你手动引入 reflect-metadata polyfill 并配合编译器
• 像 Angular 的 @Component 或 NestJS 的 @Get() 全部依赖构建时静态分析，不是 JS 引擎执行出来的

哪些场景真正适合用装饰器

装饰器的价值不在语法炫技，而在**收敛横切关注点 + 减少样板代码**。适用前提是：项目已用 TypeScript + 构建工具链，且团队接受编译期增强语义。

典型可用场景包括：

• 权限控制：比如 @RequireRole('admin') 自动拦截方法调用
• 日志埋点：在方法前后注入计时、参数打印逻辑
• 状态管理绑定：如 MobX 的 @observable、@action，把字段行为声明化
• API 请求封装：NestJS 中 @Query()、@Body() 解构请求数据

但要注意：过度使用会让调用链变隐晦，调试时看不到原始方法体；单元测试也得 mock 装饰器副作用，而不是只测业务逻辑。

替代方案比硬上装饰器更轻量

如果你只是想复用逻辑，函数组合或高阶函数往往更透明：

const withLogging = (fn: Function) => (...args: any[]) => {
  console.time(fn.name);
  const result = fn(...args);
  console.timeEnd(fn.name);
  return result;
};

const getData = withLogging(() => fetch('/api/data'));

相比 @Log，这种方式：

• 不依赖编译配置
• 类型推导更稳定（装饰器对泛型支持仍有限）
• 可读性更高：一眼看出谁被包装、怎么包装
• 便于动态启用/禁用（装饰器是静态的）

装饰器不是银弹。它在框架层封装公共契约很有用，但在业务代码里，先问一句：“这个逻辑真的需要‘声明式贴标签’，还是直接调用函数更清楚？”