做前端这几年，代码风格规范这个事我踩过的坑不算少。团队协作时，今天你双引号、明天我单引号，今天你有分号、明天我去分号，每次提交都一堆格式改动，code review 里全是和逻辑无关的 diff。后来公司统一推到 ESLint 和 Prettier 组合，我一开始还觉得“这不就是两个工具吗，配一下就好”，真上手才发现，在 IDEA 里配置 ESLint 和 Prettier 看着简单，实际有一堆细节，配不好就会出现“保存时格式乱了”“ESLint 疯狂报错但就是不自动修”“Prettier 和 ESLint 互相打架”这类奇葩问题。
这篇内容就是围绕在 IDEA 中配置 ESLint 和 Prettier 这件事，把整套思路、配置步骤、参数选择和坑点讲明白。适合刚开始做前端工程化、或者已经在用但被各种小问题折磨的同学参考。我尽量不整虚的，直接把能落地的做法写出来。
1. 先搞清楚 ESLint 和 Prettier 到底在管什么
1.1 两者的职责边界
很多同学第一次配这两个工具时，最大的困惑是：它们都管代码格式，为什么装完一个还要装另一个？
这里我说个直白点的理解：ESLint 管的是“代码质量”，Prettier 管的是“代码颜值”。
ESLint 重点检查的是代码里有没有隐患、有没有不符合规范的写法。比如说，你声明了一个变量但从来没用到，ESLint 会标黄；你在函数里写了 console.log，ESLint 可以按团队规范警告或报错；你用了 var 而不是 const/let，ESLint 也可以拦下来。它更像一个“纪律委员”，盯着你代码里那些一眼看上去没问题、但仔细想想会出事的写法。
Prettier 就不一样了，它只关心代码长得好看不好看。字符串用单引号还是双引号，结尾加不加分号，行宽超没超过 100 个字符，对象属性后面跟不跟逗号，这些东西 Prettier 全会管。它更像一个“排版工”，拿到代码后按规则统一重排一遍，不需要知道你代码逻辑是什么。
两者的侧重点完全不同，所以不是二选一，而是合作。ESLint 负责让你别写不靠谱的代码，Prettier 负责让所有人都长得一样，代码审查的时候大家只看业务逻辑，不用再吵格式问题。
1.2 为什么不能只装一个
可能有人问：我只要 Prettier 不就行了？每次保存自动格式化，代码风格统一了，还省事。
答案是不行，至少对稍微正规点的项目来说不行。Prettier 不会告诉你“这个变量没用到”，也不会提醒你“这里用了 == 而不是 ===”。它只负责排版，不负责代码安全性。反过来，只装 ESLint 也不够，ESLint 虽然包含少量格式规则，但力量有限，像“对象属性是否换行”“箭头函数参数是否加括号”这类风格细节，如果全部靠 ESLint 规则去配，规则文件会变得非常庞大，而且跟 Prettier 的默认行为很难完全对齐。
所以正规做法就是 ESLint 管质量 + Prettier 管格式，各司其职。两者组合起来才是完整的代码规范体系。
1.3 从全局看整套配置流程
在 IDEA 里配置这两个工具，整体流程其实就四步：
第一步，安装依赖。项目里要有 eslint、prettier，以及把两者串起来的 eslint-config-prettier 和 eslint-plugin-prettier。
第二步，写配置文件。ESLint 读取 .eslintrc.js，Prettier 读取 .prettierrc，两个文件各管各的。
第三步，在 IDEA 的 Settings 里配置插件指向这些依赖。
第四步，设置保存时自动执行格式化或修复，然后验证是否生效。
前面两步属于“项目层面”，后面两步属于“IDE 层面”。很多人配不好，就是因为只做了后面两步，前面项目依赖没装全；或者只做了前面两步，IDEA 里插件没指到项目的 node_modules。我下面按顺序来拆。
2. 动手前：IDEA、Node 与插件的准备
2.1 确认 IDEA 版本与内置插件支持
新版 IDEA 对前端工具的支持已经相当好了。ESLint 插件从很早就集成在 IDEA 里，不需要额外去插件市场安装；Prettier 在 2020.1 版本之后也变成内置支持，同样不需要装第三方插件。你只需要确保 IDEA 版本别太老就行。
如果你的 IDEA 比较旧，建议先升级，不然后面配置界面长得跟我说的对不上，容易瞎。打开 IDEA 的 Settings，在 Plugins 里搜 ESLint 和 Prettier，如果看到已经安装（Installed），说明内置支持没问题。如果没看到，说明版本可能过老，要么升级，要么手动安装插件。
这里多说一句，社区版（Community）和旗舰版（Ultimate）都能用这两个工具，社区版的前端支持其实也够用，不一定非要旗舰版。如果你只是写前端项目、不搞后端框架，社区版完全能配合 ESLint 和 Prettier 正常干活。
2.2 安装 Prettier 插件与项目依赖
虽然 IDEA 内置了对 Prettier 的支持，但项目里必须装 prettier 这个 npm 包，IDEA 才能找到解析器。只装插件不装依赖的话，IDEA 会一直提示找不到 package。
在项目根目录执行：
npm install -D prettier eslint eslint-config-prettier eslint-plugin-prettier这几个包的作用我简单说明一下：
prettier：格式化引擎，负责排版。eslint：代码检查引擎，负责质量。eslint-config-prettier：关闭 ESLint 中跟 Prettier 冲突的格式规则。eslint-plugin-prettier：把 Prettier 当成 ESLint 的一条规则来跑，格式不对直接报错。
这两兄弟缺一个都不行。缺少 eslint-config-prettier，ESLint 的格式规则会和 Prettier 打架；缺少 eslint-plugin-prettier，Prettier 的格式化结果不会以错误形式反馈到 IDEA 里，体验会差很多。
如果你用的是 Vue 项目，还要额外装一个插件来处理 .vue 文件：
npm install -D eslint-plugin-vue如果是 TypeScript 项目，再装：
npm install -D @typescript-eslint/parser @typescript-eslint/eslint-plugin2.3 初始化前端项目的基本结构
上面那些命令执行完，package.json 里会出现类似这样的 devDependencies：
{ "devDependencies": { "@typescript-eslint/eslint-plugin": "^7.0.0", "@typescript-eslint/parser": "^7.0.0", "eslint": "^8.57.0", "eslint-config-prettier": "^9.1.0", "eslint-plugin-prettier": "^5.1.3", "eslint-plugin-vue": "^9.25.0", "prettier": "^3.2.5" } }这里有个容易踩的版本问题：ESLint 9 之后配置文件格式变了，IDEA 对 ESLint 9 的支持需要 IDEA 2023.2 以上。如果你用的是老版本 IDEA，建议先锁定 ESLint 8.x 的版本，配置方式更通用：
npm install -D eslint@8.57.0等确认 IDEA 版本支持新配置格式，再升级到 9 也不迟。这个版本坑我当年就踩过，装完 ESLint 9 后发现 IDEA 里规则读不出来，报错显示找不到配置，最后回退到 8.x 才正常。
3. 配置文件怎么写得省心又稳定
3.1 ESLint 配置：老格式与新格式
ESLint 的配置文件，目前最常见的是.eslintrc.js。虽然 ESLint 9 开始推荐用新的扁平配置eslint.config.js，但老格式的存量项目和使用习惯依然非常多，我先把老格式写明白，再说新格式的区别。
在项目根目录创建.eslintrc.js：
module.exports = { root: true, env: { browser: true, es2021: true, node: true, }, extends: [ 'eslint:recommended', 'plugin:vue/vue3-recommended', 'plugin:prettier/recommended', ], parserOptions: { ecmaVersion: 'latest', sourceType: 'module', }, rules: { 'no-console': process.env.NODE_ENV === 'production' ? 'warn' : 'off', 'no-debugger': process.env.NODE_ENV === 'production' ? 'warn' : 'off', }, };关键点逐个说：
root: true表示这个配置文件是项目的根配置，ESLint 不会再往上级目录找其他配置文件。这个很重要，否则 ESLint 可能会读到全局或上级目录的配置，导致规则混乱。
env里声明了代码运行环境。浏览器环境允许使用 window、document 等全局变量；node 环境允许使用 process、module 等；es2021 开启 ES2021 的全局变量和语法。
extends是配置的核心，按顺序继承规则集。重点是最后一行plugin:prettier/recommended，这一行同时做了三件事：引入 eslint-plugin-prettier、把 prettier 规则作为 ESLint 规则启用、用 eslint-config-prettier 关掉与 Prettier 冲突的 ESLint 格式规则。有了它，你就不需要手动在 rules 里写一堆quotes: off、semi: off这种补丁式配置了。
如果你不用 Vue，就把plugin:vue/vue3-recommended去掉，变成：
extends: ['eslint:recommended', 'plugin:prettier/recommended'],对于 TypeScript 项目，可以调整成：
extends: [ 'eslint:recommended', 'plugin:@typescript-eslint/recommended', 'plugin:prettier/recommended', ], parser: '@typescript-eslint/parser',至于 ESLint 9 的新格式eslint.config.js，写法差异比较大，大概长这样：
import js from '@eslint/js'; import prettier from 'eslint-config-prettier'; import eslintPluginPrettier from 'eslint-plugin-prettier'; export default [ js.configs.recommended, { files: ['**/*.{js,mjs,cjs,vue}'], plugins: { prettier: eslintPluginPrettier, }, rules: { 'prettier/prettier': 'error', }, }, prettier, ];如果项目不是新建的，我建议暂时不用追新，等你搞清楚了旧格式能稳定跑起来，再去了解新格式也不吃亏。工具的作用是服务开发效率，不是追版本号。
3.2 Prettier 配置：一套让团队吵不起来的默认值
Prettier 的配置文件推荐用.prettierrc或.prettierrc.json。我常用的配置如下：
{ "printWidth": 100, "tabWidth": 2, "useTabs": false, "semi": false, "singleQuote": true, "trailingComma": "es5", "bracketSpacing": true, "arrowParens": "always", "endOfLine": "auto" }每个参数的含义我挑重点解释一下：
printWidth：单行最大宽度，超过就换行。我习惯设 100，也有人喜欢 80，这没有绝对标准，团队统一就行。semi：是否使用分号。我团队选择 false，也就是代码行尾不加分号，这是 Prettier 社区里比较流行的一种风格。singleQuote：字符串用单引号。这个基本是前端主流风格。trailingComma：多行对象、数组最后一个元素后面是否加逗号。es5表示 ES5 支持的地方加，比如对象和数组；函数参数列表不加。arrowParens：箭头函数参数是否加括号。always表示始终加括号，比如(x) => x。
这个配置文件写完后，Prettier 会严格遵守。IDEA 里的 Prettier 插件会自动读取项目根目录下的这个文件，不需要额外指定。
3.3 用 plugin:prettier/recommended 把两者粘起来
为什么强调在 ESLint 的 extends 里必须加plugin:prettier/recommended，而不是只装 eslit-config-prettier？
我试过只加 eslint-config-prettier 的情况，结果是：ESLint 不再报那些和 Prettier 冲突的格式错误了，但 Prettier 本身没接入 ESLint，你在 IDEA 里保存文件时，ESLint 不会自动帮你按 Prettier 规则修复。你可能要手动按 Ctrl+Alt+L 去格式化一次，或者靠运行命令来修复，体验比较割裂。
而加了plugin:prettier/recommended后，Prettier 的规则会以prettier/prettier这条 ESLint 规则的形式存在。也就是说，只要代码格式不符合 .prettierrc 的规则，ESLint 就会把这个问题当作一个 error 报出来，并且可以通过--fix自动修复。这样，IDEA 的保存时自动修复功能就能直接调用 Prettier 的逻辑，真正做到“保存即格式化”。
从原理上讲，这就像是在 ESLint 这个“纪律委员”手下安排了一个专职“排版工”，“纪律委员”看到排版有问题，直接喊“排版工”过来处理。你不需要在 IDEA 里同时维护两套触发机制，省了不少事。
4. IDEA 里的关键设置：让保存即生效
4.1 ESLint 插件配置入口
IDEA 的 ESLint 配置在：Settings -> Languages & Frameworks -> JavaScript -> Code Quality Tools -> ESLint。
打开后，推荐选择Manual ESLint configuration，这样能主动控制 ESLint 的包路径和生效范围。
这里有几个重点字段：
- ESLint package：必须指向项目 node_modules 里的 eslint 包。你可以点击后面的文件夹图标，一直选到项目下的
node_modules/eslint这一层，IDEA 才能正确加载 ESLint。很多时候 ESLint 不生效，八成是这里没配好，IDEA 用的是它自己内置的另一个解析器，读不到项目规则。 - Working directory：一般是当前项目目录，留空默认走项目根目录也可以。
- Node interpreter：如果系统装了 Node，IDEA 一般会自动探测到。如果没识别出来，就手动选择 Node 可执行文件路径。
- Extra eslint options：如果你只想对 src 目录做检查，或者需要指定额外的扩展名，可以在这里写。比如
--ext .js,.vue。
最关键的一步是勾选Run eslint --fix on save。勾上之后，每次保存文件，IDEA 都会自动跑一次eslint --fix，把代码里能自动修复的问题直接修掉，不需要你手动触发。
这个功能我用下来最直观的感受是：写完代码保存一下，未用变量、缺失分号、单双引号不统一这些低级别问题瞬间清理干净。剩下的是那些需要人工判断的问题，IDEA 会用红色波浪线标出来。
4.2 Prettier 与保存时格式化
Prettier 在 IDEA 里的配置入口在：Settings -> Languages & Frameworks -> JavaScript -> Prettier。
这里主要设置两件事：
第一，Prettier package要指向项目 node_modules 里的 prettier 包。这个不指对，IDEA 会报找不到模块，或者用旧版本解析规则。
第二，勾选格式化触发方式。IDEA 的 Prettier 配置里也有On save相关选项，可以设置为保存时自动格式化。但是注意，我这里建议大家不要同时把 ESLint 的 on save 和 Prettier 的 on save 两个都打开。
为什么？我实际遇到过：同时开两个保存钩子后，每次保存文件，Prettier 先排版一遍，ESLint 再修复一遍，有些规则顺序不对可能导致代码反复横跳。特别是像尾逗号、分号这类两个工具都有权管的地方，可能出现“Prettier 改完、ESLint 又改回来”或者相反的情况，最后代码风格还是乱的。
我的建议是：保存时自动修复交给 ESLint 的--fix，因为plugin:prettier/recommended已经让 ESLint 能调 Prettier 的逻辑了，一次保存能同时解决质量问题和格式问题。Prettier 的 on save 可以关掉，或者保留但只在两者不冲突时用，具体看项目情况。
如果你就是习惯手动格式化，那更简单，只要配置好 Prettier package 路径，在文件里按快捷键就能触发 Prettier。
4.3 手动格式化与快捷键的坑
IDEA 里原本的格式化快捷键是 Ctrl+Alt+L，对应的是 IDEA 自己内置的 Reformat Code。在老版本 IDEA 里，这个快捷键默认走的是 IDEA 自带的代码样式，而不是 Prettier。如果没注意，你可能按了快捷键以为在跑 Prettier，实际跑的是 IDEA 另一种格式化逻辑，结果跟项目里的 Prettier 风格对不上。
新版本 IDEA 装了 Prettier 插件后，Ctrl+Alt+L 的行为会变成优先调用 Prettier，但不同版本表现不一样。稳妥的做法是：在 Settings -> Keymap 里搜Reformat with Prettier，看有没有分配快捷键，手动指定一个自己顺手的快捷键，比如 Ctrl+Alt+Shift+L。这样你按快捷键时明确是在跑 Prettier，而不是 IDEA 内置格式化。
有人可能会问：那我直接把 IDEA 自带的代码样式改成和 Prettier 一样，不就行了？理论上可以，实际上很难维护。IDEA 自带的代码样式配置非常细，跟 Prettier 的规则不是一一对应的，你很难做到完全一致。与其花大量时间调 IDEA 代码样式，不如让 Prettier 接管所有格式化，IDEA 自带格式化只在个别场景用。
从工程效率来看，这里最省心的方案是：靠保存时触发 ESLint --fix 做自动修复，按快捷键时明确使用 Reformat with Prettier，手动操作有兜底。这样无论怎么触发，最终落到代码上的格式规则都是同一套。
5. 高频问题与排查实录
5.1 ESLint 规则一直爆红但就是不自动修复
这是最常见的现象：IDEA 里代码下面很多红色波浪线，但保存的时候不修复，甚至右键菜单里也找不到 eslint --fix 相关选项。
大概率原因是Run eslint --fix on save没开。这一点在 IDEA 新版本里有个小坑：默认设置可能没有勾，装完插件后需要手动去 ESLint 配置面板里勾上。
另一个可能原因是 ESLint 配置文件的 env 没配好，比如代码里用了process，但 env 里没有 node，ESLint 会报 no-undef。这类问题属于 ESLint 本身能力范围内，但它不会自动修，因为它涉及的是“判断有没有定义变量”，而不是“格式问题”。解决办法是修正配置，把用到的环境变量声明到 env 里。
还有一种情况是 ESLint 包路径没选对。IDEA 找不到项目 node_modules 里的 eslint，就只能用一个内置的默认检查器，规则完全不对，错误提示也和项目里的 .eslintrc.js 不一致。这种情况下首先要解决的是路径问题，而不是规则问题。
我自己遇到过一整个下午配置不生效的情况，最后发现是 IDEA 里 ESLint package 选错了层级，选到了 eslint 包的上层目录，IDEA 识别不到。正确做法是从 node_modules 里展开后精确定位到 eslint 目录那一层。
5.2 Prettier 格式化结果和 ESLint 冲突
这里说的冲突，最常见的是：按 Prettier 格式化后，ESLint 又报格式错误；或者 ESLint 修完，Prettier 再格式化，代码又变回原样。
原因很直接：ESLint 里某些格式规则没有关掉，和 Prettier 的规则掐起来了。典型的就是indent、quotes、semi这三条。ESLint 默认的 recommended 规则集里，像no-mixed-spaces-and-tabs、quotes这类并没有全部开启，但你如果自己手写在 rules 里加了一些格式规则，就容易冲突。
解决办法就是我在前面强调过的：不要自己手写格式规则，直接用plugin:prettier/recommended。它会把 ESLint 里能跟 Prettier 冲突的规则全关掉，让格式化这块完全交给 Prettier 决定。如果你项目里已经有手写的格式规则，并且跟 Prettier 冲突，建议逐一清掉，只留下真正的代码质量规则。
5.3 Vue/TS 项目中的额外处理
Vue 项目配 ESLint 时，容易出两个问题。
第一个是.vue文件解析失败，报错类似Parsing error: Unexpected token。这是因为你没装eslint-plugin-vue，或者 extends 里没引入plugin:vue/vue3-recommended。不加这个插件，ESLint 看不懂 .vue 文件的模板部分，自然就报语法错误。
第二个是vue/multi-word-component-names规则。Vue 官方推荐组件文件名用多个单词，比如user-card.vue，避免和原生 HTML 标签冲突。如果你的组件叫Index.vue，这条规则会报警。处理方式有两种：要么改组件名，要么在 rules 里关闭这条规则：
rules: { 'vue/multi-word-component-names': 'off', }我一般建议团队里保留这条规则，新建文件时尽量用多单词命名，这样组件可读性好很多。
TypeScript 项目的话，重点就是 parser 要换成@typescript-eslint/parser，extends 里加plugin:@typescript-eslint/recommended。不然 ESLint 会把 TS 的类型语法当成普通 JS 去解析，报一堆解析错误。装了之后，像 no-unused-vars 这类规则也会根据 TS 的情况自动处理，不用自己额外适配。
5.4 常见问题速查表
我把平时答疑遇到的高频问题整理成一张表，方便直接查：
| 问题现象 | 大概率原因 | 解决办法 |
|---|---|---|
| IDEA 里 ESLint 完全不报错 | ESLint 插件未启用，或 package 路径没指向 node_modules/eslint | 到 ESLint 配置面板手动指定包路径 |
| 保存时格式不自动修复 | 没勾 Run eslint --fix on save | 在 ESLint 配置里勾选该选项 |
| 保存时修复和格式化冲突，代码反复横跳 | ESLint on save 和 Prettier on save 同时开启 | 只保留 ESLint --fix，关闭 Prettier on save |
| 格式错误提示来自 prettier/prettier | Prettier 规则被当作 ESLint 错误提示，说明配置正确 | 确认 .prettierrc 与团队风格一致即可 |
| Ctrl+Alt+L 格式化结果不像 Prettier | IDEA 内置格式化接管 | 用 Reformat with Prettier 或改快捷键 |
| .vue 文件语法报错 | 缺 eslint-plugin-vue | npm install -D eslint-plugin-vue 并在 extends 引入 |
| TS 语法报错 | 缺 @typescript-eslint/parser | 安装对应包并配置 parser |
| ESLint 不识别项目配置文件 | IDEA 版本过老 | 升级 IDEA 到较新版本 |
5.5 配置完成后如何快速验证
配置完成后，别急着开始写代码，我一般会先做个快速验证，确认整套链路是通的。
随便打开一个 js 文件，故意写几行不规范代码，比如：
var name="张三" const fn=(a)=>{ console.log(a) }然后观察：
第一，IDEA 是否出现 ESLint 报错。如果有红色波浪线提示no-var或prettier/prettier，说明 ESLint 已经读到配置。
第二，保存文件，看是否自动修复。修完应该是：
const name = '张三' const fn = (a) => { console.log(a) }如果保存后代码变成这样，说明整套配置完全生效，ESLint 和 Prettier 配合正常。
如果保存后没反应，检查第一步的设置项，重点看 ESLint package 路径和 on save 勾选项。整个验证过程不会超过两分钟，但能避免你写出几百行代码后才发现工具没起作用的情况。
最后再分享一个我个人的使用习惯：配置好之后，我会在 package.json 里加上 lint 和 format 脚本：
{ "scripts": { "lint": "eslint src --ext .js,.vue,.ts", "lint:fix": "eslint src --ext .js,.vue,.ts --fix", "format": "prettier --write src" } }这样不仅仅是 IDEA 里能用，命令行里也能跑。将来接 CI/CD 流水线时，直接在流水线里执行npm run lint就可以对代码做检查，统一门禁。IDEA 里的配置解决的是“平时开发时的体验”，脚本解决的是“提交时的强制规范”，两件事配合起来，代码风格才真正管得住。
