装饰器是运行时函数劫持，非语法糖；它通过修改object.defineproperty行为重写类成员描述符，在类定义完成时执行，不支持普通函数声明，需编译支持且多装饰器自下而上覆盖。
装饰器不是语法糖，是运行时函数劫持
JavaScript 装饰器（@ 语法）目前仍处于 Stage 3 提案阶段，**原生不支持**。你看到的 @log、@debounce 等写法，必须配合 Babel（@babel/plugin-proposal-decorators）或 TypeScript 编译才能生效。直接在浏览器控制台敲 @memoize function foo() {} 会报 SyntaxError: Unexpected token '@'。
本质是：装饰器是一个接收目标、属性名、描述符的函数，它返回一个新描述符（或修改原描述符），从而改变函数行为。不是“加一层壳”，而是重写 Object.defineProperty 的行为。
- 类方法装饰器参数顺序固定：
target, propertyKey, descriptor - 装饰器执行时机在类定义完成但实例未创建时，**不是每次调用函数时执行**
- Babel 默认使用 legacy 模式（类似 TS 的旧行为），若要匹配提案最新语义，需显式配置
decoratorsBeforeExport: true
手写 @throttle 装饰器要注意 this 和参数透传
节流装饰器常被误写成只处理无参函数。实际中，被装饰的方法往往依赖 this 上下文和不定参数，漏掉这两点会导致 TypeError: Cannot read property 'xxx' of undefined 或参数丢失。
正确写法必须显式绑定 this 并展开参数：
立即学习“Java免费学习笔记（深入）”；
function throttle(ms) {
return function(target, prop, descriptor) {
const fn = descriptor.value;
let lastTime = 0;
descriptor.value = function(...args) {
const now = Date.now();
if (now - lastTime >= ms) {
fn.apply(this, args); // ← 关键：this 和 args 都要透传
lastTime = now;
}
};
};
}- 不能用箭头函数重写
descriptor.value，否则this指向丢失 - 不要在装饰器内部直接调用
fn()，那会脱离原始调用上下文 - 如果装饰的是 getter/setter，要用
descriptor.get或descriptor.set，而非value
装饰器无法修饰普通函数声明，只能用于类成员或导出函数
你不能这样写：
@log
function apiCall() { ... }这在任何环境下都不合法。ECMAScript 装饰器规范**只允许用于类元素**（方法、访问器、字段）或模块级导出声明（如 export @memoize function fetchData() {}）。想给独立函数加能力，有两个务实选择：
- 改用高阶函数：
const throttledFetch = throttle(300)(fetchData) - 把函数包进类里再装饰：
class Api { @throttle(300) fetch() { ... } } - TypeScript 用户可启用
experimentalDecorators+emitDecoratorMetadata，但仅限编译期支持，运行时仍靠 polyfill
多个装饰器叠加时，执行顺序容易反直觉
写成这样：
@A
@B
@C
method() {}实际执行顺序是 C → B → A（从下到上），但每个装饰器对 descriptor.value 的修改是**累积覆盖**的。比如：
@log 把 value 改成带日志的包装函数；@throttle 又把它替换成节流版——最终生效的是最上面那个装饰器返回的描述符。
- 装饰器之间无自动组合逻辑，不会自动形成“日志+节流”复合行为
- 若需组合，应手动封装：
@compose(log, throttle(200))，或让一个装饰器接受多个中间件函数 - React 中的
connect+memo类装饰器组合，本质是 HOC 嵌套，和原生装饰器机制无关
真正麻烦的从来不是语法怎么写，而是搞清「谁在什么时候、以什么上下文、修改了哪一段描述符」。装饰器不是魔法，它是明确的元编程操作——每一步都得对得上 Object.getOwnPropertyDescriptor 返回的东西。
