Vue2项目里为啥要配ESLint？

terry 7小时前阅读数 10 #Vue

文章标签 Vue2；ESLint

不少做前端开发的朋友，在Vue2项目里碰到ESLint配置问题就头大——要么初始化不知从哪下手，要么规则改起来没方向，还有和编辑器配合老出bug，这篇用问答形式把Vue2 + ESLint 从入门到定制的关键步骤拆明白,新手也能跟着一步步把代码规范管起来～

简单说，ESLint是帮咱“自动检查代码规范”的工具，想象下团队里三个人写Vue组件：有人组件名用驼峰，有人用短横线；有人if语句不加大括号，有人喜欢箭头函数省略return……代码风格乱成粥，后续维护像拆盲盒。

配了ESLint后，它能在你写代码时（或提交前）自动揪出语法错误（比如漏写分号、变量未定义）、风格问题（比如引号不一致、缩进不对）、Vue特有的坑（比如组件data没返回函数、v-for没写key），相当于给代码装了个“自动质检员”，团队协作更顺，后期维护也少踩坑。

Vue2项目初始化ESLint要做哪些事？

分「新建项目时直接配」和「老项目后加ESLint」两种场景：

场景1：用vue-cli新建项目时配置

打开终端执行vue create 项目名，选「手动配置（Manually select features）」，然后把「Linter / Formatter」勾上，接下来会让你选规则集（比如Airbnb、Standard、Vue官方规则）、是否用Prettier、检查时机（保存时/提交时），跟着向导选完，脚手架会自动装ESLint依赖，还生成.eslintrc.js配置文件，省了不少事。

场景2：给已有的Vue2项目加ESLint

得手动装依赖、配配置文件：

装核心依赖：npm install eslint eslint-plugin-vue @babel/eslint-parser --save-dev，其中eslint-plugin-vue是Vue官方的ESLint插件，处理.vue文件里的模板、脚本语法；@babel/eslint-parser是让ESLint能解析Babel处理的语法（比如Vue2里的装饰器、ES6+语法）。
生成配置文件：执行npx eslint --init，回答几个问题（比如代码运行环境、用啥规则集、是否用TypeScript），生成基础的.eslintrc.js。
关联Vue规则：打开.eslintrc.js，在extends里加Vue的规则集，比如'plugin:vue/essential'（基础必选规则）、'plugin:vue/strongly-recommended'（强推荐规则）或'plugin:vue/recommended'（推荐规则）。

装完后，项目根目录会有.eslintrc.js（或.json/.yml）、.eslintignore（忽略哪些文件不检查），这俩文件是配置核心。

ESLint配置文件里关键配置项咋理解？

以最常见的.eslintrc.js为例，核心配置项就像“规则开关”，得搞懂它们干啥用：

extends：继承现成的规则集

可以理解成“抄作业”——直接继承别人写好的规则。

extends: [
  'plugin:vue/essential', // Vue官方的基础必选规则（比如组件data必须是函数）
  'airbnb-base' // Airbnb的JS规则（不含React，适合Vue项目）
]

常用的规则集还有standard（JS标准风格）、eslint:recommended（ESLint官方推荐规则），选哪个看团队习惯，Airbnb规则严但全面，Standard更简洁。

plugins：引入插件扩展规则

ESLint本身只管JS基础语法，处理Vue得靠eslint-plugin-vue插件，配置时要先装插件，再在plugins里声明：

plugins: [
  'vue' // 告诉ESLint：我要用vue插件的规则
]

类似的，处理React用eslint-plugin-react，处理Prettier冲突用eslint-plugin-prettier。

rules：自定义单条规则

如果继承的规则集里某条规则太严/太松，就在rules里单独改，格式是'规则名': ['错误级别', 额外配置]，错误级别分'off'（关闭）、'warn'（警告，不阻断提交）、'error'（错误，阻断提交）。

比如Vue3要求组件名用多单词（防止和HTML原生标签冲突），但Vue2项目里很多单单词组件（比如Home.vue），就把这条规则关了：

rules: {
  'vue/multi-word-component-names': 'off' // 关闭“组件名必须多单词”的检查
}

再比如JS里喜欢用单引号，把引号规则改成单引号：

'quotes': ['error', 'single'] // 强制用单引号，不符合就报错

parser：指定语法解析器

Vue2项目里，.vue文件里的<script>可能用了Babel处理的语法（比如ES7装饰器、async/await），这时候得用@babel/eslint-parser当解析器，让ESLint能读懂代码：

parser: '@babel/eslint-parser',
parserOptions: {
  sourceType: 'module',
  ecmaVersion: 2021,
  babelOptions: { // 告诉解析器用项目里的babel配置
    configFile: './babel.config.js'
  }
}

如果没配对解析器，ESLint可能把Vue的语法认错，疯狂报红，所以这步很关键。

怎么给Vue2定制ESLint规则？

定制规则得结合团队习惯和项目需求，分「Vue组件特有的规则」和「JS通用规则」

Vue组件专属规则（看eslint-plugin-vue文档）

组件命名：除了前面说的vue/multi-word-component-names，还能配vue/component-name-in-template-casing（模板里组件名用kebab-case还是PascalCase）。
模板语法：比如vue/attributes-order（规定v-bind、v-on、普通属性的顺序）、vue/html-self-closing（单标签是否自闭合，比如<img>要不要写成<img/>）。
脚本逻辑：vue/require-prop-types（props是否要写类型验证）、vue/no-unused-components（检测未使用的组件引入）。

JS通用规则（看ESLint官方规则文档）

代码风格：semi（是否加分号）、indent（缩进用2空格还是4空格）、linebreak-style（换行用LF还是CRLF）。
代码质量：no-unused-vars（检测未使用的变量）、no-console（禁止用console.log，线上代码要删）、no-alert（禁止用alert弹窗）。
ES6+特性：prefer-const（能声明const就不用let）、arrow-parens（箭头函数参数是否加括号）。

定制技巧：先跑npx eslint src看现有错误，再针对性改规则，比如老项目里console.log太多，先把no-console设为'warn'，提醒但不阻断，慢慢替换；新项目可以直接设为'error'，从源头杜绝。

ESLint和VSCode/Sublime这些编辑器咋联动？

让编辑器实时提示错误、保存时自动修复，写代码才爽！以VSCode和Sublime为例：

VSCode配置步骤

装插件：在VSCode扩展市场搜「ESLint」，装官方的ESLint插件。
开自动修复：打开VSCode的设置（File → Preferences → Settings），搜codeActionsOnSave，把「Editor: Code Actions On Save」里的source.fixAll.eslint勾上（或在settings.json里写"editor.codeActionsOnSave": { "source.fixAll.eslint": true }）。
选对工作区版本：如果项目里装了本地ESLint（node_modules里的），VSCode会优先用本地版本，避免全局版本和项目规则冲突。

这样写代码时，只要不符合ESLint规则，编辑器会标红波浪线，保存时自动fix成符合规则的格式。

Sublime配置步骤

装插件：先装「Package Control」，再搜「SublimeLinter」（代码检查框架）和「SublimeLinter-eslint」（ESLint的适配器）。
开自动检查：打开SublimeLinter的设置，把"lint_on_save"设为true，这样保存文件时自动检查。
指定ESLint路径：如果项目用了本地ESLint，在SublimeLinter设置里把"paths": { "linux": [], "osx": [], "windows": [] }里加上项目node_modules/.bin的路径，确保用项目里的ESLint版本。

不管用啥编辑器，核心思路是「让编辑器能找到项目里的ESLint，并且开自动修复」，这样写代码时实时反馈，效率拉满。

Vue2项目里ESLint和Prettier冲突咋解决？

很多人同时用Prettier（格式化代码）和ESLint（检查规范），结果因为两者都管“代码格式”（比如引号、缩进、换行），导致规则打架（比如Prettier要单引号，ESLint要双引号），解决得靠两个包：

eslint-config-prettier：关闭ESLint里和Prettier冲突的规则（比如ESLint的引号规则和Prettier不一致，就把ESLint的引号规则关了，让Prettier说了算）。
eslint-plugin-prettier：把Prettier的格式化规则当成ESLint的规则来运行（这样ESLint报错时，既能管代码质量，又能管Prettier的格式）。

配置步骤：

装依赖：npm install eslint-config-prettier eslint-plugin-prettier --save-dev。

改.eslintrc.js：

extends: [
'plugin:vue/essential',
'airbnb-base',
'prettier' // 先引入prettier，关闭ESLint和Prettier冲突的规则
],
plugins: [
'vue',
'prettier' // 引入prettier插件
],
rules: {
'prettier/prettier': 'error' // 把Prettier的格式问题当成ESLint错误
}

这样配置后，ESLint和Prettier就统一了：Prettier负责定格式规则，ESLint负责执行+检查代码质量，再也不打架～

配置完后怎么验证ESLint是否生效？

分「命令行验证」和「编辑器验证」两步：

命令行验证

在项目根目录执行npx eslint src（假设代码在src文件夹），如果配置生效，终端会列出所有不符合规则的文件和错误原因，比如故意写个没加key的v-for：

<template>
  <ul>
    <li v-for="item in list">{{ item }}</li> <!-- 没写key -->
  </ul>
</template>

执行eslint后，应该能看到'vue/require-v-for-key'的错误提示，说明Vue的规则生效了。

编辑器验证

打开一个.vue文件，故意写不符合规则的代码：比如规则要求用双引号，你写成单引号；或者v-bind缩写没加冒号（比如src="img.png"应该写成:src="img.png"）。

如果编辑器里出现红色波浪线，说明ESLint检测到了；然后保存文件，如果代码自动变成符合规则的格式（比如单引号变双引号），说明自动修复也生效了。

要是没生效，先检查编辑器是否装了ESLint插件、配置是否开了自动修复，再检查项目里的.eslintrc.js有没有语法错误（比如逗号漏写、规则名拼错）。

Vue2老项目接入ESLint要注意啥？

老项目代码量多，直接开严格规则会冒出几百个错误，团队改起来压力山大，得讲究“循序渐进”：

先把规则设为warn，减少阻力

把关键规则的错误级别从'error'改成'warn'，

rules: {
  'no-console': 'warn', // 控制台打印只警告，不阻断提交
  'vue/multi-word-component-names': 'warn' // 组件名规则先警告
}

这样团队成员提交代码时，能看到提示但不会被强制阻断，慢慢改。

用--fix自动修复批量问题

执行npx eslint src --fix，让ESLint自动修复能处理的问题（比如引号、缩进、分号这些格式问题），修复后再手动处理剩下的逻辑错误（比如未使用的变量、props类型缺失）。

忽略无关文件，加快lint速度

在.eslintignore里加入不需要检查的文件/文件夹，

node_modules/
dist/
public/
*.config.js // 配置文件里的语法可能不符合规则，暂时忽略

这样ESLint不会去检查这些目录，减少执行时间。

和团队同步规则迭代节奏

老项目接入ESLint是个渐进过程，建议每周选1 - 2条规则从warn改成error，逐步收紧规范，比如第一周解决引号、分号问题，第二周解决组件命名，第三周解决props类型验证……每次迭代前开个短会同步，避免有人不知情被规则卡壳。

总结下，Vue2配置ESLint核心是「选对规则集→改自定义规则→联动编辑器→解决冲突→渐进落地」，刚开始可能觉得配置项多、规则绕，但只要把每个环节拆碎了理解，再结合项目实际需求调整，代码规范这块就能从“靠人盯”变成“自动管”，团队协作和代码质量都能上一个台阶～要是配置过程中碰到具体报错，欢迎留言,咱们一起拆解解决～