JavaScript虽无原生注解，但通过JSDoc、装饰器提案及框架扩展可实现类似功能：1. JSDoc用于类型提示与文档生成；2. 装饰器（Stage 3）修饰类成员行为；3. 框架如NestJS利用装饰器定义元数据；4. 构建工具识别特殊注释优化打包。
JS注解（JavaScript 注解）这个说法在实际开发中容易引起误解，因为 JavaScript 本身并不原生支持像 Java 或 TypeScript 中那样的“注解”（Annotation）语法。但结合现代前端生态和工具链，我们可以理解为：通过特定语法标记（如 JSDoc 注释、装饰器提案等），实现类似“注解”的功能。这些机制虽不改变运行逻辑，但能显著提升代码可读性、类型检查能力和框架集成能力。
JSDoc 注释：增强类型提示与文档生成
虽然不是真正的注解，JSDoc 是 JavaScript 中最接近“注解”用途的实践方式。它通过结构化注释为变量、函数、类添加元信息。
- 提供类型提示，在 VSCode 等编辑器中实现智能补全
- 配合 TypeScript 使用，即使在 .js 文件中也能启用类型检查
- 生成项目 API 文档，便于团队协作
- 标注参数是否可选、返回值类型、抛出异常等信息
/\*\*
\* 计算两个数的和
\* @param {number} a - 第一个加数
\* @param {number} b - 第二个加数
\* @returns {number} 和值
\*/
function add(a, b) {
return a + b;
}
装饰器（Decorators）：实验性但功能强大
JavaScript 正在推进的 Decorator 提案（目前处于 Stage 3）允许开发者以声明式方式修改类及其成员行为，这更接近传统意义上的“注解”。
- 用于拦截方法调用，实现日志、权限控制、性能监控
- 自动绑定 this 到类方法，避免上下文丢失
- 在 Angular、NestJS 等框架中广泛使用，标识组件、注入依赖
- 简化重复逻辑，提升代码复用性
@logMethodCalls
class UserService {
@readonly
getName() { return "Alice"; }
}
框架中的“伪注解”：元数据驱动开发
一些框架利用字符串标记或特殊注释引导代码生成或运行时行为，这类“注解”常用于构建流程中解析。
- React Native 中的
// @flow或// @ts-check启用类型检查 - Webpack 的 magic comments 控制代码分割，如
/* webpackChunkName: "admin" */ - NestJS 使用装饰器定义路由、控制器、中间件，形成清晰的结构化代码
静态分析与构建优化辅助
注解类标记还能被工具链识别，用于优化打包、启用特性或条件编译。
- Pure 注释帮助 Webpack 标记副作用，进行 tree-shaking
- 条件编译注释（如 Closure Compiler 的
@export）控制输出内容 - Linter 自定义规则可通过特定注释关闭/开启检测
基本上就这些。JS 本身没有运行时注解机制，但通过 JSDoc、装饰器、框架扩展和构建工具配合，已经能实现类型增强、行为修饰、自动化处理等多种“注解式”功能。掌握这些技巧，有助于写出更健壮、易维护的 JavaScript 代码。
