javascript原生不支持装饰器，因其仍为stage 3提案；typescript通过编译转译实现，需启用experimentaldecorators等配置，适用于权限、日志等横切关注点，但非银弹。
JavaScript 的装饰器（@decorator）目前仍是 Stage 3 提案，**尚未正式进入 ECMAScript 标准**。你在 TypeScript 或 Babel 项目里看到的 @ 语法，依赖的是编译器层面的支持，不是原生 JS 运行时能力。
装饰器在 TypeScript 中怎么写、怎么生效
TypeScript 把装饰器当作一种“语法糖”，在编译阶段把它转成普通函数调用。它本质是接收目标对象（类、方法、属性等）并返回修改后结构的高阶函数。
启用前必须在 tsconfig.json 中打开两个开关：
"experimentalDecorators": true-
"emitDecoratorMetadata": true（如果要用反射元数据）
常见写法示例：
立即学习“Java免费学习笔记（深入）”；
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-metadatapolyfill 并配合编译器 - 像 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，这种方式：
- 不依赖编译配置
- 类型推导更稳定（装饰器对泛型支持仍有限）
- 可读性更高：一眼看出谁被包装、怎么包装
- 便于动态启用/禁用（装饰器是静态的）
装饰器不是银弹。它在框架层封装公共契约很有用，但在业务代码里，先问一句：“这个逻辑真的需要‘声明式贴标签’，还是直接调用函数更清楚？”
