javascript原生不支持装饰器语法，@decorator会报错因v8等引擎尚未实现该stage 3提案；元编程主要靠proxy、reflect等实现，高阶函数是无需编译的稳妥替代方案。
JavaScript 中目前没有原生稳定的装饰器语法（@decorator）可供生产环境直接使用，它仍处于 Stage 3 提案阶段，需依赖 Babel 或 TypeScript 编译支持；所谓“元编程”在 JS 中主要通过 Proxy、Reflect、Object.defineProperty 等机制实现，而非 Python 那类完整的运行时类型/结构干预能力。
为什么直接写 @log 会报错？
浏览器和 Node.js 原生 JavaScript 引擎（V8、SpiderMonkey）尚未实现装饰器提案。你看到的 @ 语法只能在以下情况工作：
- 使用
@babel/plugin-proposal-decorators并配置legacy: true（兼容旧版装饰器行为）或version: "2023-11"（匹配新提案） - TypeScript 项目中开启
"experimentalDecorators": true，但编译后会转为普通函数调用，不保留装饰器语义 - 直接在未编译的 .js 文件里写
@，必定触发SyntaxError: Unexpected token '@'
Proxy 是 JS 最实用的元编程工具
它不修改原对象，而是拦截并重定义基本操作（如读取、赋值、构造），适合做日志、校验、响应式封装等。注意：无法代理普通函数或基本类型，且性能开销比直接访问高 2–5 倍。
const handler = {
get(target, prop) {
console.log(`Getting ${prop}`);
return Reflect.get(target, prop);
},
set(target, prop, value) {
if (prop === 'age' && typeof value !== 'number') {
throw new TypeError('age must be a number');
}
return Reflect.set(target, prop, value);
}
};
const user = new Proxy({ name: 'Alice', age: 30 }, handler);
user.age = 31; // OK
user.age = '31'; // TypeError
用高阶函数模拟装饰器行为（无编译依赖）
这是最稳妥、可直接运行在任何环境的替代方案。核心是把“装饰逻辑”抽成函数，接收目标函数/类并返回增强后的新函数/类。
立即学习“Java免费学习笔记（深入）”；
- 装饰方法：传入函数，返回包装后的新函数（常用于日志、节流、权限检查）
- 装饰类：传入类构造器，返回新类（可用于自动注册、添加静态属性、混入方法）
- 避免修改原函数的
this绑定 —— 用fn.apply(this, arguments)或箭头函数保持上下文
function logCalls(fn) {
return function(...args) {
console.log(`Calling ${fn.name} with`, args);
const result = fn.apply(this, args);
console.log(`${fn.name} returned`, result);
return result;
};
}
class Calculator {
add(a, b) { return a + b; }
}
Calculator.prototype.add = logCalls(Calculator.prototype.add);
容易被忽略的关键限制
装饰器提案本身对“类字段初始化时机”、“私有字段访问”、“装饰器执行顺序”仍有争议，不同编译器行为不一致。例如：
- Babel legacy 模式下，
@decorator修饰字段会提前执行，可能访问到undefined的this - TypeScript 的
experimentalDecorators不支持装饰私有成员（#field），会报错 -
Proxy无法拦截in操作符对私有字段的检测，也无法代理WeakMap键
真要元编程，先确认你的运行时环境是否支持所需 API，再决定用 Proxy、高阶函数，还是引入 Babel/TS 编译链 —— 别让装饰器语法成了第一个阻塞上线的问题。
