跨平台框架比较¶
更新：2026 年 9 月。本文讨论应用开发框架，比较 Android、iOS、Windows、macOS、Linux、浏览器与小程序；具体系统版本与插件支持以官方文档为准。
“一套代码多端运行”可以指共享业务逻辑、共享界面、将 Web 页面放进应用容器，或把页面编译到不同的小程序平台。这些方式的开发成本、平台体验和维护边界不同。选型前，先确定必须交付的平台，再确认哪些代码确实需要共享。
主要方案一览¶
| 方案 | 主要语言与界面方式 | 主要交付平台 | 适合的起点 | 需要留意 |
|---|---|---|---|---|
| Flutter | Dart；框架自行绘制大部分界面 | Android、iOS、Windows、macOS、Linux、Web | 新项目要在多端保持统一界面 | Web 端的渲染方式不同于传统 DOM 网站；原生能力仍要检查插件或自行接入 |
| React Native | JavaScript / TypeScript；使用平台原生视图 | Android、iOS 为核心；Web、Windows、macOS 依赖其他项目 | React 团队开发移动应用 | 扩展平台的维护与库兼容性需单独核对 |
| Kotlin Multiplatform | Kotlin；可只共享逻辑，也可配合 Compose Multiplatform 共享界面 | Android、iOS、桌面、Web，取决于所选目标和 UI 方案 | 已有原生应用，想逐步复用逻辑 | 共享层越大，跨平台依赖与平台差异处理越多 |
| .NET MAUI | C# / XAML；映射到平台控件 | Android、iOS、Windows、macOS（Mac Catalyst） | .NET 团队开发移动和桌面应用 | Linux 和浏览器不是其官方标准应用目标 |
| Electron | HTML / CSS / JavaScript；内置 Chromium 与 Node.js | Windows、macOS、Linux | 已有 Web 团队，需要成熟的桌面应用方案 | 每个应用附带浏览器运行时，须测量包体和内存 |
| Tauri 2 | Web 前端；系统 WebView 与 Rust 核心 | Windows、macOS、Linux；也可面向 Android、iOS | Web 团队重视桌面包体，愿意处理 Rust 与系统集成 | 不同系统的 WebView 需分别测试；移动端能力与插件需逐项验证 |
| Capacitor | HTML / CSS / JavaScript；移动端 WebView 与原生插件 | Android、iOS，并可复用 Web 应用 | 已有网站或 Web 应用要进入应用商店 | 对复杂原生交互、动画或设备 API，要验证插件和实际体验 |
| uni-app | Vue / JavaScript；按目标平台编译，App 常规 .vue 页面由 WebView 渲染 |
各类小程序、Web、Android、iOS；其他目标以文档为准 | Vue 团队以小程序为重点，同时交付 H5 与 App | 普通 Web 的 DOM 库未必能用于小程序；App 页面渲染方式与 uni-app x 有区别 |
| Taro | React / Vue 等；面向不同小程序和 H5 转换 | 各类小程序、H5；可通过 React Native 路径开发 Android / iOS App | React 团队以多种小程序为重点 | App 端需额外适配 React Native；组件与 API 的多端支持需逐项核对 |
表中“主要交付平台”描述的是官方文档中的常见目标，并不表示同一套界面、插件与发布流程在所有平台完全一致。例如 React Native 的 Web 和桌面支持属于独立维护的扩展平台；Kotlin Multiplatform 的共享界面是可选方案，Compose Multiplatform 的 Web 目标截至本文更新时仍标为 Beta。参见 React Native 扩展平台和 Kotlin Multiplatform 官方说明。
uni-app 与 Taro 的位置：两者更强调小程序与 H5 的多端交付。uni-app 采用 Vue 风格页面和统一 API，常规 App .vue 页面通常经 WebView 渲染；uni-app x 是另一个技术路线，提供原生渲染，不能把两者的性能与兼容性混作一项。Taro 可使用 React 或 Vue 开发小程序与 H5；其 Android / iOS App 路径基于 React Native，需要相应的工程配置和平台适配。两者都应按目标小程序逐项检查组件与 API 支持。
核心差异¶
共享到哪一层¶
- 共享业务逻辑：Kotlin Multiplatform 可以从网络、数据模型或规则模块开始，Android 与 iOS 继续使用各自的界面。适合已有原生代码、重视平台设计规范的团队。
- 共享界面与逻辑：Flutter、React Native、.NET MAUI，以及配合 Compose Multiplatform 的 Kotlin Multiplatform，能共享较多应用代码；但权限、推送、支付、后台任务等仍可能需要平台代码。
- 复用 Web 界面：Capacitor 面向移动端，Electron 面向桌面端，Tauri 兼顾桌面与移动端。已有 Web 应用通常更容易迁移，但浏览器环境与原生控件的行为需要实测。
- 交付小程序与 H5：uni-app 和 Taro 为不同小程序提供编译与运行时适配，也能输出 Web 页面。共享的是符合框架约束的页面与逻辑，并非任意现成网站都能直接编译成小程序。
界面如何呈现¶
Flutter 主要由自己的渲染引擎绘制控件，利于跨端统一视觉；React Native 和 .NET MAUI 使用平台视图或控件；Electron 自带 Chromium，Tauri 使用操作系统提供的 WebView，Capacitor 在移动应用中承载 Web 内容。Kotlin Multiplatform 的呈现方式由界面选择决定：可以保留 SwiftUI / UIKit 等原生界面，也可以使用 Compose Multiplatform。参见 Flutter 架构、React Native 原生组件、Tauri 进程模型和 Capacitor 文档。
这些差异不能直接换算成“性能排名”。启动时间、滚动流畅度、安装包、空闲内存和电池消耗取决于业务代码、依赖、设备及构建配置。应以同一功能、同一设备和正式构建做对比。
按场景选型¶
| 你的主要需求 | 优先验证 | 选择理由 |
|---|---|---|
| 从零开发 Android 与 iOS，要求统一、可定制的视觉 | Flutter | UI 与逻辑可集中开发；先验证关键原生插件 |
| React 团队开发移动应用 | React Native | 能沿用 React 知识和 JavaScript / TypeScript 工具链 |
| 已有 Android / iOS 原生应用，先减少业务逻辑重复 | Kotlin Multiplatform | 可逐模块接入，同时保留原有界面 |
| .NET 团队同时交付移动与 Windows / macOS 应用 | .NET MAUI | 沿用 C# 与现有 .NET 工程经验 |
| 现有 Web 应用需要 Windows / macOS / Linux 客户端 | Electron 或 Tauri | 前者集成 Chromium，环境较一致；后者使用系统 WebView，需验证系统差异 |
| 现有 Web 应用需要 Android / iOS 安装包 | Capacitor | 复用页面与 Web 工具链，再以插件接入设备能力 |
| Vue 团队要同时交付微信等小程序、H5 和 App | uni-app；如需原生渲染再评估 uni-app x | 小程序与 App 都在其目标范围，先核对实际所需 API 与页面渲染模式 |
| React 团队要交付多个小程序和 H5 | Taro | 保留 React 开发方式；若还要 App，单独验证 React Native 端 |
| 同时需要网站与应用商店客户端 | 分别验证 Web 体验和应用体验 | “可运行在 Web”不等于适合搜索、无障碍或内容型网站；也不保证移动端手势与导航自然 |
做决定前的验证清单¶
- 平台边界：列出必须支持的系统版本、设备形态和发布渠道；确认构建与签名所需的操作系统。例如 iOS 开发与签名通常需要 macOS / Xcode。
- 关键能力：用小型原型验证相机、蓝牙、地图、支付、推送、后台任务等真正会用到的功能，而非只看插件列表。
- 实际体验：在低端设备和目标系统上测启动、内存、滚动、输入法、辅助功能与离线行为。
- 维护成本：核对插件维护状态、升级频率、平台代码比例，以及团队熟悉的语言和调试工具。
如果需求尚不明确，先做一个包含最难设备能力和一条完整业务流程的原型，再决定框架。跨平台方案降低的是一部分重复开发成本，并不会消除各平台的测试、适配和发布工作。