JavaScript装饰器提案处于Stage 3，语法稳定，TypeScript 5.0+和Babel已支持。其元数据功能通过函数包装、静态分析、构造函数替换和元数据存储实现，用@decorator语法将配置与业务逻辑分离，提升可读性和复用性。
JavaScript 装饰器提案目前处于 Stage 3 阶段。这表示该提案已经解决了主要的设计问题，语法和核心功能基本稳定，正等待进一步的实现反馈以最终成为正式标准。尽管尚未被所有浏览器原生支持，但 TypeScript 5.0+ 和 Babel 等工具已提供实验性或准正式的支持，允许开发者在项目中提前使用。
元数据功能如何工作
装饰器的元数据功能通过在类或其成员（方法、属性、访问器）上“附加”额外信息来实现，这些信息可以在运行时被检查或用于改变行为。它本质上是一种元编程技术，不直接修改原始代码逻辑，而是通过包装或注入的方式扩展功能。
- 函数包装：最常见的模式是装饰一个方法。装饰器接收目标对象、属性名和属性描述符（descriptor），然后可以包装原始方法（例如，在执行前后添加日志、性能监控或权限检查），最后返回修改后的描述符。
-
静态分析与类型扩展：结合 TypeScript 使用时，装饰器可以为类或成员添加类型信息或标记。框架（如 Angular）利用这一点，通过
@Component或@Injectable这样的装饰器告诉编译器或运行时系统这个类的用途和配置，从而自动进行依赖注入或DOM渲染。 - 构造函数替换：类装饰器作用于整个类。它接收类的构造函数作为参数，并可以返回一个新的构造函数或类定义，从而修改类的整体行为，比如自动生成注册信息或将所有实例属性变为响应式。
- 元数据存储：一些库（如 Reflect Metadata）允许装饰器将任意数据（元数据）关联到类或成员上。之后，其他代码可以通过反射 API 读取这些数据，实现诸如路由映射、序列化规则或验证逻辑的自动化。
基本上就这些，核心就是用声明式的 @decorator 语法，把附加逻辑和配置从主业务代码中剥离出来，提升代码的可读性和复用性。虽然标准落地还在推进，但开发实践已经相当成熟。
