JavaScript代码规范是通过ESLint等工具落地的工程实践，非语法强制；ESLint可自动检查潜在bug与风格问题，支持环境配置、规则继承、解析器与插件协同，并集成至编辑器、Git钩子及CI流程。
JavaScript 代码规范是团队协作中统一代码风格、提升可读性与可维护性的约定，不是语法强制要求，而是通过工具（如 ESLint）落地执行的工程实践。ESLint 是目前最主流的 JavaScript/TypeScript 代码检查工具，它不只查语法错误，更关注潜在 bug、不一致写法和不良习惯。
为什么需要 ESLint 而不只是靠人盯？
人工 Code Review 难以覆盖缩进、分号、变量命名、未使用变量等细节，容易疲劳遗漏；而 ESLint 可在编辑器实时提示、提交前自动拦截，把“风格讨论”变成“自动修复”。它本身不规定规则，靠配置驱动——你选什么规则、怎么配，决定了代码长什么样。
核心配置方式：从 .eslintrc.js 开始
项目根目录下新建 .eslintrc.js，这是最灵活的配置形式（支持 JS 逻辑，可动态判断环境）。基础结构如下：
module.exports = {
env: {
browser: true,
es2021: true,
node: true
},
extends: [
'eslint:recommended',
'plugin:react/recommended',
'plugin:@typescript-eslint/recommended'
],
parser: '@typescript-eslint/parser',
plugins: ['react', '@typescript-eslint'],
rules: {
'no-console': 'warn',
'no-unused-vars': ['error', { argsIgnorePattern: '^_' }],
indent: ['error', 2],
quotes: ['error', 'single']
}
};
立即学习“Java免费学习笔记（深入）”；
- env 告诉 ESLint 当前运行环境（浏览器？Node？ES 版本？），影响全局变量识别（比如 window、process 是否合法）
-
extends 复用成熟规则集，推荐组合：
eslint:recommended（基础安全项）+ 框架插件（如 React/Vue）+ 类型插件（TS） -
parser & plugins 必须配对：用 TS 就要
@typescript-eslint/parser和@typescript-eslint插件；用 JSX 就要react插件 -
rules 是最终裁决层，格式为
[severity, ...options]，severity 可选'off'、'warn'、'error'
常用规则举例与实用建议
不必一上来就全开，优先解决高频痛点：
-
缩进与空格：
indent: ['error', 2]统一用 2 空格；禁用 tab（设no-tabs: 'error'） -
分号：推荐关闭（
semi: ['off']），配合prettier自动格式化，避免争议 -
变量声明：
no-var: 'error'强制用const/let；prefer-const: 'warn'提示可改 const 的地方 -
解构与默认值：
prefer-destructuring: ['error', { object: true, array: false }]控制对象解构启用、数组按需 -
禁止 console：
no-console: process.env.NODE_ENV === 'production' ? 'error' : 'warn'生产环境直接报错
集成到开发流：保存即检查 + 提交前卡点
光有配置不够，得让它真正起作用：
- 编辑器内联提示：VS Code 安装 ESLint 插件，打开项目自动读取配置，错误直接标红
-
保存自动修复：在 VS Code 设置中开启
"editor.codeActionsOnSave": { "source.fixAll.eslint": true } -
Git 提交拦截：用
husky + lint-staged，只检查暂存区文件，避免全量扫描拖慢速度 -
CI 检查：在 GitHub Actions 或 Jenkins 中加一步
npx eslint src/ --ext .js,.ts，失败则阻断发布
基本上就这些。ESLint 配置不复杂但容易忽略细节——关键不在堆规则，而在选准团队共识的几条，配稳 parser 和插件，再串进日常流程。跑起来之后，代码会自己“说话”，人反而更轻松。
