如何通过ESLint实现代码规范与一致性检查？

说实话，代码这玩意儿，写起来容易，管起来难。特别是多人协作的时候，那叫一个乱啊。你写个 function 用驼峰命名， 他写个变量用下划线，再加个小伙伴喜欢在行尾加个分号，另一个又不加……你懂的，这种“自由发挥”的代码风格，时间一长，项目就废了那个。所以ESLint 就是来救场的，实不相瞒...。

它就像一个代码界的“班主任”，专门盯着你写代码的姿势对不对。它不光是挑毛病，还帮你改毛病。你写完代码，它一看，哎你这缩进不对，它就给你标红，甚至还能自动给你修好。你说这工具厉不厉害？

咱就是说ESLint 是 JavaScript 和 TypeScript 的代码检查工具。它通过抽象语法树来分析你写的代码，看看你有没有“越界”。比如你用了个未定义的变量，它就给你报错；你没加分号，它也给你提示。它不是为了为难你，而是为了让你的代码更干净、更统一、更少出错，一言难尽。。

你可能会说：“代码能跑不就完事了吗？”害，这话听起来挺有道理，但等你项目大了维护起来你就知道什么叫“痛不欲生”了。代码规范这事儿，短期看是麻烦，长期看是省事。不信你试试，一个几十万行的项目，如果没人管代码风格，那维护成本是指数级上升的，真的不骗你，也是醉了...。

ESLint 怎么用？

先说说你得把它装到项目里。现在装个 ESLint 真的不费劲， 直接在终端里敲：，中肯。

npm install -D eslint

然后初始化一下：

npm init @eslint/config@latest

它会问你一堆问题，比如你用的是啥框架、啥规范，你选一选，它就自动生成配置文件了。当然你也可以自己手写配置，不过一般不推荐，除非你特别闲，谨记...。

配置文件怎么写？

ESLint 的配置文件， 现在推荐用 eslint.config.js不是以前那种 .eslintrc.js 了。 就这样吧... 为啥？主要原因是新版本的配置方式更直观，更像写普通 JS 代码，配置起来也更灵活。

举个例子：

import js from '@eslint/js';
export default , // 不加分号
      "quotes": , // 用单引号
      "comma-dangle":  // 保留尾逗号
    }
  }
];

很棒。 你也可以根据项目需要，自定义规则。比如你团队就喜欢不加分号，那就把 semi 规则关掉。或者你团队喜欢统一用双引号，那就把 quotes 改成 double。 规则是死的，人是活的，你说了算。

规则严重度

ESLint 的规则有三个等级：

• "off" 或 0关掉， 爱咋写咋写
• "warn" 或 1警告，但不影响提交
• "error" 或 2错误，严重时会中断构建

比如你写了个规则：

"no-console": "error"

我整个人都不好了。 那你在代码里写了 console.log它就会报错，甚至阻止你提交。你说这严格不严格？

和编辑器结合

绝大多数前端开发者都用 VS Code，所以 ESLint 插件必须装上。但光装插件还不够， 你还得配置一下 settings.json让编辑器在你保存文件的时候自动修复代码。比如这样：，我好了。

"editor.codeActionsOnSave": {
  "source.fixAll.eslint": true
}

这样你每次按 Ctrl + S代码格式就自动修好了。是不是很爽，总体来看...？

和 Prettier 配合

讲真，ESLint 和 Prettier 是黄金搭档。ESLint 负责代码质量，Prettier 负责代码美观。但它们俩有时候会打架，比如 ESLint 说要加分号，Prettier 说不要。这时候就得让它们“分工合作”，事实上...。

说明….. 安装 Prettier 和 ESLint 的兼容包：

npm install -D prettier eslint-config-prettier

然后在配置里把 Prettier 的规则放再说说 这样它就能覆盖掉 ESLint 中冲突的规则：

import js from '@eslint/js';
import prettier from 'eslint-config-prettier';
export default ;

又爱又恨。 然后你再单独创建一个 .prettierrc 文件，专门放样式相关的配置：

{
  "semi": false,
  "singleQuote": true,
  "trailingComma": "all"
}

这样一来ESLint 专心抓逻辑错误，Prettier 负责代码美观，天下太平，再也不用为格式问题吵架了。

和 Git 钩子结合

试试水。 虽然编辑器能帮你修好大部分问题， 但总有些“漏网之鱼”，或者有些队友根本没装插件。为了确保进入仓库的代码是干净的，我们需要在 Git 提交前做一次拦截。这里就要祭出 lint-staged 和 Husky 这对黄金搭档了。

安装并初始化 Husky：

npx husky add .husky/pre-commit "npx lint-staged"

本质上... 然后在 package.json 中配置 lint-staged 告诉它只检查本次修改的文件，别去检查整个项目，那样太慢了：

"lint-staged": {
  "*.{js,ts,vue}": 
}

配置好这套流程后被打断。这时候你就必须乖乖把代码改好才能提交。 哪怕... 这招虽然有点狠，但对于维护团队代码质量来说简直是立竿见影。

忽略文件

嚯... 当然规矩是死的，人是活的。有些时候，我们确实不希望某些文件走 ESLint 检查。比如打包后的 dist 目录，或者某些第三方库的源码。这时候，我们可以通过 .eslintignore 文件来指定不需要走规范的代码。

梳理梳理。 这个文件的用法跟 .gitignore 非常像， 一行写一个路径匹配规则：

dist/
node_modules/
*.min.js
build/

有了这个文件，ESLint 在扫描的时候就会自动跳过这些目录，既节省了性能，又避免了不必要的报错干扰，何必呢？。

一下

人间清醒。 讲了这么多， 其实归根结底就是一句话：ESLint 是为了让我们写代码更轻松，而不是更累。通过 ESLint，开发者可以规范代码风格、发现潜在的错误、维护一致性的代码库。虽然刚开始配置的时候可能会觉得繁琐，甚至要花时间去解决各种报错，但这绝对是一笔稳赚不赔的投资。

所以别再犹豫了现在就去给你的项目配上 ESLint 吧。当你习惯了那种干净、整洁、统一的代码风格，你就再也回不去那个“自由散漫”的旧时代了。