Vue、React、Flutter、uni-app怎么选？

团队刚确定“要做一个 App”，选型表里就摆上 Vue、React、Flutter、uni-app，比性能、生态和学习成本。

问题是，这四个名字并不处在同一层。硬排一个总冠军，就像拿装修图纸、施工队、预制房和商场运营系统放在一起问“谁更适合盖房子”。

这篇文章不绕概念。看完你应该能弄明白三件事：它们到底是什么、分别能做什么，以及 2026 年自己的项目该从哪里选。

先给最短答案：

• Vue：主要用来开发网页界面的 JavaScript 框架。
• React：用于构建用户界面的 JavaScript 库；做移动 App 时，通常还要补全为 React Native、Expo 或 Web 宿主方案。
• Flutter：使用 Dart 开发跨平台应用的一整套 UI 工具包和运行体系。
• uni-app：以 Vue 开发体验为重要入口，面向小程序、H5、App 等多个目标端的跨端框架。

它们都可能参与一个移动产品，但解决的问题不同。真正该比较的不是四个裸名字，而是四套完整交付方案。

Vue：擅长把网页界面搭起来

Vue 最直接解决的是网页里的组件、数据和交互怎么组织。公司官网、活动 H5、企业后台、数据看板和 Web 应用，都是它熟悉的场景。

但“会 Vue”不等于已经会做完整的 iOS、Android App。

一个可安装的 App 还要处理相机、定位、推送、蓝牙、应用签名和商店发布。Vue 项目如果要进入手机，通常需要 Capacitor 一类原生容器，或者进入 uni-app 等跨端体系。

所以 Vue 能做移动页面，也能参与 App，但它本身不是一套完整的移动应用交付方案。

React：先说清是 React，还是 React Native

React 也用组件和状态组织界面，在网站、Web 应用和复杂交互产品里很常见。

问“React 能不能做 App”，答案是能，但这句话少了半截。真正需要讨论的通常是 React Native 或 Expo。

React 提供界面开发模型；React Native 把这套模型带到移动端，并用平台支持的原生组件呈现界面。另一条路线，是让 React Web 页面运行在原生容器中。两条路线的渲染、系统接入和维护方式并不相同。

把 React 和 React Native 当成一个词，会让后面的选型全部失焦。

Flutter：自己带着一套画界面、跑应用的体系

Flutter 使用 Dart 和 Widget 编写界面。它不只是告诉开发者组件怎么写，还带着 framework、渲染引擎和平台嵌入层，能直接面向 iOS、Android、Web 和桌面系统。

多数 Flutter 界面不是网页，也不是简单地把每个 Widget 翻译成同名系统控件。它有自己的布局、合成和绘制体系，因此跨平台 UI 的控制力更强，团队也要接受 Dart、Flutter 插件和对应构建链。

Flutter 能直接做移动 App，不代表它消灭了平台差异。相机、地图、推送、支付和厂商 SDK，仍然要经过插件、Platform Channel 或平台工程。

uni-app：重点解决小程序、H5、App 多端交付

uni-app 的价值很明确：让熟悉 Vue 的团队使用相近的组件和语法，同时面向微信、支付宝、抖音等小程序，以及 H5、iOS 和 Android App 开发。

如果一个中国互联网项目要求“小程序 + H5 + App”同时交付，它往往会很早进入候选名单。

但把 uni-app 简化成“Vue 套壳”也不准确。老 uni-app 的 App-Vue、nvue，以及持续演进的 uni-app x，在语言能力、渲染路径和扩展机制上并不完全相同。选型时必须写清具体使用哪条路线，不能只写一个 uni-app。

用一个外卖项目，看懂它们各自站在哪里

【上传图片：images/06-food-delivery.png】

假设一家公司要做运营后台、活动 H5、微信小程序和骑手 App。

运营后台和活动 H5，可以直接用 Vue 或 React。这里主要解决页面组件、表单、状态、接口数据和交互逻辑。

微信小程序如果希望沿用 Vue 开发习惯，未来还要发布支付宝小程序和 H5，uni-app 会成为明确候选。

骑手 App 如果包含持续定位、地图、推送、拍照上传和语音提醒，比较对象就不该是“Vue 对 Flutter”，而应该写成：

• Flutter + 地图、定位、推送插件；
• React Native / Expo + 原生模块；
• uni-app 具体模式 + UTS 或原生扩展；
• Vue Web + Capacitor + 原生插件；
• Kotlin / Swift 原生实现。

同一个项目完全可能同时使用 Vue、uni-app 和 Flutter。技术选型不是要求公司只留下一个框架名，而是让每个产品端使用合适的完整方案。

真正会卡住项目的，往往不是页面

我查完四套官方架构后，最终保留了一个比“代码复用率”更有用的问题：统一抽象覆盖不到时，谁来接盘？

我把必须进入下一层解决问题的路径叫作“逃生口”。例如：

• Vue + Capacitor 可能进入 Swift、Kotlin 和原生插件；
• React Native 可能进入 Native Module、原生组件和分平台文件；
• Flutter 可能进入 Platform Channel、Platform View 和宿主工程；
• uni-app 可能进入条件编译、UTS 插件、原生 SDK 或分平台实现。

普通页面通常不会把这些差异全部暴露出来。地图、后台定位、蓝牙、实时音视频、支付和厂商 SDK，才容易让团队频繁使用“逃生口”。

这也是为什么“一套代码能复用多少”不能单独代表成本。哪怕只有少量代码不能复用，只要它控制着支付、定位或上架，那部分代码就可能决定整个项目能不能交付。

别再做计数器 Demo，直接测最难能力

“首页跑起来了”只能证明框架会画页面，不能证明产品能够上线。

比如打开相册。一次点击背后至少经过业务代码、框架 API、插件或桥接层、iOS/Android 系统权限，再把结果送回页面。这已经能帮助团队看见五层关系：

1. 业务代码怎么写；
2. 界面由谁渲染；
3. 代码运行在哪个运行时；
4. 系统能力怎么接入；
5. 应用怎么构建和发布。

但真实选型不能只测相册。骑手 App 最难的是后台定位，就用后台定位做真机原型；产品核心是视频通话，就验证弱网、前后台切换和真实设备；小程序支付不可删除，就把登录、支付和审核链跑通。

一份有效的验证记录，至少要写清：

• 框架、插件和 SDK 的具体版本；
• 哪些代码共享，哪些代码分平台；
• 是否修改过 Xcode、Gradle 等原生工程；
• debug 和 release 是否都成功；
• 测过哪些系统版本与真实设备；
• 插件或系统升级后由谁重新验证。

如果现在必须给出第一候选，我的建议是：

1. 从零进入全球 Web 前端生态：先看 React

Stack Overflow 2025 开发者调查的 Web 技术样本中，React 使用率为 44.7%，Vue.js 为 17.6%。这能说明 React 在该 Web 样本中覆盖更广，但不能推出它在所有项目里性能更强。

团队已经有成熟的 Vue 组件、模板和工程资产，就不必为了热度重写。中国团队做后台、管理系统，Vue 仍然是很自然的候选。

2. 从零开发 iOS、Android 跨端 App：默认先评估 Flutter

Flutter 提供较完整的跨平台移动应用路线。2025 年一项跨平台移动开发研究中，Flutter 的长期满意度中位数更高；React Native 的招聘职位中位数更高。两者各有现实优势。

如果团队已经有成熟的 React、TypeScript 人员和组件资产，先看 React Native / Expo，往往比强行切换语言更合理。

3. 同时做小程序、H5、App：优先看 uni-app

这是 uni-app 最明确的主场，尤其适合熟悉 Vue、主要服务中国互联网平台的团队。

如果蓝牙、后台定位、音视频、地图或特殊硬件是产品核心，就要先验证插件、UTS 或原生扩展能力。验证不过，原生方案必须回到候选名单。

4. 核心能力高度依赖系统：原生优先，或跨端配原生团队

跨端不是越彻底越好。最难且不可删的能力需要长期进入 iOS、Android 平台层时，团队是否有人能维护 Swift、Kotlin、Xcode 和 Gradle，比框架宣传的覆盖端数更重要。

截至 2026 年 8 月 24 日，四个官方主仓库累计 Star 快照约为 React 247,675、Flutter 178,618、Vue Core 54,234、uni-app 41,599。这个数字只能作为开源关注度快照，不能混成“综合冠军榜”。

一张可以直接拿去开会的选型清单

在写框架名之前，先让团队回答五个问题：

1. 最终发布到 Web、小程序、iOS、Android 中的哪些端？
2. 产品最难且不可删除的能力是什么？
3. 团队已经掌握 Vue、React、Dart、Kotlin、Swift 中的哪些技术？
4. 目标版本的插件和 SDK 覆盖到哪里？
5. 抽象失效后，前端、跨端工程师、原生工程师还是供应商负责维护？

我最后保留的选型顺序很简单：先列目标平台，再找最难能力，然后看团队已有资产，最后检查插件、原生接入和发布责任。

完成这四步，再谈哪个框架更适合。否则表格列得再长，也可能只是在比较四个名字。

如果你正在选型，可以在评论区留下“目标端 + 最难且不可删的能力”，比如“iOS / Android + 后台定位”或“微信、支付宝小程序 + 支付”。我会按这套路径继续拆。

证据边界

• 本文不提供性能冠军或成本排名，因为目前没有统一任务、设备、版本和 release 构建下的四者对照实验。
• React 与 React Native / Expo 必须区分；Vue 与具体移动宿主必须区分。
• uni-app、nvue、uni-app x 需要按具体模式和版本讨论。
• “逃生口”是本文依据官方架构资料整理的定性检查方法，不是行业标准评分。
• 资料与仓库数据核对日期：2026 年 8 月 24 日。

1. Vue.js：Introduction
2. React 官方网站
3. React Native：Core Components and Native Components
4. React Native：Platform-Specific Code
5. React Native：Native Platform
6. Flutter：Architectural Overview
7. Flutter：Supported Deployment Platforms
8. Flutter：Platform Channels
9. Flutter：Platform Views
10. Flutter：Add Flutter to an Existing App
11. Capacitor：Getting Started / Plugins
12. DCloud：uni-app 组成和跨端原理
13. DCloud：条件编译处理多端差异
14. DCloud：uni 版本说明
15. DCloud：uni-app x 是什么
16. DCloud：uni-app 升 uni-app x 指南
17. Stack Overflow：2025 Developer Survey—Technology
18. Jošt 与 Taneski：跨平台移动应用开发框架研究
19. GitHub 官方仓库快照：React、Flutter、Vue Core、uni-app