JavaScript装饰器是Stage 3提案特性，非ECMAScript 2024标准语法，需Babel或TypeScript编译；用@符号标记类/方法等，本质是接收target、propertyKey、descriptor等参数的函数调用语法糖。
JavaScript 装饰器不是当前标准语法（ECMAScript 2024），而是处于 Stage 3 提案阶段的实验性特性，需通过 Babel 或 TypeScript 启用；直接在原生环境运行会报 SyntaxError: Decorator is not supported。
装饰器语法在 JS 中怎么写？
它用 @ 符号标记，紧贴在类、方法、访问器或参数前，本质是函数调用的语法糖。Babel 编译后，@log 会被转为对 log 函数的调用，并传入目标对象、属性名、描述符等元数据。
常见写法示例：
function readonly(target, propertyKey, descriptor) {
descriptor.writable = false;
return descriptor;
}
class User {
@readonly
getName() {
return 'Alice';
}
}
注意：类装饰器接收 constructor，方法装饰器接收三个参数（target, propertyKey, descriptor），这和 Object.defineProperty 的参数顺序一致。
立即学习“Java免费学习笔记（深入）”；
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
为什么直接用原生 JS 会报错？
因为 V8 和 SpiderMonkey 引擎尚未实现提案，Chrome / Node.js 默认禁用该语法。即使写了 @deprecated，也会触发解析失败，而非运行时警告。
- Node.js 需加
--harmony-decorators（仅旧版 v16~v18 有限支持，已移除） - Babel 需配置
@babel/plugin-proposal-decorators并设legacy: true - TypeScript 需开启
"experimentalDecorators": true且不启用"useDefineForClassFields"（否则与装饰器冲突）
装饰器增强类/方法的实际用途有哪些？
它不修改原有逻辑，而是在不侵入源码前提下注入横切关注点，比如日志、权限、缓存——但必须依赖编译时转换，无法纯运行时动态添加。
典型场景包括：
-
@autobind：自动绑定类方法中的this，避免 React 类组件中手动bind -
@throttle(300)：节流装饰器，包装方法使其固定间隔最多执行一次 -
@validate({ name: String, age: Number })：参数校验，作用于方法参数（需配合reflect-metadata） -
@singleton：类装饰器，拦截构造调用，确保全局唯一实例
所有这些都依赖装饰器函数返回新的描述符或构造器，而不是“增强”原方法本身——它只是替换了定义行为。
容易被忽略的关键限制
装饰器不能用于普通函数声明（如 function foo() {}），也不能用于变量或表达式；它只作用于静态定义的类成员。更隐蔽的问题是：若多个装饰器叠加（@A @B method()），执行顺序是自下而上（B 先于 A），和数组 [A, B].reduceRight 行为一致——这点常被误认为从上到下。
