前言
上一篇我聊的是：为什么我开始认真看 Makepad。
这一篇接着回答一个更实际的问题：
如果 Tauri、egui、Dioxus、Makepad 都摆在你面前，到底该怎么选？
先把结论放前面，免得大家看半天还不知道我要说啥：
- 想尽快把桌面应用做出来，先看
Tauri - 想全程写 Rust，而且先把工具界面做出来，先看
egui - 喜欢 React 那套组件思维，但又不想回去写 JS/TS，可以看
Dioxus - 想认真看看 Rust 原生 UI 这条路能不能走远，继续看
Makepad
所以这篇不是排名文。
我也不打算搞什么"2026 Rust GUI 终极推荐"。
因为说到底，这几个项目解决的就不是同一个问题。你要是把它们当成同一赛道来比，很容易越比越拧巴。
1. 先别急着选，先把它们当成 4 条不同路线
很多文章喜欢把这几个框架塞进一张表里，然后开始从性能、语法、生态、未来前景一路横评。
看着很全，真到自己做项目时还是懵。
我现在更愿意这么看：
| 方案 | 它更像什么 | UI 主要写在哪 | 我会先想到的场景 |
|---|---|---|---|
Tauri |
WebView 客户端框架 | 前端 | 快速交付桌面应用 |
egui |
Rust immediate mode GUI | Rust | 工具、面板、配置器 |
Dioxus |
Rust 版组件式前端 | Rust 组件 + Web 心智 | 想用 Rust 写跨平台组件 UI |
Makepad |
Rust-first UI runtime | Rust | 想看更原生的 Rust UI 路线 |
你先接受这个前提，后面基本就好聊了。
因为这 4 个东西看起来都在做 GUI，但发力点完全不一样。
有的是在解决"怎么更快交付"，有的是在解决"怎么写起来更顺"，有的是在解决"Rust 能不能把 UI 也接过来"。
这不是细节差异，这是路线差异。
2. Tauri：最现实，也最省事
如果你问我：现在要做一个桌面客户端，哪条路最容易落地？
我大概率还是先回答 Tauri。
原因不复杂，它真的很现实。
Tauri 官方的定位一直很清楚：前端你继续用 HTML / CSS / JS 那套，后端能力交给 Rust，界面跑在系统 WebView 上。桌面端底层这块目前主要是 WRY 在做统一封装。
官方资料：
这条路为什么香，其实不用讲太深，大家都懂：
- 前端同学能马上接进来
- 已有 Web 项目迁移成本低
- UI 生态、调试工具、样式体系都是现成的
- Rust 刚好负责它擅长的系统能力、本地能力、性能部分
一个很典型的 Tauri 味道，大概就是这样：
rust
#[tauri::command]
fn greet(name: &str) -> String {
format!("Hello, {name}!")
}前端继续写页面，Rust 暴露命令，大家分工明确，工程上很顺。
2.1 什么场景下，我会优先考虑 Tauri
比如这些：
- 有现成前端团队
- 本来就是页面型应用
- 想快速出一个能发布的桌面客户端
- 想少踩坑，少重新学习一套 UI 编程方式
说白了，如果你的目标是：
别折腾，先把东西做出来。
那 Tauri 真的很难绕开。
2.2 但 Tauri 也有很明确的边界
它的问题不是"不够强"，而是它的 UI 主场始终还是 Web。
这件事对很多项目完全没问题。
但如果你开始在意这些事：
- 不想长期维护两套状态心智
- 不想界面层一直依赖前端技术栈
- 想把 UI、状态、逻辑尽量统一在 Rust 里
- 对动画、绘制、交互手感有更高要求
那 Tauri 就不一定还是最对味的。
所以我对它的评价一直都挺稳定：
它是现在最好落地的 Rust 客户端方案之一，但它并不是"Rust 原生 UI"这条路。
3. egui：写起来真的顺，尤其是做工具的时候
如果说 Tauri 是最现实的路线，那 egui 就是最容易让 Rust 开发者觉得"这玩意儿我能直接上手"的路线。
egui 官方对自己的描述也很直接：easy-to-use、simple、fast、highly portable，而且明确是 immediate mode GUI。
官方资料：
它最经典的味道就是这种：
rust
if ui.button("保存").clicked() {
self.save();
}这句代码基本已经把它的性格写脸上了。
3.1 egui 为什么让人觉得省脑子
因为 immediate mode 这套东西，写起来就是顺。
你不用老想着：
- 组件先怎么挂
- 事件怎么绕
- 状态又要从哪儿传回来
很多时候就是"我现在要画个什么，我现在要处理什么交互"，直接往下写。
比如一个很普通的小面板：
rust
ui.horizontal(|ui| {
ui.label("用户名");
ui.text_edit_singleline(&mut self.name);
});
if ui.button("保存设置").clicked() {
self.save();
}这种代码看着就没什么心理负担。
尤其是下面这些东西，egui 往往非常合适：
- 调试面板
- 配置工具
- 数据查看器
- 内部小工具
- 一些轻量可视化界面
3.2 但它不一定适合所有"产品型 UI"
这个得说清楚。
很多人第一次用 egui 会觉得太爽了，然后开始脑补"那我是不是以后所有桌面 UI 都能这么写"。
也不是不行，但未必舒服。
因为它最强的地方，本来就不是"把大型产品界面组织得特别优雅"，而是：
让你很快把一个能交互、能工作的界面写出来。
如果你更在意的是：
- 复杂页面层级
- 长期组件化
- 更重的视觉表达
- 更像产品而不是工具的界面结构
那 egui 可能就不是第一选择了。
所以我会这么总结：
做工具、做面板、做效率型 GUI，egui 很香。
但如果你期待它完全替代别的 UI 路线，最好先别上头。
4. Dioxus：很像前端，但主语言变成了 Rust
Dioxus 这条路很有意思。
如果你本来就熟 React、Solid、Vue 这类组件式写法，第一次看 Dioxus，大概率会有一种熟悉感。
因为它确实很像那一路思维。
从官方仓库和文档看，Dioxus 把自己定位成 web、desktop、mobile 都能覆盖的跨平台应用框架，核心写法是 rsx!。
官方资料：
比如这种：
rust
fn App() -> Element {
rsx! {
button {
onclick: move |_| println!("clicked"),
"Click me"
}
}
}看这个语法，前端味儿已经很重了。
4.1 Dioxus 适合哪类人
我觉得它特别适合下面这类开发者：
- 喜欢组件化思维
- 不想回去写 JS / TS
- 想让主语言统一成 Rust
- 希望一套思路能同时覆盖 web、desktop、mobile
它吸引人的点，不是"原生"，而是"熟悉"。
你可以把它理解成：
Rust 世界里的一套组件式前端体验。
4.2 它和 Tauri 有点像，但又不是一回事
这俩经常被一起提，因为都能做跨平台客户端，也都和 Web 那套思维有关系。
但我自己的感受是：
Tauri更像"前端照旧，Rust 来补系统能力"Dioxus更像"我想保留组件式开发体验，但把主语言换成 Rust"
官方文档里对桌面端的描述也能看出这个味道，它并不是彻底和 Web 心智切开，而是在 Rust 里重建一套组件体验。
所以如果你问我 Dioxus 最像谁，我不会说它像 egui，我会说：
它更像 Rust 版前端框架。
这不是贬义，反而是它最清晰的定位。
5. Makepad：它最吸引我的，不是"能不能用"，而是"它想把事情做到哪一步"
终于说到 Makepad。
我前一篇已经聊过，为什么我会开始认真看它。这篇就不重复铺垫了，直接讲结论：
Makepad 真正让我在意的，不是它今天有多成熟，而是它想走的方向很不一样。
从官方仓库和文档看，Makepad 想做的是 Rust-first 的 UI runtime，有自己的 UI DSL、live_design! 体系，也很强调渲染能力和 live 编辑这类东西。
官方资料：
它给我的感觉不是"又一个 GUI 库"，而是：
它在认真尝试一件更大的事：Rust 能不能自己长出一套像样的现代 UI 体系。
5.1 为什么我会把 Makepad 单独拎出来看
因为它和前面 3 个项目关注点不一样。
Tauri 更关注交付效率。
egui 更关注上手速度和交互效率。
Dioxus 更关注组件式跨平台体验。
而 Makepad 更像是在问：
如果我不想回到 WebView，也不想停在 immediate mode，那 Rust 自己能不能把 UI 这件事接住？
这就是它最有意思的地方。
5.2 但你现在也别把它想得太完美
这个冷水还是得泼。
如果你今天立刻要做商业项目，而且你很在意这些：
- 文档够不够密
- 社区案例够不够多
- 团队成员能不能快速接手
- 搜问题的时候能不能立刻搜到答案
那 Makepad 现在大概率不是最省心的选项。
它更像一条值得持续跟进、值得研究、值得押注的路线。
这和"默认最优解"是两回事。
所以我自己的态度一直是：
我会认真关注 Makepad，但我不会假装它现在已经适合所有项目。
6. 如果你现在就要选，我会直接这样给建议
不拐弯，直接上结论。
6.1 想快点做完，选 Tauri
尤其是：
- 你有前端经验
- 你要快速交付
- 你不想重学一套 UI 开发思路
6.2 想全程写 Rust，小工具先干起来，选 egui
尤其是：
- 面板
- 配置器
- 调试工具
- 内部系统辅助界面
6.3 想保留组件化思维，但不想写 JS/TS，选 Dioxus
尤其是：
- 你本来就习惯 React 这类思路
- 你想让 UI 主语言变成 Rust
- 你想一套组件逻辑跑多个平台
6.4 想看 Rust 原生 UI 更长线的可能性，选 Makepad
尤其是：
- 你不满足于 WebView 路线
- 你对 UI runtime 这件事本身有兴趣
- 你愿意接受前期摸索成本
总结
最后就一句话。
别再问"Rust GUI 谁最强"了，这个问法本身就有点跑偏。
更靠谱的问法应该是：
你现在最想解决的问题，到底是交付、效率、组件化，还是原生 UI 路线。
如果按这个思路看：
Tauri像最稳的工程解egui像最顺手的工具解Dioxus像最像前端的 Rust 解Makepad像最值得继续观察的原生解
这篇先把选型框架搭起来。
下一篇我会直接开跑 Makepad 项目，看看它到底是"概念很酷"，还是"真能干活"。
如果你已经实际用过这几个方案，欢迎把你的项目场景和真实体验写在评论区。