ESLint vs Prettier：代码格式化真的需要两个工具吗？

一个前端项目初始化时，几乎都会遇到这个问题：ESLint 和 Prettier，到底装哪个？还是两个都装？

2023年 Stack Overflow 的调查显示，87.6% 的开发者使用 ESLint，而 Prettier 的使用率也达到了 78.3%。两个工具同时存在，已经成了行业默认配置。但说真的，你问 10 个前端，至少有 5 个说不清它们到底有什么区别。

它们压根不是同一类工具

很多人以为 ESLint 和 Prettier 都是格式化代码的，挑一个用就行。这个理解从一开始就错了。

ESLint 的核心工作是找错。它检查代码是否符合最佳实践，有没有未使用的变量，是不是写了 == 而不是 ===。说白了，它是个代码质量检测器。

Prettier 的核心工作是排版。它不管你的代码逻辑对不对，只负责把代码变得整齐。比如单引号还是双引号，行尾要不要加分号，缩进用两个空格还是四个。

一个管"好不好"，一个管"美不美"。这是两个维度的事。

冲突的地方在哪

问题出在它们都管了同一件事：代码风格。

ESLint 有个叫 max-len 的规则，限制每行最多 80 个字符。Prettier 也有 printWidth 参数，干的是同一件事。你设了 80，它设了 100，就会打架。

2019 年的一个 GitHub issue 里，开发者抱怨最多的就是两个工具互相覆盖规则，导致保存文件时反复格式化，甚至出现死循环。这种情况在大型项目中尤其常见。

解决办法其实简单：让 Prettier 管格式，ESLint 只管逻辑。

具体做法是，在 ESLint 配置里关掉所有和格式相关的规则，比如 indent、quotes、semi 这些。然后用 eslint-config-prettier 这个插件，一键屏蔽冲突规则。

只用一个行不行

可以，但会有代价。

只装 ESLint，你能控制代码质量，但格式化得靠自己手调。团队里有人习惯用 2 空格，有人用 4 空格，每次 code review 都在争论缩进问题。

只装 Prettier，代码会变得非常整齐，但没人帮你检查有没有写了 var 而不是 const，有没有在循环里创建函数。

GitHub 上有个叫 standard 的项目，试图用一个工具同时搞定格式和质量。它内置了一套严格规则，用的人要么很喜欢，要么很讨厌。因为它不让你自定义——你只能接受它的风格。

现在的新选择

2023 年，Rome 工具链和 Biome 开始进入视野。它们的目标是把 ESLint 和 Prettier 合并成一个工具。

Biome 的官方文档说，它的格式化速度比 Prettier 快 10 倍，同时内置了 100 多条 lint 规则。目前还在快速迭代中，但已经有不少项目在试用。

不过话说回来，对于大多数团队，两个都装依然是性价比最高的方案。ESLint 负责"别写 bug"，Prettier 负责"别吵了，统一风格"。分工明确，各司其职。

配置好之后，你只需要记住一个命令：npx eslint --fix 或者保存文件时自动触发。剩下的交给工具。

总结一下

ESLint 和 Prettier 不是二选一的关系。一个管代码质量，一个管代码格式。冲突的地方通过配置解决，不是通过取舍。

如果你正在搭建新项目，直接两个都装上。花 10 分钟配好 eslint-config-prettier，省下的是未来几个月甚至几年的格式争吵。

工具是为人服务的，不是反过来。