前言#

过去两年，前端工具链被系统级语言重新写了一轮：Rolldown 对齐 Rollup，Biome 替代 ESLint / Prettier 的一部分场景，tsgo 试图重写 TypeScript 编译器，Turbopack 也在重构 webpack 式的打包体验。

这些项目大多解决的是 构建期 问题：启动更快、热更新更快、打包更快、类型检查更快。

rari 往前多走了一步：它把加速点推到 运行期。HTTP server、路由匹配、RSC 渲染管线、Server Actions 调度这些框架基础设施由 Rust runtime 承担；JavaScript 仍然存在，但更像是被 V8 执行的业务模块，而不是承载整个 Web 框架的服务器运行时。

官方给出的 benchmark 很激进：

注：以上数据来自 rari 官方 README / benchmark，标注更新时间为 2026-05-15。它能说明框架固定开销的差异，但不能直接等价为真实业务页面的端到端性能提升。

先给结论：

• rari 优化的不是组件里的业务计算，而是 HTTP、路由、调度、RSC 流拼装这些每个请求都会经过的固定开销。
• 页面越轻、Server Component 占比越高，rari 的优势越容易体现；瓶颈如果在数据库、第三方 API 或客户端图表，收益会被摊薄。
• 迁移成本主要不在 React 写法，而在 Node API、Next.js 专有能力、部署和观测链路。

核心取舍：Rust 接管框架外壳#

rari 不是“用 Rust 写 React 组件”，也不是“让 JavaScript 计算突然变快”。

它更像是把 React 应用外围那层框架基础设施换成 Rust：

• 请求进来后由 Rust HTTP server 接住
• 路由匹配和请求上下文由 Rust runtime 管理
• Server Components 在嵌入式 V8 里执行
• RSC payload / HTML stream 由 Rust 侧组织和返回
• Server Actions 的入口、参数解析和调度也由 runtime 接管

rari 的核心判断是：

React 应用里有一部分工作其实不必由 Node.js 框架层来做。只要这些工作能被移到 Rust runtime，React 生态可以保留，框架固定开销也有机会下降。

这个判断很关键。它决定了 rari 和 Leptos / Dioxus 这类 Rust 前端框架不是同一种路线。

rari 选择的是“换底盘，不换驾驶方式”：你依旧写 React，但框架运行时尽量少让 Node.js 承担固定工作。

架构分层#

rari 把自己描述为 three layers, one framework。理解它时可以按三层看：底层负责运行时，中间层提供 React 语义，上层负责构建和开发体验。

┌─────────────────────────────────────────────┐
│  Layer 3: Build Toolchain                    │
│  Rolldown + Vite + tsgo                      │
├─────────────────────────────────────────────┤
│  Layer 2: React Framework                    │
│  App Router · Server Actions · Streaming     │
├─────────────────────────────────────────────┤
│  Layer 1: Rust Runtime                       │
│  HTTP Server · RSC Renderer · Router · V8    │
└─────────────────────────────────────────────┘

一条请求在 rari 里怎么跑#

从外部看，rari 应用还是 App Router 风格；从内部看，一次页面请求大致经过这条链路：

Browser
  │
  │ GET /dashboard
  ▼
Rust HTTP server
  │
  │ 路由匹配、请求上下文、RSC/SSR 调度
  ▼
Embedded V8
  │
  │ 执行 Server Component 模块
  │ 遇到 Client Component 时记录 client reference
  ▼
RSC renderer / SSR pipeline
  │
  │ 生成 HTML + RSC payload
  │ 通过 Suspense 边界逐步 flush
  ▼
Browser
  │
  │ 加载客户端 bundle，hydrate Client Component
  ▼
Interactive UI

这条链路里，最影响 bundle 和运行时收益的是 Server Component / Client Component 边界：

• Server Component 在服务端执行，结果通过 RSC payload 传给浏览器，本身不需要作为组件源码进入客户端 bundle
• Client Component 用 'use client' 标记，它以及它向下引入的交互代码会进入客户端依赖图
• Server Component 可以 import Client Component，但传入的 props 必须可序列化
• 函数、数据库连接、文件句柄这类服务端资源不能直接跨到客户端组件
• Suspense 边界决定哪些内容可以先返回，哪些内容等数据准备好后再补上

这套语义来自 React RSC。rari 做的是把语义背后的路由、渲染调度和流式响应拼装尽量放到 Rust runtime。

Server Action 的链路也类似：

form/action call
  │
  ▼
rari action endpoint
  │
  │ 解析 action 标识和 FormData
  ▼
Embedded V8
  │
  │ 调用 'use server' 函数
  ▼
serialize result
  │
  ▼
更新客户端状态 / 触发后续导航或刷新

它的价值是减少手写 API 层：mutation 逻辑仍然写成服务端函数，框架负责把表单提交、参数序列化、服务端调用和客户端状态更新接起来。

写起来是什么样#

先看最小项目：

# 1. 使用脚手架
pnpm create rari-app@latest my-rari-app

# 2. 启动开发服务器
cd my-rari-app
pnpm dev
# 默认运行在 http://localhost:5173

Server Component 默认在服务端执行：

// app/page.tsx
// 默认就是 Server Component
export default async function HomePage() {
  const posts = await fetch('https://api.example.com/posts').then((r) => r.json())

  return (
    <main>
      <h1>Hello rari</h1>
      <ul>
        {posts.map((post: { id: string; title: string }) => (
          <li key={post.id}>{post.title}</li>
        ))}
      </ul>
    </main>
  )
}

这里没有 getServerSideProps，也没有额外的 loader。数据请求直接写在服务端组件里，客户端只接收渲染结果和必要的交互代码。

需要交互时再显式声明 Client Component：

// app/components/Counter.tsx
'use client'

import { useState } from 'react'

export default function Counter() {
  const [count, setCount] = useState(0)

  return (
    <button onClick={() => setCount((value) => value + 1)}>
      clicked {count} times
    </button>
  )
}

'use client' 会切开依赖图：这个文件以及它向下 import 的交互逻辑都会进入客户端 bundle。因此它应该尽量靠近真正需要浏览器状态、事件或 DOM API 的地方。

Server Action 仍然按 React 语义写：

// app/actions/todo-actions.ts
'use server'

export async function addTodo(formData: FormData) {
  const title = formData.get('title') as string

  if (!title?.trim()) {
    return { success: false, error: 'title is required' }
  }

  await db.todo.create({ data: { title: title.trim() } })

  return { success: true }
}

// app/components/TodoForm.tsx
'use client'

import { useActionState } from 'react'
import { addTodo } from '@/actions/todo-actions'

export default function TodoForm() {
  const [state, formAction, isPending] = useActionState(
    async (_prevState, formData: FormData) => addTodo(formData),
    { success: false },
  )

  return (
    <form action={formAction}>
      <input name="title" />
      <button type="submit" disabled={isPending}>
        {isPending ? 'adding...' : 'add'}
      </button>
      {'error' in state && state.error ? <p>{state.error}</p> : null}
    </form>
  )
}

背后的流程是：

表单提交
  ↓
rari action endpoint 收到请求
  ↓
在 V8 中调用 addTodo
  ↓
序列化返回结果
  ↓
更新客户端状态或触发后续刷新

Server Action 可以访问数据库、环境变量和 server-only 能力。如果要调用 Node API 或 native addon，仍然需要按 rari 当前运行时兼容性逐项验证。

性能数据怎么看#

官方 benchmark 最大的价值，是展示框架固定开销的差异。它回答的是“runtime 本身能省多少”，不是“业务页面一定快多少”。

一个请求的总耗时可以粗略拆成：

T_total =
  T_http
+ T_route
+ T_framework_orchestration
+ T_react_render
+ T_data_fetch
+ T_serialize
+ T_network

rari 主要压低的是前几项：HTTP、路由、框架调度、RSC 流拼装。T_react_render 仍然发生在 V8 里；T_data_fetch 取决于数据库、缓存和外部 API；T_network 取决于部署位置和网络环境。

所以更实际的判断是：

• 页面越轻、框架固定开销占比越高，rari 的相对优势越容易体现
• 页面如果主要慢在数据库、第三方接口、图片处理或复杂业务计算，rari 只能减少框架层开销
• Client Component 占比越高，bundle 和 hydration 成本越难靠服务端 runtime 解决
• Node API / native addon 依赖越深，迁移验证成本越高

// 这个文件一旦标记 'use client'，
// 它下面 import 的交互逻辑也会进入客户端依赖图
'use client'

import HeavyChart from './HeavyChart'
import { formatMoney } from '@/lib/format'
import { getServerOnlyConfig } from '@/lib/server-config' // 应该避免

它适合什么场景#

判断 rari 是否值得试，核心不是“它是否比 Next.js 快”，而是你的项目瓶颈是否刚好落在它擅长优化的那一层。

迁移前应该检查什么#

如果只是体验新框架，create rari-app 就够了；如果要评估真实项目迁移，建议先做下面几项检查。

与同类方案对比#

rari 的差异点很清晰：在不放弃 React 生态的前提下，把 React 框架运行时尽量搬到 Rust。

值得关注的实现细节#

从仓库结构可以看出一些工程取向：

• crates/rari/：Rust 主体，Cargo workspace 管理
• packages/：发布到 npm 的客户端包和 Vite 插件
• examples/app-router-example/：官方示例应用
• playwright.config.ts + e2e 测试：近期版本持续补齐端到端测试
• rust-toolchain.toml + Cargo.lock：固定 Rust 工具链与依赖版本

这些细节说明 rari 不只是 proof of concept，而是在往可维护的应用型 Rust 项目方向推进。但从版本号和生态成熟度看，它仍然更适合先试点，再进入核心生产链路。

个人观察#

1. 系统级运行时正在进入前端框架内部。过去是打包器、linter、formatter 被 Rust / Go / Zig 重写，现在 rari 把 HTTP、路由和 RSC 管线也纳入系统级运行时的优化范围。
2. RSC 是适合“换底盘”的边界。Server Component、Client Component、Suspense、Server Action 天然把服务端执行、客户端交互和流式传输拆开，Rust runtime 有清晰的接管空间。
3. 业务团队应该关注的是固定成本下降，而不是宣传倍数。如果你的瓶颈在数据库、第三方 API 或客户端图表，rari 不会让页面直接快 72 倍；如果你的瓶颈在框架 runtime、冷启动或高并发尾延迟，它才更值得认真评估。

总结#

rari 的方向很明确：

• 下沉运行时：把 HTTP、路由、RSC 渲染和 Server Actions 调度从 Node.js 框架层下沉到 Rust
• 保留生态：继续使用 React、TypeScript 和 npm，而不是要求团队改写组件语言
• 更新工具链：用 Rolldown、Vite、tsgo 组成更偏底层实现的现代构建链路
• 仍然早期：截至 2026-05-21，最新 release 为 0.13.6，API 和运行时边界仍可能变化

如果你想体验 RSC 在低固定开销 runtime 上的表现，rari 很值得关注；如果要迁移成熟的 Next.js 生产体系，更稳妥的方式是先挑选性能敏感、依赖边界清晰的页面做试点，再用真实业务指标判断收益。

参考链接#

• 官网：https://rari.build/
• 仓库：https://github.com/rari-build/rari
• 文档：https://rari.build/docs
• Benchmarks：https://github.com/rari-build/benchmarks