首先在项目中安装eslint及相关依赖，如typescript或react插件；2. 运行npx eslint --init生成.eslintrc配置文件以定义检查规则；3. 在vscode中安装eslint扩展；4. 在项目.vscode/settings.json中配置editor.codeactionsonsave和eslint.validate以启用保存时自动修复和文件类型支持；5. 重启vscode使配置生效。这样vscode即可通过项目本地eslint实现代码检查与自动修复，解决插件不生效的常见原因包括未安装项目依赖、配置文件缺失或错误、文件类型未包含在validate中、node环境问题或monorepo工作目录未指定，可通过检查node_modules、配置文件、扩展设置及查看eslint输出日志来排查。自定义规则需在.eslintrc的rules中设置级别为"off"、"warn"或"error"，并通过extends继承推荐配置、plugins引入框架插件、parser指定语法解析器、overrides针对特定文件覆盖规则。为实现eslint与prettier协同工作，需安装prettier、eslint-config-prettier和eslint-plugin-prettier，其中eslint-config-prettier用于关闭与prettier冲突的eslint格式规则，eslint-plugin-prettier将prettier作为eslint规则运行，并在extends中将'plugin:prettier/recommended'置于末尾以确保优先级，同时在vscode中设置prettier为默认格式化器并开启formatonsave，从而实现prettier统一格式化、eslint专注质量检查的高效协作流程。
配置VSCode让ESLint进行代码检查，核心流程其实并不复杂：它主要涉及在项目里安装ESLint本身，接着在VSCode中安装对应的ESLint扩展，最后就是配置好项目的
.eslintrc文件。这样一来，你的编辑器就能实时帮你找出代码里的潜在问题和不规范之处，甚至自动修复一部分。
解决方案
要让VSCode和ESLint愉快地协同工作，我通常会按照下面几个步骤来操作，这套流程下来基本能解决大部分问题：
-
项目内安装ESLint和相关依赖 这是第一步，也是最关键的一步。ESLint通常是作为项目开发依赖存在的，而不是全局安装。 打开你的项目根目录，在终端里运行：
npm install eslint --save-dev # 或者如果你用yarn yarn add eslint --dev
如果你还打算用TypeScript或者React，可能还需要安装一些额外的插件和解析器，比如：
npm install @typescript-eslint/eslint-plugin @typescript-eslint/parser --save-dev npm install eslint-plugin-react --save-dev # 如果是React项目
-
初始化ESLint配置 安装完ESLint后，我们需要告诉它怎么检查代码。在项目根目录运行：
npx eslint --init
这个命令会引导你完成一系列选择，比如你想用哪种风格指南（Airbnb、Standard、Google），项目是否使用React或TypeScript，以及配置文件格式（JS、YAML、JSON）。根据你的选择，它会自动生成一个
.eslintrc.js
（或.json
/.yml
）文件。这个文件就是ESLint的“大脑”，里面定义了所有的规则。 安装VSCode ESLint扩展 打开VSCode，进入扩展视图（Ctrl+Shift+X），搜索“ESLint”，找到由“Dirk Baeumer”发布的那个，然后点击安装。这个扩展是连接VSCode和项目ESLint的桥梁，它负责把ESLint的检查结果实时显示在你的编辑器里。
-
配置VSCode工作区设置（可选但强烈推荐） 为了让ESLint体验更顺畅，我个人习惯在项目的工作区设置里加上一些配置。打开你的项目根目录下的
.vscode/settings.json
文件（如果没有就创建一个），添加以下内容：{ "editor.codeActionsOnSave": { "source.fixAll.eslint": "explicit" }, "eslint.validate": [ "javascript", "javascriptreact", "typescript", "typescriptreact", "vue" // 如果你用Vue ], // 针对 monorepo 项目，可能需要指定 ESLint 的工作目录 // "eslint.workingDirectories": [ // "./packages/*" // ] }"editor.codeActionsOnSave": { "source.fixAll.eslint": "explicit" }这一行非常有用，它让VSCode在你保存文件的时候自动运行ESLint的自动修复功能，能省去很多手动格式化的麻烦。"eslint.validate"
则确保ESLint对你指定的文件类型生效。 重启VSCode 所有配置完成后，重启一下VSCode，让所有的设置和扩展都生效。通常，你会在代码中看到ESLint的错误和警告提示了。
为什么我的VSCode安装了ESLint插件却不生效？
这问题我被问过太多次了，也遇到过不少。说实话，ESLint不生效的原因五花八门，但大部分都逃不过这几个点：
首先，最常见的是项目里根本没装ESLint。很多人以为VSCode装了ESLint扩展就万事大吉，但实际上，VSCode的扩展只是一个“接口”，它需要调用你项目里安装的ESLint包来执行检查。如果项目
node_modules里没有
eslint这个包，那扩展自然就没东西可调了。所以，记得第一步——
npm install eslint --save-dev是必不可少的。
其次，.eslintrc
配置文件有问题或者干脆没有。ESLint需要一个配置文件来知道检查哪些规则。如果你没有运行
npx eslint --init，或者配置文件里有语法错误、路径引用不对，ESLint就无法正常工作。有时候，文件名字写错了（比如写成
.eslint.js而不是
.eslintrc.js）也会导致找不到配置。
再来，是VSCode的ESLint扩展没有被激活或者配置不正确。
- 检查扩展是否已启用。
eslint.validate
设置里是否包含了你当前编辑的文件类型？比如你在写.ts
文件，但eslint.validate
里没有typescript
，那它自然不会检查。- 有时候，VSCode缓存出了问题，重启VSCode通常能解决。
还有一些比较隐蔽的原因，比如：
- Node.js环境问题：如果你使用了NVM、Volta等工具管理Node.js版本，或者Node.js路径没有正确配置在系统环境变量里，VSCode的ESLint扩展可能找不到正确的Node环境来运行ESLint。
-
工作目录问题：在Monorepo（多包仓库）项目中，ESLint可能不知道去哪个子包里找
node_modules
和.eslintrc
。这时候就需要用到eslint.workingDirectories
这个VSCode配置项，明确告诉ESLint每个子项目的根目录在哪。 - 冲突的插件或设置：比如你同时安装了Prettier和ESLint，并且两者都有格式化功能，可能会互相干扰。
遇到不生效的情况，我的经验是先从最基本的检查开始：
node_modules里有没有ESLint？
.eslintrc文件存不存在、内容对不对？然后看VSCode的输出面板（Ctrl+Shift+U），选择“ESLint”通道，那里通常会打印出ESLint运行时的错误信息，这往往是定位问题的关键。
如何根据项目需求自定义ESLint规则？
自定义ESLint规则是让代码风格和质量符合团队或个人偏好的关键一步。这主要通过修改项目根目录下的
.eslintrc.js（或其他格式）文件来实现。
这个文件通常长这样：
module.exports = {
root: true, // 告诉ESLint这是根配置，不要再往上级目录找了
env: {
browser: true, // 启用浏览器全局变量
node: true, // 启用Node.js全局变量
es2021: true, // 启用ES2021语法
},
extends: [
// 可以继承多个配置，后面的会覆盖前面的
'eslint:recommended', // ESLint推荐的基本规则
'plugin:react/recommended', // React插件推荐规则
'plugin:@typescript-eslint/recommended', // TypeScript插件推荐规则
'plugin:prettier/recommended', // Prettier集成，禁用与Prettier冲突的ESLint规则
],
parser: '@typescript-eslint/parser', // 指定解析器，让ESLint能解析TypeScript
parserOptions: {
ecmaVersion: 'latest', // ECMAScript版本
sourceType: 'module', // 模块类型
ecmaFeatures: {
jsx: true, // 启用JSX
},
project: './tsconfig.json', // 如果是TS项目，需要指定tsconfig文件
},
plugins: [
'react', // 启用React插件
'@typescript-eslint', // 启用TypeScript插件
'prettier', // 启用Prettier插件
],
rules: {
// 在这里自定义或覆盖规则
'indent': ['error', 2], // 强制使用2个空格缩进，错误级别
'linebreak-style': ['error', 'unix'], // 强制使用Unix风格的换行符
'quotes': ['error', 'single'], // 强制使用单引号，错误级别
'semi': ['error', 'always'], // 强制语句结尾使用分号，错误级别
'no-unused-vars': 'warn', // 未使用的变量发出警告，而不是错误
'react/react-in-jsx-scope': 'off', // 在新版React中不再需要引入React
'@typescript-eslint/no-explicit-any': 'off', // 允许使用any类型
// 可以禁用某个继承来的规则
'no-console': 'warn', // 允许console.log但发出警告
},
settings: {
react: {
version: 'detect', // 自动检测React版本
},
},
// 针对特定文件或目录的覆盖规则
overrides: [
{
files: ['*.ts', '*.tsx'], // 仅对ts和tsx文件生效
rules: {
'@typescript-eslint/explicit-module-boundary-types': 'off', // TS函数需要明确返回类型，这里禁用
},
},
{
files: ['**/*.test.js', '**/*.spec.js'], // 对测试文件生效
env: {
jest: true, // 启用Jest全局变量
},
rules: {
'no-unused-expressions': 'off', // 测试文件中可能用到一些表达式
},
},
],
};核心自定义点：
-
rules
：这是你最常打交道的地方。每个规则通常有三个级别："off"
或0
：禁用规则。"warn"
或1
：违反规则时发出警告（不影响退出码）。"error"
或2
：违反规则时报错（通常会阻止编译或提交）。 一些规则还可以接受额外的配置数组，比如'quotes': ['error', 'single']
，single
就是配置项。
-
extends
：这个属性非常强大，它允许你继承其他预设的配置。比如eslint:recommended
是ESLint官方推荐的一套基础规则；plugin:react/recommended
则包含了React项目常用的一些规则。通过继承，你不需要从头开始定义所有规则，只需要在rules
里覆盖或添加你自己的规则即可。后面的配置会覆盖前面的。 -
plugins
：当你的项目使用了特定的库或框架（如React、Vue、TypeScript）时，可能需要安装并启用对应的ESLint插件。这些插件提供了针对特定技术栈的额外规则。 -
parser
和parserOptions
：如果你的项目不是纯JavaScript（比如使用了TypeScript或JSX），就需要指定一个解析器来帮助ESLint理解这些语法。parserOptions
则提供了更多解析相关的配置。 -
overrides
：这特别有用。有时候你希望某些规则只对特定类型的文件或特定目录下的文件生效。overrides
数组可以让你为符合files
模式的文件应用一套不同的规则、环境或解析器。
自定义规则是一个不断磨合的过程。一开始可以从一个成熟的
extends配置开始，然后根据团队的实际开发习惯和痛点，逐步调整
rules，禁用一些过于严格的，或者加强一些你认为重要的。这其实是个挺微妙的平衡点，既要保证代码质量，又不能让开发者觉得束手束脚。
ESLint与Prettier如何协同工作以优化代码格式？
ESLint和Prettier是现代前端开发中两款非常强大的工具，但它们解决的问题略有不同，因此需要巧妙地协同工作，避免“打架”。
它们各自的职责：
- ESLint：主要关注代码质量和潜在错误。它能检查出你代码中可能导致bug的模式（比如未使用的变量、潜在的内存泄漏），以及一些风格上的不一致（比如强制使用驼峰命名）。它有能力修复一部分风格问题，但这不是它的核心职责。
- Prettier：专注于代码格式化。它几乎没有可配置的规则，一旦配置好（比如单引号、缩进空格数），它就会不遗余力地把所有代码格式化成统一的风格，不关心代码逻辑是否正确。
冲突点：
问题来了，ESLint也有一些格式化相关的规则（比如缩进、分号、引号），这和Prettier的功能重叠了。如果两者都开启，就可能出现你保存文件时，ESLint自动修复了A样式，结果Prettier又把它改回了B样式，或者反过来，代码在保存后反复“跳动”的情况。这体验简直让人抓狂。
完美的解决方案：
让ESLint负责代码质量和潜在错误，而Prettier则全权负责代码格式化。实现这一点的关键在于使用两个特定的ESLint插件：
eslint-config-prettier和
eslint-plugin-prettier。
-
安装必要的包
npm install prettier eslint-config-prettier eslint-plugin-prettier --save-dev # 或者 yarn add prettier eslint-config-prettier eslint-plugin-prettier --dev
prettier
: Prettier本体。eslint-config-prettier
: 这是一个特殊的ESLint配置，它的作用是禁用所有与Prettier冲突的ESLint格式化规则。这样，ESLint就不会再管格式问题了。eslint-plugin-prettier
: 这是一个ESLint插件，它将Prettier的格式化功能作为一条ESLint规则来运行。这意味着，如果Prettier认为你的代码格式不正确，ESLint就会把它标记为一个错误。
-
配置
.eslintrc.js
在你的.eslintrc.js
文件的extends
数组中，将'plugin:prettier/recommended'
放在最后。顺序很重要，因为extends
后面的配置会覆盖前面的。module.exports = { // ...其他配置 extends: [ 'eslint:recommended', 'plugin:react/recommended', 'plugin:@typescript-eslint/recommended', // 确保 'plugin:prettier/recommended' 在最后 'plugin:prettier/recommended', ], // ...其他配置 rules: { // 'prettier/prettier': 'error', // 这一行通常由 'plugin:prettier/recommended' 自动包含 // 你自定义的ESLint规则，不应包含格式化规则 }, };'plugin:prettier/recommended'
这个配置实际上做了两件事：- 它继承了
eslint-config-prettier
，禁用了所有可能与Prettier冲突的ESLint格式化规则。 - 它启用了
eslint-plugin-prettier
，并设置'prettier/prettier': 'error'
规则，这意味着如果代码不符合Prettier的格式，ESLint会报错。
- 它继承了
-
配置VSCode
- 安装Prettier - Code formatter扩展：同样在VSCode扩展视图中搜索并安装。
-
设置默认格式化器：在
.vscode/settings.json
中，确保Prettier是你的默认格式化器，并且保存时自动格式化：{ "editor.defaultFormatter": "esbenp.prettier-vscode", "editor.formatOnSave": true, // 确保 ESLint 也能在保存时自动修复 "editor.codeActionsOnSave": { "source.fixAll.eslint": "explicit" } }
这样配置下来，你的工作流就会非常流畅：当你保存文件时，VSCode会先调用Prettier对代码进行格式化，然后ESLint再进行代码质量检查和自动修复。由于ESLint的格式化规则已经被禁用，它不会再和Prettier冲突，完美实现了分工协作。
