代码是写给人阅读的，而一致性是保证可读性的关键。ESLint 作为 JavaScript 生态中最主流的静态代码分析工具，通过在代码运行之前检查源代码中的潜在错误、代码风格问题和不符合约定规范的模式，帮助团队维持统一的代码质量。它的核心价值在于：尽早发现问题，把 bug 扼杀在摇篮里，同时减少 Code Review 中因代码风格引发的争论。
23.1.1 快速上手：安装与初始化
在一个已有项目中，通过 npm 安装 ESLint：
npm install eslint --save-dev然后通过交互式向导初始化配置文件：
npx eslint --init向导会询问几个问题，比如是否使用 ES Modules、框架类型（React / Vue / 无）、项目环境（浏览器 / Node 等）、期望的代码风格，最后生成一个 .eslintrc.* 配置文件。常见的配置文件格式有 .eslintrc.js（JavaScript 导出）、.eslintrc.json、.eslintrc.yaml，也可以直接在 package.json 的 eslintConfig 字段中配置。现在提倡使用扁平化配置（使用 eslint.config.js），但对于大多数既有项目，传统配置依然是主流。
23.1.2 规则体系：内置规则与共享配置
ESLint 自带超过 300 条内置规则，每条规则可以设置为三个级别：
"off"或0：关闭规则"warn"或1：将规则视为警告，不会导致检查退出码为 1（不影响 CI 通过状态）"error"或2：将规则视为错误，触发错误时 ESLint 以非零退出码退出，可阻断 CI 流程
一条规则还可能接受额外的配置选项，例如指定缩进空格数、是否允许在 else 前的大括号换行等：
// .eslintrc.js
module.exports = {
rules: {
"semi": ["error", "always"], // 要求语句结束加分号
"quotes": ["warn", "single"], // 建议使用单引号
"no-unused-vars": "error", // 禁止出现未使用的变量
"eqeqeq": ["error", "always"], // 强制使用 === 和 !==
}
};手动维护几十上百条规则既不现实也无必要，ESLint 官方及社区提供了预置的规则集合，通过 extends 字段一键继承：
eslint:recommended：包含 ESLint 官方推荐的常见最佳实践规则，安全、无争议，适合作为基础起点。eslint:all：启用所有内置规则，适用于对代码质量有极致要求的项目，但需要额外调整。- 第三方共享配置：如
eslint-config-airbnb（Airbnb 的严格风格）、eslint-config-standard（StandardJS 风格）、eslint-config-prettier（关闭与 Prettier 冲突的规则）。
// 典型配置
module.exports = {
extends: [
"eslint:recommended",
"prettier" // 关闭与 Prettier 冲突的规则
],
env: {
browser: true,
node: true,
es2021: true
},
parserOptions: {
ecmaVersion: "latest",
sourceType: "module"
}
};23.1.3 自定义规则与针对性覆盖
在实际项目中，不同文件可能有不同的规则需求，例如测试文件中可以安全使用全局变量，而路由配置文件可能允许特定的命名约定。通过 overrides 字段可以针对特定文件或文件组进行精细化调整：
module.exports = {
rules: { "no-console": "warn" },
overrides: [
{
files: ["*.test.js", "*.spec.js"],
env: { jest: true },
rules: {
"no-console": "off" // 测试文件中允许 console
}
},
{
files: ["src/legacy/**/*.js"],
rules: {
"no-var": "off" // 老代码不做 var 限制
}
}
]
};如果需要全局变量不被误报，可以在 globals 字段声明（或使用注释 / global myGlobal /）。对于一些实在无法修复又必须放行的代码行，可以在行末添加 // eslint-disable-line 注释，但不建议滥用——每一条 disable 注释都应该写出具体正在禁用的规则名称，并注明原因，以便后续审查。
23.1.4 自动修复：让工具替你写风格
ESLint 最实用的功能之一是自动修复。许多规则（标记为🔧可修复的）提供了修复函数，通过 --fix 参数可以直接修改源文件：
npx eslint . --fix这能自动处理的任务包括但不限于：添加/移除分号、统一引号类型、修正缩进、移除无用的 console.log 残留等。将 ESLint 自动修复集成到编辑器（VS Code、WebStorm）中，可以实现保存时自动格式化代码风格，进一步解放开发者的双手。
需要注意的是，自动修复可能改变代码行为吗？理论上不会，但某些规则（如 no-unused-vars 的修复是移除变量声明，但可能导致其他引用该变量的地方报错）需要谨慎。建议在提交前运行 --fix，并通过 git diff 检查变更始终是个好习惯。
23.1.5 集成到工程化流程
ESLint 可以无缝融入现代前端的开发流程：
- 编辑器中实时提示：安装 VS Code 的 ESLint 插件，错误和警告会实时显示在代码旁边，无需离开编辑器。
- pre-commit 关卡：结合 Husky 和 lint-staged，在每次提交前只对暂存区文件执行 ESLint 检查和自动修复，防止不合规代码进入仓库。
- CI/CD 流水线：在持续集成中运行
eslint命令，若存在"error"级别的规则违例，则构建失败，强制执行团队规范。
# 在 CI 中常用命令
npx eslint . --max-warnings 0 # 即使是警告也不允许通过23.1.6 与 Prettier 的分工与合作
在实践中，ESLint 侧重代码逻辑质量与潜在错误，而 Prettier 侧重代码格式的统一（如每行长度、换行、空格）。两者配合使用时，需要安装 eslint-config-prettier 来关闭二者冲突的格式化规则，让 ESLint 专注于逻辑检查，Prettier 专注于格式美化。这个组合已成为现代前端项目的标配，它们共同构成了代码规范的左膀右臂。
通过合理配置 ESLint，团队不再需要花费精力争论代码风格，所有成员的代码就像同一个人写出来的，这不仅提升了协作效率，也大幅降低了因风格差异产生的合并冲突，真正让规范从口头约束变为自动执行的无形之手。