尤雨溪官宣这件事我是从朋友圈刷到的。第一反应是“又来了”毕竟前端工具链这两年隔三差五就有人喊“颠覆”热点来得快去得也快。但瞄了一眼细节——基于 Rust 重写的格式化工具官方口径是比 Prettier 快 45 倍——我立刻有点坐不住了。因为说实话Prettier 慢不慢每个在大型前端项目里做过全量格式化的同学心里都有数。我当天下午就在手头一个 Vue3 TypeScript 项目里跑了一轮实测。结论先放这儿45 倍这个数字不是营销话术但也不是所有场景都成立我的实际测试在 20 到 60 倍之间浮动看项目文件构成。关键是这款新工具让我们看到了“格式化”这件事在新一代前端工具链里的真正位置。这篇文章我会从背景、实测、配置迁移、坑点到生态前景全部讲一遍尽量让读完的你也能自己上手判断。1. 这条官宣到底在说什么定位与背景1.1 不是又一个格式化插件而是整个工具链的重写起点市面上“比 Prettier 快”的工具不是没有出现过。之前 Biome 也主打“秒杀 Prettier”但说实话生态一直不温不火原因很大程度在于迁移成本大家已经在用 Prettier 的配置、插件和编辑器集成凭什么为了“快”去折腾一遍这次不一样的地方在于它出自尤雨溪领衔的 Oxc 项目体系。Oxc 不是单个工具而是一整套基于 Rust 的 JavaScript 工具链计划目标是逐步覆盖解析、转换、压缩、lint、格式化这些前端工程化里的核心环节。这套工具链里lint 工具 oxlint 已经跑到过 ESLint 的数倍甚至数十倍性能格式化器则是对 Prettier 生态最正面的一次挑战。所以尤雨溪这次官宣本质上是在给一个更大的叙事定调前端工具链的性能瓶颈要从根上解决而不是靠打补丁。格式化快 45 倍只是一个起点后面跟着的是一整套“编译器级别”的基础设施。1.2 为什么 Prettier 会慢Rust 为什么快要理解这个 45 倍得先明白 Prettier 的性能瓶颈在哪儿。Prettier 是用 JavaScript 写的。JS 本身是动态类型、垃圾回收的语言跑在 V8 这类 JIT 引擎上。单个文件格式化的时候几毫秒到几十毫秒体感不明显但一碰到几百上千个文件的全量格式化CPU 密集型的字符串解析和 AST 遍历就会成倍放大开销。再加上 Prettier 的格式化流程里解析、打印、对比、写盘是串行的中间还有个“检查是否需要改动”的回读过程多文件场景下大量内存分配和 GC 停顿就会被拉满。Rust 的优势一句话就能说清楚编译型、无 GC、内存布局紧凑、能直接利用多核并行。Oxc 这套工具在架构上从第一天就把“并行处理多文件”当成基本设计而不是事后优化。再加上底层解析器用 Rust 重写不做 JS 解析器那种历史包袱所以快不是“稍微快一点”而是数量级上的差异。我自己的理解是45 倍这个数字更多是“全量格式化多文件”场景下的体现。单文件单次格式化再快你也感知不出来但到了 commit 前全部文件检查、CI 里跑格式校验、大型 monorepo 里做统一格式化的时候这个差距就会变成实打实的效率提升。1.3 45 倍这个数字到底有没有水分我实际跑下来结论是“没太大水分但要看你怎么测”。官方基准里 45 倍大概率是拿大文件、多文件、并行的极端案例算出来的。我的项目里比较大的 TypeScript 文件单文件格式化大概快 10 倍左右但一跑全量因为并行调度好整体提升就非常可观接近 50 倍。其实比起纠结“45 倍准不准”更应该关注的是“它以后会不会越来越快”。一个新工具刚发布时的性能往往不是它的上限因为还有大量优化空间。反过来Prettier 作为运行了十年的老项目已经在性能上逼近 JS 方案的极限了。方向一旦变了后面的差距只会越拉越大。2. 我对新格式化工具实测后的整体感受2.1 安装和接入方式比想象中简单我原以为这玩意儿要配一堆环境实际装下来就是一条命令的事。我是先在临时目录里做的验证项目根目录直接执行npx oxfmt --version如果这个命令在当前版本不可用说明官方可能调整了 CLI 入口你直接看它 README 里的命令说明就行。我这边测的时候它会把格式化器作为一个独立的 npm 包拉下来底层是编译好的原生二进制不依赖本地 Rust 环境。装完之后我做的第一件事是生成配置文件。目前的策略是兼容 Prettier 的那套常见配置我直接把项目里的.prettierrc.json内容复制到新工具对应的配置里基本没有改动。这一步我觉得很重要——迁移成本足够低才会有人愿意换。2.2 真实项目全量格式化的耗时对比我在一个大约 800 个文件的 Vue3 TypeScript 项目上做了对比。这个项目不算大但文件类型混得比较全有.ts、.vue、.js、.json很接近大多数团队的真实情况。先看 Prettier 的表现time npx prettier --write src/**/*.{ts,vue,js,json}跑完差不多用了 23 秒其中有大半时间花在启动和文件扫描上。说实话这个速度在日常开发里已经能接受但在 CI 里每次都要等 20 多秒多少有点烦躁。再看新格式化工具time npx oxfmt --write src/**/*.{ts,vue,js,json}跑完大概是 1.1 秒其中还包含首次启动的开销。我把这个测试连续跑了好几遍确认不是缓存加成两次之间的提升倍数在 20 倍上下。如果去掉启动开销只看纯格式化时间那到 45 倍是合理推测。我又单独拆了几个大文件做对比一个 2000 行的状态管理模块Prettier 格式化耗时 120ms新工具耗时 11ms差距约 11 倍。倍数最夸张的场景确实是“很多文件 并行执行”单文件场景反而体现不出优势。2.3 编辑器体验少了那种“卡一下”的感觉除了命令行我也装了对应的 VS Code 扩展。这里分享一个很直观的感受以前在 Prettier 里打开一个几百行的文件按下保存偶尔能感觉到光标顿一下然后格式化后的内容刷出来。尤其是 Vue SFC 文件因为里面要处理 template、script、style 三种区块格式化的计算量会更大。换了新工具之后我专门挑了一个很大的 Vue 文件反复测试保存格式化的延迟基本感知不到就是“按下保存、代码瞬间对齐”的状态。这对日常开发体验的提升比命令行的倍数数字更让我觉得值。3. 配置迁移与兼容性细节能直接替换 Prettier 吗3.1 从 .prettierrc 迁移配置先说结论常见的 Prettier 配置项覆盖度已经相当高。这是我测下来最让我放心的地方。Prettier 里团队用得最多的配置无非是这些配置项我原来的值迁移情况semitrue直接支持singleQuotetrue直接支持trailingCommaall直接支持printWidth100直接支持tabWidth2直接支持arrowParensalways直接支持endOfLinelf直接支持我的操作步骤基本是三步在项目里新建格式化工具对应的配置文件把原有.prettierrc.json的内容复制过去删掉 VSCode 工作区里强制指定 Prettier 作为默认格式化器的设置打开几个代表性文件跑一遍format肉眼对比 git diff。第三步是最关键的。不要相信文档说的“完全兼容”要相信你项目里的真实文件。我做完之后发现绝大多数文件只有少量差异而且这些差异大多集中在“Prettier 已有的格式决策和 Oxc 的实现细节不一致”上不是理解层面的错误。3.2 格式差异集中出现在哪里我专门整理了一批出现差异的文件发现规律挺明显。第一类是长行自动换行。Prettier 和 Oxc 在 printWidth 边界上的判断有一些细微不同比如链式调用、条件表达式、可选链混合在一起的时候换行位置的取舍会有差异。这个不仔细看根本发现不了但如果在团队规范里属于“必须一致”的内容切换前就要想清楚。第二类是模板字符串和嵌套表达式的缩进处理。Vue 模板里的插值表达式、复杂的三元运算符嵌套两边格式化出来的风格偶尔不一样不过语义上是等价的。第三类是注释的吸附。行内注释、尾部注释在代码重排时挂在哪个节点上Prettier 有一套很细的规则Oxc 基本兼容了大头但少数怪异的注释位置会有偏差。我的建议是如果你只是想“尝鲜试试速度”不用急着全量切如果是想真正落地到团队先在主力项目里跑一次全量格式化把差异拉到 git diff 里人工过一遍确认能接受后再切换。3.3 还不能替代 Prettier 的场景这是我觉得必须诚实说清楚的部分。至少在我测试的版本里还有几个场景是不建议直接替换的。一是插件生态。Prettier 最值钱的资产之一就是插件机制比如很多人用的prettier-plugin-tailwindcss能把 Tailwind 的 class 按官方推荐顺序排序。这类依赖 Prettier 内部 API 的插件新工具短期内肯定没法无缝兼容。如果你的团队重度依赖这类插件现在还不是切换的时机。二是Markdown 和 YAML 的支持成熟度。Prettier 处理 Markdown 的能力虽然不算多惊艳但够用新工具目前的重心明显在 JS/TS/Vue 这类“代码文件”上文档类的格式化能力我实测下来还有不少细节没对齐。文档为主的项目建议继续用 Prettier。三是老旧的 Babel/Flow 项目。Prettier 对老语法、奇怪语法的容错率非常高属于“怎么都能格式化”的类型。新工具起步更晚对现代 ECMAScript 标准的支持很好但遇到极其冷门的语法时偶尔会有无法解析的情况。新项目随便切老项目先做一次全量文件扫描再说。4. 与现有前端工程化的配合4.1 如何在 Vue3 TypeScript 项目里接入我实际的落地路径是分两步走的这里给你一个可以直接抄的作业。第一步配置默认格式化器。我的编辑器是 VS Code在项目根目录的.vscode/settings.json里修改{ editor.defaultFormatter: oxc.format, editor.formatOnSave: true }这样保存文件的时候就会默认走新的格式化工具。注意如果你的团队里还有同事在用 Prettier这个改动会直接影响他们的保存行为所以最好提前在群里说一声。第二步把命令行格式化接进 package.json 的脚本里。我习惯保留一个统一入口方便 CI 和本地共用{ scripts: { format: oxfmt --write \src/**/*.{ts,vue,js,json}\, format:check: oxfmt --check \src/**/*.{ts,vue,js,json}\ } }--check这个命令很重要它不写文件只检查格式是否符合规范CI 里一般用它来做格式门禁。原来用 Prettier 的时候prettier --check在几百个文件上也要跑不少时间换了新工具之后这步在 CI 里基本就是几秒钟的事。4.2 用 lint-staged 接进 git hooks格式化工具最理想的触发时机是提交前而不是提交后。以前我在项目里用的是husky lint-staged的组合核心逻辑是每次 commit只对暂存区里的文件做检查或格式化避免全量跑浪费性能。原来的配置长这样{ husky: { hooks: { pre-commit: lint-staged } }, lint-staged: { *.{ts,vue,js,json}: [ prettier --write ] } }接入新工具后我把最后一行改成{ lint-staged: { *.{ts,vue,js,json}: [ oxfmt --write ] } }跑起来之后我发现一个额外的好处以前 lint-staged 对单文件执行 Prettier单个文件也就几十毫秒差距不大但如果在 monorepo 里一次改了十几个文件新工具的并行处理能力就能明显拉开差距。大仓场景下pre-commit 的耗时从十几秒压缩到了两三秒这体验提升简直是质变。4.3 CI 里的缓存策略CI 里最怕的不是工具本身慢而是“每次都从头跑一遍”。所以我习惯在 CI 里加一层缓存逻辑让“文件内容没变”的时候能直接跳过格式检查。做法其实很简单把格式化检查命令挂到一个基于内容哈希的缓存后面。比如用 Turborepo 或者 Nx它们天然支持基于输入文件哈希的任务缓存。我在项目里的配置大致是这样的思路# 用 git 计算本次变更涉及的源码文件集合 # 如果这些文件的哈希没有变化直接跳过格式化检查具体实现会因为 CI 平台不一样而不同但核心思路是一致的格式化检查要做的不是“每次都证明所有文件没问题”而是“证明本次改动的文件没问题”。在这个前提下新工具的超快速度更像是买了一份保险——即使哪天缓存失效了全量检查也能在几秒内跑完不会把 CI 卡死。5. 常见问题与排查实录5.1 常见报错从“找不到二进制”到“格式漂移”我实际使用过程中遇到过几个典型问题这里整理成速查表你大概率也会碰到。问题可能原因解决办法command not found: oxfmt未安装全局命令或 npx 缓存异常用npx oxfmt或通过 devDependencies 安装到本地格式化结果和 Prettier 大范围不一致配置文件没有正确加载检查配置文件命名是否符合工具要求最好显式指定配置路径某些文件被跳过、提示 parse error文件里有工具暂不支持的冷门语法用--ignore-path暂时排除同时给官方提 issue格式化后 git diff 变化巨大之前 Prettier 留下大量历史欠账建议单独提交一次“格式化迁移”commit让 blамe 能追溯第五个问题其实不是新工具特有的只要团队换格式化工具都会遇到一次“历史格式大清洗”。我的经验是单独开一个 commit不混任何业务改动在 commit message 里写清楚“chore: 更换格式化工具”这样以后 git blame 追代码的时候不会把格式化相关的改动和业务逻辑混在一起。5.2 行尾符和编码问题这个问题很隐蔽但杀伤力极大。在多平台协作的团队里Windows 上默认 CRLFmacOS/Linux 上是 LF。Prettier 靠endOfLine配置来统一默认值在格式化时会自动转换行尾符。新工具在这个行为上我测试下来默认是“跟随配置”不会自作主张改行尾符。这其实是好事因为不会造成“每次保存都有一堆行尾变更”的假 diff。但坏处是如果团队里有人本地配置是 CRLF提交到仓库后会有行尾符混乱的风险。我的建议是在项目根目录加一个.gitattributes强制源码文件统一 LF* textauto eollf *.ts text eollf *.vue text eollf这一步建议在新工具落地之前就做好能把“格式迁移”和“行尾符迁移”两个变量分开出问题也好定位。5.3 和编辑器自带格式化冲突还有一个特别容易踩的坑团队里可能有人装了多个格式化插件或者编辑器自己带了格式化能力。比如 VSCode 里如果同时装了 Prettier 和新工具的扩展又没有把默认格式化器指定清楚就会发生“保存时被格式化两次”的诡异现象——第一次按新工具格式化第二次又按 Prettier 格式化回去。排查方法很简单在一个文件里故意写乱格式然后按保存观察最终效果和 VSCode 右下角提示用的是哪个格式化器。如果发现两个格式化器在打架就在.vscode/settings.json里把默认格式化器显式锁定然后禁用另一个扩展或者至少在工作区里禁用它。另外还有一个容易忽略的点新工具的格式化结果和 ESLint 的 autofix 规则可能互相覆盖。比如 ESLint 里开了indent规则并且设置了自动修复格式化之后又跑一遍 ESLint autofix那两者可能抢着改同一段代码。这个问题的解法不是“让谁赢”而是调整规则边界格式化交给格式化工具ESLint 只做代码质量检查不要在 ESLint 里重复配置格式类规则。6. 前端工具链接下来会怎么走6.1 Oxc 不是孤立项目linter、transformer、minifier 的布局聊到这可能会有人问“一个格式化工具而已至于这么激动吗”我的看法是真正值得关注的不是格式化本身而是它背后那条完整的工具链路径。Oxc 目前已经在做的有基于 Rust 的 JavaScript 解析器、transformer、minifier、linter也就是 oxlint现在加上 formatter已经覆盖了前端工程化里“解析—转换—检查—格式化—压缩”的大部分核心链路。这意味着什么意味着未来前端构建链路里的重型操作可能不再需要一个个独立的 JS 工具而是由一个统一的高性能原生内核来提供。这对开发者的影响是深远的。以前我们习惯了“ESLint 管质量、Prettier 管格式、Babel/SWC 管转换、Terser 管压缩”每一层都有一套独立的 AST 解析和配置体系。如果 Oxc 能把它们统一起来一次解析、多处复用整个工具链的启动速度和运行性能都会有质的提升。这也就是为什么“格式化快 45 倍”这个数字在我看来只是个开胃菜。6.2 对 Vite/Rolldown 生态的影响尤雨溪本人的另一个重要身份是 Vite 的作者。Vite 在开发模式下已经足够快但生产构建部分长期依赖 Rollup而 Rollup 是用 JS 写的性能天花板非常明显。他之前一直在推 Rolldown也就是用 Rust 写的 Rollup 替代方案目标是把 Vite 的生产构建性能也拉到“原生级”。这次官宣的格式化工具和 Rolldown 在底层是共享 OX 生态的同样的解析器、同样的依赖图谱思路、同样的“用 Rust 重写 JS 工具”哲学。所以我猜测接下来你在 Vite 项目里看到“一键启用 oxfmt”或者“内置 oxfmt 格式化”之类的集成只是时间问题。将来前端项目的标配可能是Vite 负责开发和构建Oxc 负责底层解析、lint、格式化和压缩所有工序都是原生二进制冷启动和热更新的速度都会再上一个台阶。对使用者来说少装几个依赖、少配几个工具本身就是巨大的效率提升。6.3 开发者现在该做什么未来该学什么这里我给个非常务实的建议分阶段讲一讲。短期来看你不需要立刻把项目里的 Prettier 全换掉。新工具还处在快速迭代阶段插件生态和边缘场景的成熟度需要时间。但值得做的是拉一个新的测试项目或者在不影响主分支的分支上跑一遍全量格式化对比自己感受一下差距顺便把团队未来迁移可能要踩的坑先摸清楚。中期来看前端构建工具链的“Rust 化”是不可逆的趋势。这不是说 JS 会没落而是“用 JS 写开发工具”这件事会逐步被更底层、更高性能的方案替代。作为前端工程师不用急着去学 Rust 写编译器但可以开始理解“AST”、“parser”、“transformer”这些概念因为下一代前端工具的核心思路全建立在这些之上。长期来看我个人的判断是以后前端工具的竞争点不再是“功能有没有”而是“性能好不好、生态全不全”。Oxc 这套体系如果能把 lint、format、transform、minify 全部做扎实并且保持对现有配置的兼容它完全有机会成为下一代前端工程化的默认底座。到那时候我们现在讨论的“快 45 倍”可能只是一个历史注脚更快的工具会在它之上继续生长。从我自己的体验来说这次我最大的收获不是省下的那几十秒格式化时间而是亲眼看到了一条“新工具链如何一步步接管旧生态”的真实路径。它不像以前某些工具那样对着文档喊完美兼容而是先解决核心痛点再把兼容性边界一点一点补齐——这种务实又清晰的路线恰恰是前端工具链最需要的。如果你也想试试我的建议是不要从主力仓库开始。找个个人项目或内部小项目先跑通“格式化—检查—提交—CI”的全流程感受一下性能差异再决定要不要推荐给团队。工具好不好用永远跑一遍才知道。