跨平台不是"能不能跑"，而是"用哪条技术路线换哪种确定性"。

选错框架的代价：某团队用 Electron 做笔记应用，上线后用户反馈"启动 5 秒，内存 500MB"。重构用了 3 个月。如果一开始选 Tauri 或 Wails，这个坑完全可以避免。

一、先搞懂底层逻辑：UI 是怎么画到屏幕上的

不同的"画法"决定了框架的基因，也决定了它擅长什么、不擅长什么。

1.1 四种技术路线

路线一：自绘渲染（Self-rendering）

框架自己实现渲染引擎，拿到系统给的"画布"，一笔一画把 UI 画出来。

类比：买一块空白画布，用自己的颜料和画笔画画。风格完全由你决定，跟画布品牌没关系。

┌─────────────────────────────────────┐
│ 你的应用代码                         │
├─────────────────────────────────────┤
│ 框架的渲染引擎                       │ ← 这一层是框架自己实现的
├─────────────────────────────────────┤
│ 系统图形 API (Metal/Vulkan/GL)      │
├─────────────────────────────────────┤
│ GPU                                 │
└─────────────────────────────────────┘

代表：Flutter、Qt Quick、GPUI、Dioxus（Blitz 模式）、Slint

路线二：原生控件映射（Native Bridging）

框架把你写的代码"翻译"成原生控件调用。你写 <Button>，框架帮你调用 iOS 的 UIButton 或 Android 的 MaterialButton。

类比：你是导演，给演员（原生控件）下指令。iOS 演员演得像 iOS，Android 演员演得像 Android。

┌─────────────────────────────────────┐
│ 你的应用代码                         │
├─────────────────────────────────────┤
│ 框架的桥接层 (Bridge)               │ ← 翻译 + 通信
├─────────────────────────────────────┤
│ 原生控件 (UIKit / Android Views)    │
├─────────────────────────────────────┤
│ 系统                                │
└─────────────────────────────────────┘

代表：React Native、.NET MAUI、Uno Platform、NativeScript、Lynx、Valdi

路线三：WebView / Chromium 方案

用 Web 技术栈写 UI，通过 WebView 或内嵌 Chromium 渲染。

类比：在应用里开了一个"浏览器窗口"，你的 UI 实际上是一个网页。

┌─────────────────────────────────────┐
│ 你的 Web 应用 (HTML/CSS/JS)         │
├─────────────────────────────────────┤
│ WebView / Chromium / 系统浏览器     │
├────────────────┬────────────────────┤
│ 后端进程        │ 系统 API 调用      │
│ (Node/Rust/Go) │                    │
└────────────────┴────────────────────┘

代表：Electron、Tauri、Wails、Electrobun

路线四：逻辑共享优先（Shared Logic First）

只共享业务逻辑和数据层，UI 各平台自己写。

类比：后厨（业务逻辑）是统一的，但前台装修（UI）各店不同。

┌──────────────────────────────────────────────────┐
│ 共享层 (Kotlin)                                   │
│ 网络、数据库、业务逻辑、状态管理                    │
├─────────────────┬────────────────┬───────────────┤
│ Android UI      │ iOS UI         │ Desktop UI    │
│ (Compose)       │ (SwiftUI)      │ (Compose)     │
└─────────────────┴────────────────┴───────────────┘

代表：Kotlin Multiplatform (KMP)

1.2 路线选择决策树

你的核心诉求是什么？
│
┌─────────────────┼─────────────────┐
▼                 ▼                 ▼
跨端一致性        原生体验           开发效率
视觉完全统一      系统深度集成       快速上线
│                 │                 │
▼                 ▼                 ▼
自绘渲染          原生映射           WebView 方案
Flutter/          RN/MAUI/Uno/      Electron/Tauri/
Slint/Qt/GPUI    NativeScript/KMP  Wails/Dioxus

二、按语言生态分组：你团队写什么，就选什么赛道

选框架的第一刀不是"哪个框架好"，而是"你团队用什么语言"。语言决定了你能高效使用的框架范围，也决定了学习曲线的起点。

2.1 JavaScript / TypeScript 赛道

这是最大的赛道——前端开发者天然能进入的框架最多，但细分方向差异极大。

三组关键对决：

① React Native vs NativeScript：React 还是 Vue？

一句话：React 团队无脑选 RN；Vue/Angular 团队选 NativeScript。

② Electron vs Tauri vs Wails：桌面应用怎么选？

一句话：不碰 Rust/Go → Electron；愿意学 Rust → Tauri；Go 团队 → Wails。

③ Lynx：RN 的挑战者？

字节跳动 2025 年开源，双线程架构（UI 线程 + JS 线程），原生映射与自绘混合渲染。对 RN 桥接性能不满意的团队可以关注，但目前生态尚早。

2.2 Dart 赛道

Flutter——Dart 几乎只有一个选择，但这个选择足够强。

Flutter 的核心优势：跨端一致性——因为渲染引擎自己画，不依赖系统控件，同一份代码在所有平台视觉完全统一。

Flutter 的核心代价：与系统"格格不入"——iOS 的橡皮筋效果、Android 的 Material You 动态取色、系统级无障碍，都需要额外适配。

真实案例：Google Pay（全球支付应用，Flutter 重写后开发效率提升 70%）、阿里闲鱼（首页 Flutter 实现）、BMW 车载信息娱乐系统

常见坑：热重载偶尔失效需热重启；--split-debug-info + --obfuscate 可减包体 ~30%；iOS 审核需确保 Info.plist 权限说明清晰

2.3 C# 赛道

两个框架，一个微软官方、一个社区先行者，核心区别在于 WebAssembly 支持。

一句话：不需要 WASM → MAUI；需要 WASM 或更广平台 → Uno。

2.4 C++ 赛道

Qt——30 年历史的工业级方案，嵌入式和桌面的"老大哥"。

真实案例：特斯拉 Model S/X 早期车载系统、达芬奇手术机器人控制界面、Autodesk Maya 部分 UI、VirtualBox 管理界面

适合：工业软件、医疗设备、汽车 HMI、嵌入式系统——这些领域对稳定性和确定性要求远高于开发效率

不适合：快速原型验证、小团队短周期项目、纯移动端消费级应用

2.5 Kotlin 赛道

Kotlin Multiplatform (KMP)——不共享 UI，只共享逻辑，"最小侵入"的跨平台方案。

核心价值：渐进式迁移——你可以从 Android 项目开始，一点点把逻辑抽到共享层，iOS 端仍然写原生 SwiftUI。不像其他框架要求"全有或全无"。

真实案例：Netflix（部分共享逻辑）、VMware（企业应用）、 Philips（医疗设备软件）

不适合：需要 UI 也跨平台共享的团队（虽然 Compose Multiplatform 在补这块短板，但 iOS 端仍是 Alpha）

2.6 Rust 赛道

Rust 赛道是最热闹的新战场——三个框架各切一个角度。

三者怎么选：

• 前端团队 + Rust 后端 → Tauri（前端照写 HTML/CSS/JS，Rust 只管后端）
• 想用 Rust 统一前后端 → Dioxus（类 React 组件+Hooks 语法，一套 Rust 跑全平台）
• 追求极致渲染性能 → GPUI（GPU 直绘，但 macOS 优先，Linux 实验性，生态极小）

2.7 Go 赛道

Wails——Go 团队做桌面应用的唯一主流选择。Go 后端 + 前端 UI + 系统 WebView，定位就是"Go 版 Tauri"。

与 Tauri 的取舍：Rust 更安全更极致，Go 更简单更易上手。后端逻辑重的应用（数据库工具、网络代理、CLI 包装器）天然适合 Go。

2.8 嵌入式专用赛道

Slint——极小包体 + 低资源消耗的嵌入式 UI 方案。

与 Qt 的取舍：Qt 生态大但重，Slint 极轻但组件少。MCU 和资源受限的嵌入式场景选 Slint；需要完整组件库和工具链的工业场景选 Qt。

三、真实案例图谱

案例比参数更能说明"谁在用、用来做什么、效果如何"。

3.1 移动端案例

3.2 桌面端案例

3.3 工业 / 嵌入式案例

3.4 案例启示

• Flutter 在品牌型应用和车载系统中反复出现——视觉一致性是它的杀手锏
• Electron 的成功案例证明了"Web 技术也能做出专业应用"，但代价是内存——VS Code 吃 800MB 也被接受，但你的应用未必有这个底气
• Tauri 正在从开发者工具切入（DBX 等数据库管理工具），轻量是它的入场券
• KMP 的典型案例不是"全应用跨平台"，而是"关键逻辑共享"——更务实的中间路线
• Qt 的案例几乎都在工业和医疗——这些领域不需要时髦，需要稳定运行 10 年

四、核心指标矩阵

4.1 包体与资源

4.2 平台覆盖

4.3 学习曲线与生态

五、快速决策表

六、选型的底层逻辑

6.1 没有银弹，只有取舍

你不可能同时获得：
  跨端一致性 + 原生体验 + 小包体 + 低学习成本

自绘渲染  → 一致性 ↑，原生体验 ↓
原生映射  → 原生体验 ↑，一致性 ↓
WebView   → 开发效率 ↑，性能 ↓
逻辑共享  → 原生体验 ↑，UI 开发量 ↑

6.2 选型的三个维度

1. 团队语言：选团队最熟的语言，学习曲线比框架差异更致命
2. 目标平台：移动优先 vs 桌面优先 vs 全平台，直接砍掉一半选项
3. 核心约束：包体敏感？启动速度？原生体验？一致性？——最不能妥协的那条决定路线

6.3 新框架的"值得试水"阈值

总结

跨平台框架的选择本质上是在回答一个问题：你愿意用哪种确定性，换哪种不确定性？

• 选 Flutter：确定性是跨端一致性，不确定性是 Dart 生态和系统深度集成
• 选 React Native：确定性是 React 生态和原生体验，不确定性是桥接性能和新架构迁移
• 选 Tauri：确定性是轻量和安全，不确定性是 Rust 学习曲线和 WebView 兼容
• 选 Electron：确定性是前端生态和开发效率，不确定性是资源占用和用户体验
• 选 KMP：确定性是原生体验和渐进迁移，不确定性是 UI 写多份的维护成本
• 选 Qt：确定性是工业级稳定性，不确定性是学习曲线和许可证成本

没有最好的框架，只有最适合你当前约束的框架。

先想清楚你最不能妥协的那一条，再按决策树往下走。技术路线定了，框架的选择往往水到渠成。