JavaScript装饰器是Stage 3提案，需Babel或TypeScript编译；本质是接收目标、属性名、描述符的高阶函数，执行于类定义阶段，支持类/方法装饰、元数据注入及横切逻辑剥离，但依赖框架或构建链路支撑。
JavaScript 装饰器目前仍是 Stage 3 提案（截至 2025 年），未被所有运行时原生支持，class 和 method 上的装饰器需通过 Babel（如 @babel/plugin-proposal-decorators）或 TypeScript 编译才能使用；原生环境直接写 @log 会报 SyntaxError: Unexpected token '@'。
装饰器本质是高阶函数
装饰器不是语法糖，而是接收目标、属性名、描述符等参数的函数。类装饰器接收 constructor，方法装饰器接收 target、propertyKey、descriptor —— 这决定了它能做什么：重写方法逻辑、拦截调用、注入元数据。
- 类装饰器形如
function logClass(target) { console.log(target); }，必须返回void或新构造函数（后者会替换原类） - 方法装饰器中修改
descriptor.value是最常见操作，比如包裹原函数实现日志或防抖 - 装饰器执行时机在类定义阶段，而非实例化时；所以无法访问
this（除非在闭包内捕获）
TypeScript 中启用装饰器要配两个开关
TypeScript 默认禁用装饰器，仅开启 "experimentalDecorators": true 不够，还必须同时设 "emitDecoratorMetadata": true 才能生成反射元数据（供 reflect-metadata 库读取）。否则 Reflect.getMetadata 总返回 undefined。
- Babel 用户需确保插件配置含
legacy: false（对应提案新语法）或legacy: true（兼
容旧写法），二者行为差异大
- Vite 项目需额外安装
@rollup/plugin-replace或配置define，否则Reflect在生产环境可能未注入 - 装饰器函数内部若用了
async，要注意返回的是 Promise，而装饰器期望同步返回描述符，需用descriptor.value = async function() {...}显式包裹
真实可用的场景就那几个
别被“AOP”“元编程”唬住。真正稳定落地的只有：自动注册路由（NestJS）、权限校验（@Roles('admin')）、状态缓存（@Memoize）、参数校验（@Validate）。这些都依赖运行时反射 + 框架统一拦截，纯前端手写装饰器几乎只用于开发期辅助（如 @Deprecated 打印警告）。
-
@Component类装饰器本质是往类上挂静态属性，框架启动时扫描并收集 - 方法装饰器加
@UseGuards(AuthGuard)后，实际生效靠框架在调用前检查guards数组并逐个执行 - 想用装饰器做性能监控？得配合
performance.mark()+ 自定义 descriptor，且注意不要污染原始this上下文
装饰器的价值不在语法多炫，而在把横切关注点从业务逻辑里剥离开；但剥离的前提是有一套运行时基础设施兜底——没有框架或构建链路支撑，单写一个 @log 只是徒增维护成本。
