6MB、100ms 首帧、不带浏览器：Vercel Labs Native SDK 的路线和限制

做桌面应用，前端能选的方案就那几条。

Electron 开发效率最高，生态也最成熟。代价是每个应用都背一套 Chromium + Node.js，安装包上百 MB 很常见，内存和启动速度很难压下来。

Tauri 不捆绑 Chromium 了，改用系统 WebView。包体小很多，但本质上还是：

HTML + CSS + JavaScript
↓
系统 WebView
↓
Rust 原生能力

WebView 仍然是渲染层，Windows、macOS、Linux 各用各的实现，平台差异绕不开。

Vercel Labs 给出了第三条路线：Native SDK。不装浏览器，不依赖 WebView，也不用 JavaScript 引擎。界面用类前端模板的 .native 语法写，业务逻辑用 Zig，渲染由自研引擎直接把像素画进系统窗口。

官方公布的数据：

完整应用：小于 6 MB
启动到首帧：约 100 ms
内置浏览器：0
JavaScript 引擎：0
运行时解释器：0

先给结论：方向有意思，但项目还在 pre-1.0，生态和平台支持都有限。下面拆开说。

Electron 为什么越来越重

Electron 的架构很简单：

前端页面
↓
Chromium
↓
Node.js
↓
Windows / macOS / Linux

VS Code、Discord、Slack 都这么跑。前端栈随便选，浏览器里能跑的东西基本都能搬进桌面应用。

问题也出在这套架构上。每启动一个应用，就要把完整的 Chromium 和 Node.js 拉起来。你只写个 Markdown 编辑器、文件工具或者状态栏小工具，也得背着整套浏览器。包体、内存、启动时间，全耗在这上面。

Electron 最大的优势是浏览器，最大的负担也是浏览器。

Tauri 轻了，但没离开 WebView

Tauri 的结构是：

Vue / React / Svelte
↓
HTML + CSS + JavaScript
↓
系统 WebView
↓
Rust

包体比 Electron 小很多，后端能力交给 Rust。只要项目最终能编译成 HTML、CSS、JavaScript，基本都能塞进 Tauri。

但 Tauri 没解决渲染层的问题。Windows 用 WebView2，底层是 Edge Chromium；macOS 用 WKWebView；Linux 用 WebKitGTK。各平台的浏览器版本、渲染结果、能力支持仍然可能存在差异。

Tauri 解决的是「捆绑完整浏览器太重」，没解决「渲染层还是浏览器」。

Native SDK：界面直接编译进可执行文件

Native SDK 默认两个文件：

src/app.native
src/main.zig

.native 写界面：

-

{count}
+

count: {count}

有组件、有属性、有事件、有数据绑定，写法接近 HTML 加现代框架的模板语法。但构建时 .native 直接编译进可执行文件，不生成 DOM，不交给浏览器。布局、绘制、事件处理全由 SDK 自己的引擎完成。

发布产物不携带：

• 浏览器
• WebView
• 模板解析器
• 脚本解释器
• JavaScript 引擎

业务逻辑写在 Zig 里：

pub const Msg = union(enum) {
increment,
decrement,
reset,
};

pub const Model = struct {
count: i64 = 0,
};

pub fn update(model: *Model, msg: Msg) void {
switch (msg) {
.increment => model.count += 1,
.decrement => model.count -= 1,
.reset => model.count = 0,
}
}

状态流转是单向的：

用户操作
↓
发送 Msg
↓
update 修改 Model
↓
重新计算界面

界面只能读状态、发消息，所有状态变化集中在 update。写过 Redux、Elm、Pinia 的不用重新学。

数据是官方的，先别急着下结论

官方列出的示例应用二进制大小：

Calculator：3.6 MB
Markdown Viewer：3.5 MB
Notes：3.5 MB
Soundboard：5.7 MB
System Monitor：3.7 MB

macOS ARM64 下，从进程启动到第一帧显示的温启动时间约 71–131 ms。一个完整的 Markdown 编辑器示例，二进制 3.4 MB。

体积为什么小：

没有 Chromium
没有 Node.js
没有系统 WebView
没有 JavaScript 引擎
没有运行时模板解释器

发布产物的构成：

你的业务逻辑
+ Native SDK 渲染引擎
+ 系统原生框架

注意，这些数据来自项目方在指定设备和示例应用上的测试，不能直接推成「比 Electron 快几十倍」。两者提供的运行环境、浏览器能力和生态规模不在一个量级。

对文件工具、桌面客户端、效率工具、Markdown 编辑器、数据库管理器、系统监控、内部工作台这类应用，这个体积和启动速度确实很有吸引力。但如果你的应用重度依赖 Web 生态、需要现成的组件库或复杂排版能力，Native SDK 现在还接不住。

三套方案怎么选

Electron 适合复杂 Web 产品迁移、重度依赖浏览器生态的应用。对包体和内存占用有硬性要求时，别选 Electron。

Tauri 适合还想用 Vue、React，同时想减小包体和资源占用的团队。需要跨平台渲染表现完全一致的场景，Tauri 的 WebView 差异会成为问题。

Native SDK 的目标很明确：

保留声明式 UI
保留组件化开发
保留数据绑定
保留热更新
保留前端熟悉的开发体验
然后，删掉浏览器。

不用回去写 AppKit、Win32 或 GTK，也不把界面塞进 WebView，中间重新造了一层。代价是 API 还没稳定、社区规模小、Zig 要学。

上手和工具链

安装：

npm install -g @native-sdk/cli

创建项目：

native init my_app
cd my_app
native dev

执行完会打开一个真实系统窗口。

默认目录结构：

src/app.native   # 界面、布局、绑定、事件
src/main.zig     # 状态和业务逻辑
src/tests.zig    # UI 测试
app.zon          # 应用配置、权限、窗口、打包信息
assets/icon.png  # 应用图标

开发时改 src/app.native，窗口自动更新，尽量保留当前状态。写错了旧界面不会直接崩，会返回具体的文件、行号和列号。

检查、测试、构建、打包：

native check
native test
native build
native package --target macos
native package --target windows
native package --target linux

CLI 会处理 SDK 路径和匹配版本的 Zig 工具链，不需要自己维护 build.zig。真要自定义构建时，再通过 native eject 接管完整构建文件。

整体流程前端开发者不陌生：

安装 CLI
↓
初始化项目
↓
启动开发服务器
↓
修改界面
↓
自动更新
↓
构建打包

只是这次跑起来的不是网页。

平台支持现状

覆盖五个平台：macOS、Windows、Linux、iOS、Android。

macOS 是目前支持最完整的平台，用 Metal 渲染，接入系统滚动、菜单、托盘、弹窗和输入法。

Windows 和 Linux 可以运行、测试、打包完整应用，但主要走 CPU 软件渲染，GPU 渲染后端还在完善。Linux 暂时没有系统托盘，Windows 和 Linux 的部分系统能力也不如 macOS 完整。

移动端构建链路已经打通：

native dev --target ios
native dev --target android
native package --target ios
native package --target android

iOS 生成完整 Xcode 工程，Android 生成完整宿主工程和调试 APK。不用额外维护 Swift、Kotlin 或 Java 宿主代码。

但 iOS 和 Android 目前是实验性支持，主要在模拟器里验证，工具链、API、GPU 渲染和真机工作流都还在完善。拿它替换成熟的 Flutter 或 React Native，现在太早。桌面端已经值得一试，移动端再等等。

给 AI Agent 留的口子

运行时内置了自动化能力。Agent 可以读取正在运行的应用界面，查看无障碍树，查找按钮，输入文本，点击组件，验证状态，录制操作，生成确定性截图。

native automate wait
native automate snapshot
native automate screenshot

官方还提供 Agent Skills：

npx skills add vercel-labs/native

装完之后，Claude Code、Codex 这类 Agent 能拿到匹配当前 SDK 版本的开发说明。Agent 写完界面，启动应用、操作窗口、验证结果，再回头改代码。

流程是这样的：

AI 生成界面
↓
编译运行
↓
读取真实窗口
↓
点击和测试
↓
发现问题
↓
自动修改

以前的 AI 写桌面应用，只能保证代码「看起来能跑」。Native SDK 这条路让 Agent 能看到自己做出来的应用。组件自带来源信息，可以定位某个按钮来自哪个 .native 文件、哪一行，然后自动完成修改。

现在的状态

项目还在 pre-1.0，API 会继续变，生态和 Electron、Tauri 不在一个量级。Windows、Linux、移动端的渲染能力还要补。

但方向值得保持关注：一个不到 6 MB、约 100 ms 启动、覆盖五个平台、还能让 AI Agent 直接操作和测试的原生应用框架。

官网：https://native-sdk.dev/