三个格式化工具，一场没有硝烟的战争
2024年，一个前端团队的代码仓库里，关于用分号还是不用分号的争论，可能比关于产品方向的争论还要激烈。这不是段子，是每天都在发生的真实场景。
ESLint、Prettier、Biome，三个工具，三种哲学。你的团队该选哪个？这个问题没有标准答案，但有更接近真相的答案。
先搞清楚一件事：Lint和Format不是一回事
很多人把ESLint和Prettier混为一谈，这是第一个误区。
ESLint是规则警察，它管的是代码质量：有没有声明未使用、有没有隐式类型转换、有没有console.log漏删。Prettier是排版工人，它只管格式：缩进几个空格、字符串用单引号还是双引号、行宽多少换行。
打个比方，ESLint管你写的内容对不对，Prettier管你写的姿势好不好看。
Biome则是个狠角色，它想同时干这两件事。用Rust写的，号称比ESLint快10倍，比Prettier快7倍。这个数字来自Biome官方博客的benchmark，不是第三方测试。
ESLint：老牌王者，但有点累
ESLint诞生于2013年，是当前JavaScript生态使用最广泛的Lint工具。据npm统计，ESLint每周下载量超过3000万次。
它最大的优势是生态。插件体系极其成熟，TypeScript、React、Vue、Node.js，几乎所有场景都有对应的配置。ESLint的规则数量超过300条，加上社区插件，实际可用的规则上千条。
但它的缺点也很明显：慢。一个中型项目跑一次完整Lint，可能需要几十秒。而且配置复杂，一个典型的ESLint配置文件动辄上百行，新手看了直接劝退。
还有个尴尬的问题：ESLint本身不负责格式化，但很多团队把Prettier集成进来，通过eslint-plugin-prettier把Prettier的规则变成ESLint规则。这导致每次保存文件，先跑Prettier格式化，再跑ESLint检查，两趟下来，编辑器卡顿是常有的事。
Prettier：格式化领域的标杆
Prettier的思路和ESLint完全不同。它的态度是：别跟我讨论格式，我的格式就是标准，你只需要接受。
这个设计理念在2017年刚推出时被很多人骂，但后来证明是成功的。格式问题本来就是主观的，与其让团队争论不休，不如用工具一刀切。Prettier的规则极少，核心配置就那么几个：单引号还是双引号、是否加分号、缩进宽度、行宽。
Prettier的周下载量超过6000万次，是ESLint的两倍。几乎所有主流编辑器都有Prettier插件，保存即格式化，体验很顺滑。
但它不管代码质量。你写了个未定义的变量，Prettier不会报错。所以很多团队是ESLint加Prettier一起用，各司其职。这带来一个问题：两个工具，两套配置，两倍的维护成本。
Biome：新势力的野心
Biome在2023年开源，用Rust写的，目标很直接：替代ESLint和Prettier，一个工具搞定所有事。
性能是它的最大卖点。Biome官方宣称，在大型代码库上，它的格式化速度是Prettier的7倍，Lint速度是ESLint的10倍。这个数据被一些独立开发者验证过，比如Twitter上有人测试过，在10万行代码的项目上，Biome格式化只需1.2秒，Prettier需要8.6秒。
Biome的配置比ESLint简单得多，默认配置就能用，也支持自定义规则。它还内置了导入排序、文件格式化等功能，这些在ESLint生态里需要装好几个插件才能实现。
但Biome的生态还很薄弱。ESLint有上千条规则，Biome目前只有100多条。一些特定框架的规则，比如React Hooks的exhaustive-deps，Biome还不支持。这意味着如果你用了某些冷门框架或高级特性，Biome可能帮不上忙。
怎么选？看团队规模和项目阶段
小团队，新项目，没有历史包袱，Biome值得认真考虑。配置简单，性能快，一个工具搞定格式和Lint，开发体验很爽。目前Biome已经发布了1.0版本，API稳定，可以用于生产环境。
中大型团队，已有存量代码，ESLint加Prettier还是最稳妥的选择。生态成熟，规则全面，团队成员的既有经验可以直接复用。虽然性能慢一点，但可以通过只Lint改动文件、配置缓存等方式优化。
还有个折中方案：用Prettier做格式化，用ESLint做代码检查，但把ESLint的格式相关规则全部关掉，避免两套格式规则冲突。这个方案在前端圈子里比较流行，也被Vue、React等官方推荐。
说句实话，工具之争从来不是技术之争，而是团队习惯之争。选哪个工具不重要，重要的是团队能达成一致，不再为格式问题浪费时间。如果Biome能让你的团队少吵一架，那它就是好工具。
换工具的成本，往往比工具本身的优劣更值得考虑。