Vize：用 Rust 重写 Vue 工具链，但你先别急着换掉 vue-tsc

一个 Rust 核心，六种工具，但还不是生产就绪

Vize 的目标很直接：用 Rust 重写 Vue 的工具链，让编译、Lint、格式化、类型检查、LSP 和 Story 系统共享同一个解析器。传统 Vue 项目里，@vue/compiler-sfc 管编译，ESLint 加 eslint-plugin-vue 管静态检查，Prettier 管格式化，vue-tsc 管类型检查，每个工具都有自己的解析逻辑，彼此之间还有细微的语义差异。Vize 想用一个核心把这些全包了。它的名字来自 Vizier、Visor 和 Advisor，意思是能看透代码的顾问工具。但 README 开头的警告很显眼：项目处于 Real World Testing 阶段，不是完全生产就绪，breaking changes 和与 Vue 行为的分歧都是预期内的。这个定位决定了后面所有性能数字都要打折看。

性能数字：编译快 52 倍，但类型检查那一行没有速度比

README 给出的基准测试表很具体：在 Blacksmith 的 32 vCPU 机器上，15,000 个 SFC 的编译从 @vue/compiler-sfc 的 17.15 秒降到 Vize 的 329.2 毫秒，约 52 倍。Lint 比 eslint-plugin-vue 快 173 倍，格式化比 Prettier 快 50 倍。这些数字都来自一个固定的提交快照，并且有测试文件把 README 里的数字和基准结果绑定，防止漂移。但注意两个细节。第一，类型检查那一行没有给出速度比，因为 vue-tsc 跑的是 JavaScript 版 TypeScript 编译器，而 vize check 用的是原生 tsgo（Corsa），一个比值会把 TypeScript 的 Go 重写功劳算到 Vue 层头上。这个处理很诚实。第二，Nuxt 构建那一行只快了 1.0 倍，因为两端跑的是同一个 Nitro/Vite/Rollup 管道，SFC 编译只占整个构建的约 2%，所以端到端时间被其他部分主导。这说明 Vize 的性能优势只在编译、Lint、格式化这些纯 SFC 处理环节上明显，对完整构建的影响有限。

接入方式：从替换 Vite 插件到一键初始化

Vize 不提供脚手架，它要求你先有一个 Vue 3 + Vite 或 Nuxt 项目。最短路径是替换 Vite 插件：npm i -D @vizejs/vite-plugin，然后在 vite.config.ts 里把 @vitejs/plugin-vue 换成 vize()。这个 drop-in 只替换 SFC 编译，Lint、格式化、类型检查都还保持原样。如果你想要完整工具链，运行 npx vize init。它会检测你的项目类型，可以添加 Vite 插件或 Nuxt 模块、Oxlint、vize fmt、vize check 以及 VS Code 推荐扩展。init 支持 --dry-run 预览改动，也支持非交互模式：npx vize init --yes --lint --bundler --fmt --typecheck --editor。init 是幂等的，重复运行不会添加重复的插件、脚本或依赖。但 README 明确说，自定义的 vue({ ... }) 选项和不常见的 Vite 配置不会被自动重写。这意味着如果你的 vite.config.ts 里有复杂的 Vue 配置，drop-in 可能不成立，需要手动调整。

类型检查的替代方案：tsgo 与 vue-tsc 的差异

vize check 用的是原生 tsgo（Corsa），这是 TypeScript 的 Go 实现。这意味着它和 vue-tsc 的底层引擎不同，类型检查的语义可能有细微差别。vue-tsc 基于 JavaScript 的 TypeScript 编译器，对 Vue SFC 的类型支持经过了多年打磨，能处理复杂的模板类型推断、泛型组件、以及 vue-tsc 特有的 .vue 文件类型映射。tsgo 虽然快，但它对 Vue SFC 的支持需要 Vize 自己实现，这可能是最薄弱的环节。README 没有给出类型错误捕获率的对比数据，只提到两个计时都是真实的。对于依赖 vue-tsc 做严格类型检查的团队，换到 vize check 意味着要重新验证所有类型检查规则是否生效。如果不验证，可能会漏掉类型错误，这是比性能下降更危险的问题。

一个真实的限制：Nuxt 构建没有明显收益

Nuxt 用户需要特别留意。README 给出的 Nuxt 构建对比是 6.83 秒对 6.59 秒，几乎持平。原因在于 Nuxt 的构建流程里，SFC 编译只占约 2%，其余时间花在 Nitro、Vite 和 Rollup 这些公共管道上。Vize 的编译速度再快，也改变不了整个构建的瓶颈。所以如果你的项目是 Nuxt，期望通过 Vize 获得显著的构建加速，很可能落空。Vize 的价值主要体现在独立的 SFC 编译、Lint 和格式化任务上，比如在 CI 里跑这些步骤，或者开发时的热更新。另一个限制是 Vize 的 drop-in 范围：它只替换 SFC 编译，如果你的项目用了自定义的 Vue 编译器选项，或者有特殊的 SFC 语法扩展，Vize 可能无法正确处理，因为 README 明确说这类配置不会被自动重写。

替代方案：留在官方工具链，还是等 Vize 成熟

如果你不打算冒险，最直接的替代方案是继续使用 @vue/compiler-sfc 加 vue-tsc 加 Prettier 的组合。这套工具链虽然慢，但每个环节都由 Vue 或 TypeScript 官方团队维护，行为可预测，社区支持成熟。另一个替代方案是 oxlint，它是 OXC 项目的一部分，用 Rust 写的 linter，Vize 的 Lint 功能实际上是通过 oxlint-plugin-vize 来集成的，所以你可以单独用 oxlint 而不引入 Vize 的其他部分。oxlint 的速度同样很快，而且它不绑定 Vue 的编译。如果你只需要更快的 Lint，oxlint 是比整个 Vize 更轻量的选择。Vize 的独特之处在于它把编译、Lint、格式化、类型检查统一到一个解析器上，这理论上能消除工具间的语义分歧，但代价是你要信任一个实验性项目对 Vue 语义的完整实现。

维护成本与许可证：MIT 下的实验性项目

Vize 的许可证是 MIT，这意味着你可以自由使用、修改和分发，但没有任何担保。README 没有提供详细的维护计划，但项目处于 Real World Testing 阶段，这意味着 API 可能会频繁变化。最近的发布记录显示 v0.387.0、v0.386.0、v0.385.0 在同一天内连续发布，这暗示迭代速度非常快，也意味着升级可能需要频繁适应 breaking changes。维护成本方面，你需要关注三件事：一是 vize init 生成的配置是否能在未来版本中继续工作；二是 vize check 的类型检查结果是否与 vue-tsc 保持一致，需要定期对比；三是 Vize 的编译输出是否与 Vue 官方编译器行为一致，特别是在你使用实验性 Vue 特性时。这些都需要额外的测试投入。

编辑结论

适合追求极致编译性能、愿意接受实验性工具且项目规模较大的 Vue 3 团队尝试。不适合对稳定性要求极高、依赖 vue-tsc 完整类型语义或需要自定义 Vue 编译器选项的项目。采用前必须验证：先跑 npx vize init --dry-run 查看改动计划，确认 SFC 编译结果与现有 @vitejs/plugin-vue 一致，并检查 vize check 对类型错误的捕获率是否满足你的要求。Vize 的 README 明确警告 breaking changes 和与 Vue 行为的偏差，所以任何迁移都应保留回退路径。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes