就在最近，ESLint 发布了备受瞩目的 10.0 版本。回想几年前，每当 ESLint 进行一次大版本更新，开发者们总会第一时间去关注新增了哪些规则、性能有没有提升、运行速度是不是又“起飞了”。但现在，更多人的第一反应却变成了：它还能跑得动吗？
ESLint 10.0 终于来了。
放在几年前，大家会第一时间去看新规则、看性能、看是不是“起飞了”。
而如今，更多人的第一反应是：它还能不能用？
这倒不是 ESLint 做得不行了，而是我们有了更好的选择！
这一次，ESLint 做的是“清账”
如果你去细看 ESLint 10.0 的改动，会发现一个非常明显的特征：
没有颠覆式的新能力，也没有“效率暴涨”的故事，更多是在干一件事——把旧时代留下的东西彻底收拾干净。
eslintrc 正式退出历史舞台，Flat Config 成为唯一选择；
老 API 被移除，Node 版本门槛被抬高；
配置查找逻辑也终于变得更符合现代工程的直觉。
从工具作者的视角看，这一步非常必要。
但从使用者角度来看，获得感并不强。
更像一句话：“它终于不再拖后腿了。”
问题是，外面的世界已经变了
ESLint 在做整理的时候，前端工具链并没有停下来等它。
这两年，一个很明显的变化是：
大家开始认真讨论——ESLint 是不是必须的？
这个问题本身，就已经说明了一切。
oxlint：不聊理想，只想跑得快
oxlint 是尤雨溪团队推出的现代 lint 工具，完全用 Rust 编写。
出现一年多时间后，它已经不是一个实验品，而是一个非常能打的替代方案。
最新的 benchmark 给出的数据很直接：
在相同配置下，oxlint 的 lint 速度相比 ESLint 要快 50到100 倍。同一份代码，ESLint 可能要跑三十多秒，而 oxlint 多线程下只需 0.6 秒左右。
即便和同样基于 Rust 的 Biome 相比，oxlint 在纯 lint 场景下，通常也还能快接近 2 倍。
规则方面，oxlint 目前已经内置了超过 500 条核心规则，对大量常见 ESLint 规则的兼容性都很不错，而且可以直接读取 ESLint 的既有配置，迁移成本并不高。
从社区数据看，它的增长也非常快，目前累计下载量已经超过160万，而且还在持续上升。
现在再说 oxlint 只是“快”，已经不准了。
它是真正把 ESLint 的性能瓶颈，推向了历史。
Biome：不止于 lint
Biome 的定位和 oxlint 有些不同。
它不只是一个 lint 工具，而是想做一套统一的前端工具链。
lint、format、import sort 等功能全部内置，用一个 biome.json，就能覆盖过去 ESLint + Prettier + 各种插件的组合。
社区里的实际使用反馈也很直观：
在一些中型代码库里，Biome 做 lint + format 的整体耗时，往往比传统 ESLint + Prettier 要快 20 倍左右。
目前 Biome 内置了大约 300 多条 lint 规则，formatter 的兼容性也已经相当不错。
在 GitHub 上，它已经拿到了超过 23k star，是一个成长非常快的项目。
对新项目来说，这种“少装工具、少配配置”的体验，本身就是非常实在的生产力提升。
所以，ESLint 10.0 尚能饭否？
如果只看“能不能 lint”这件事，答案其实已经很清楚了。
在绝大多数项目里，oxlint 或 Biome 已经可以直接替代 ESLint，而且这是正在发生的事实。
不少大型乃至超大型开源项目，已经在社区分享过迁移案例：ESLint 整套移除，CI 时间从几十秒降到一两秒，本地开发几近无感。
而这种速度提升，并不是靠牺牲规则换来的。
日常项目真正用到的那部分 ESLint 规则，oxlint 和 Biome 基本都能覆盖。
在这种情况下，ESLint 已经不再是默认答案。
如果你的项目没有强依赖极少数特殊规则，那反而需要一个理由，去继续使用 ESLint。
ESLint 10 当然还能用。
只是现在，它更像是被绕开的那一个，而不是第一个被选择的工具。
