多端跨端技术选型：小程序 + H5 + App 的两栈拆分落地

我是如何完成 App 与小程序技术选型的：从三端统一到拆栈落地

项目需求：覆盖 H5 + 微信小程序 + App 三端。本意是"一套代码三端统一"，但调研后确认：RN 无法编译小程序，真正的一套代码三端不存在。实际方案必须拆栈：RN 写 App + Taro/UniApp 写 H5/小程序。本文记录选型过程中遇到的关键问题、纠结点与最终决策。

一、核心认知修正：三端统一是理想，拆栈是现实

最初的目标是"一套代码覆盖三端"，但调研第一个结论就推翻了这个前提：

RN 只覆盖 App 端，无法编译小程序，不存在"RN 一套代码三端"的可能性。
UniApp 和 Taro 虽然号称三端，但 App 端体验弱（UniApp 需 nvue/uts 补，Taro 的 App 端本身依赖 RN 编译），达不到商业级原生体验。

所以现实是：如果要 App 原生体验，RN 不可替代；H5/小程序必须用 UniApp 或 Taro。两套代码栈，拆栈是唯一务实选择。

拆栈后，H5/小程序选 Taro（React）还是 UniApp（Vue），就变成了"能否与 RN（React）共享逻辑层"的问题。这是整个选型的核心分歧点。

二、问题一：RN 为什么不能出局

第一个问题：能不能不用 RN，直接 UniApp/Taro 一套到底？

答案取决于 App 体验的要求：

如果 App 只是"能用就行"，UniApp/Taro 一套到底可以接受，省一套代码。
如果 App 是核心入口、体验要求高，RN 的原生渲染不可替代，UniApp/Taro 的 App 端体验有天花板。

结论：本项目 App 体验要求高，RN 不出局，而是 App 端主力。

维度	UniApp	Taro	RN
覆盖端	App + H5 + 全小程序	App(RN) + H5 + 全小程序	仅 App（无小程序）
技术栈	Vue	React / Vue	React
App 体验	弱（需 nvue/uts 补）	弱（依赖 RN）	原生最佳
生态	国内最大	大厂背书，窄于 UniApp	国际最大，小程序空白
定位	H5/小程序主力	H5/小程序主力（React）	App 端主力

三、问题二：H5/小程序选 Taro 还是 UniApp--真正的分歧

RN 确定写 App 后，H5/小程序在 Taro 和 UniApp 之间选。两者覆盖端和编译能力差距不大，真正的分歧是技术栈对逻辑复用的影响：

选 Taro（React）：与 RN 同为 React，可共享 hooks、请求层、TS 类型定义、状态管理逻辑，复用率最高。
选 UniApp（Vue）：与 RN（React）跨语言，逻辑复用归零，团队需要 React + Vue 双语言能力。

这是一个比"哪个框架更好"更重要的决策点。它不是框架能力问题，而是团队技术栈与长期维护成本问题。

决策依据：

团队以 React 为主 -> Taro，与 RN 共享逻辑，一套技术栈打天下。
团队以 Vue 为主、且不愿引入 React -> UniApp，接受 App 与 H5/小程序逻辑不复用。

四、问题三：脚手架选择

Taro 线

Taro 官方脚手架（taro init）开箱即用，支持 React + TypeScript + Vite/Webpack，内置多端编译配置。无需第三方增强模板，官方 CLI 足够。

UniApp 线

unibest（unibest.tech）：UniApp + Vue3 + TypeScript + Vite5 + UnoCSS 一体化模板，CLI 一键创建，支持集成 Wot UI / uView Pro。选它的理由是省基建时间、内置最佳实践、社区活跃。

遇到的问题：unibest 默认集成 Wot UI，如果要换 uView Pro 需手动替换。不过集成是可配置的，成本可控。

五、问题四：UniApp UI 组件库的"七选一"困境

UniApp 生态有 7 个候选组件库，这是选型中最耗时的环节：

组件库	备注
wot-ui	unibest 默认，Vue3，MIT 全开源
uView Pro	TS 重写，全家桶，版本 0.6.x
uView Next 3.x	平台覆盖最广
uv-ui	社区分支
uView Plus	部分组件需会员
TDesign	腾讯出品
sard-uniapp	社区项目

遇到的问题：

uView 系列命名混乱。uView Pro、uView Next、uv-ui、uView Plus 四个名字相近，来源不同。uView Pro 是独立项目（非 uView Plus），基于 uView 1.8.8 用 TS 重构；uView Plus 是另一条线。
uView Plus 的会员陷阱。标 MIT 协议但部分组件要开会员，商业项目避坑。
版本号与成熟度的矛盾。uView Pro 功能全（80+ 组件、工具函数、页面模板），但版本才 0.6.x，基线 uView 1.8.8 偏老，维护风险高。
TDesign 和 sard-uniapp 在 UniApp 生态中案例少，社区资料缺乏，不敢做商业主力。

UniApp 线最优选 ：Wot UI。v2.2.0 成熟、MIT 全开源无门槛、社区活跃案例多、文档现代（VitePress v2 + AI 友好）。工具层空白（http/route/校验）用 VueUse + 自研补，成本很低。uView Pro 作为 C 端电商场景备选（全家桶 + 页面模板能提速），但要接受版本风险。

六、问题五：Taro 组件库生态的单薄与最优选

Taro 组件库选择面窄，成熟可用的只有 NutUI（京东官方，MIT 全开源，React/Vue 双版本）。这是 Taro 生态的隐患--如果 NutUI 不满足需求几乎没有备选。

但换个角度看，NutUI 是京东官方出品，与 Taro 同厂，兼容性最好，质量有保障。单点依赖有风险，但同厂维护的确定性比第三方社区库强。

Taro 线最优选 ：NutUI-React-Taro。京东官方 + 同厂兼容 + MIT 全开源无会员，是 Taro 生态唯一且最优的选择。

七、问题六：Wot UI vs uView Pro--纯组件库还是全家桶

这是 UniApp 线最纠结的决策点。两者组件数量打平（80 vs 78），差距在"形态"不在"多少"。

维度	Wot UI	uView Pro
定位	纯组件库	全家桶（组件 + 工具 + hooks + 模板）
成熟度	v2.2.0，有迁移文档	v0.6.8，基线老 1.8.8
Vue 支持	仅 Vue3	Vue2 + Vue3
商业许可	MIT 赞助制，无门槛	MIT 全免费
文档	VitePress v2，AI 友好	VitePress v1，偏传统
社区	活跃，案例多	小，资料少

差异化优势

Wot UI 更"现代组件"：多了 FloatingPanel 浮动面板、ImgCropper 图片裁剪、Signature 签名、SlideVerify 滑动验证、Tour 漫游、Watermark 水印、VideoPreview、PasswordInput、Cascader 级联、DatetimePickerView、CalendarView 等新式交互组件。组件更新、更聚焦质量。

uView Pro 更"全家桶"：真正值钱的是 17 个工具函数--尤其 http 请求库、route 路由跳转、test 规则校验、time 时间格式化，这些是业务高频刚需，Wot UI 一个都没有。再加 10 个开箱页面模板，C 端电商类项目能省不少搭壳时间。

决策

商业级主力选 Wot UI：v2 成熟度 + 社区案例 + 长期维护确定性，比"省几个工具函数"更值钱。工具层用 VueUse + 自研补，成本可控。

C 端电商场景（登录/订单/收货地址/支付）可备选 uView Pro：全家桶开箱即用能快一截，但要接受版本 0.6.x + 基线老 + 社区小的风险。

八、问题七：RN 组件库选型------从三选一到四方向收敛

App 端用 RN，组件库选型参考了 LogRocket Blog《10 款最佳 React Native UI 库》（作者 Aman Mittal，2025-12 由 Clara Ekekenta 更新，对齐 Expo SDK 54）。这不是导流 listicle，而是带四维度硬评测的技术文，覆盖 gluestack UI、NativeWind、Shopify Restyle、Dripsy、Tamagui、React Native Paper、React Native Elements、UI Kitten、RNUIlib（Wix）、Shoutem UI 十个库。

评测维度一：性能与包体积

LogRocket 按编译优化分级，这套框架很值得借鉴：

顶级（编译优化）：Tamagui、NativeWind --- 样式编译期处理，无运行时桥开销。
中级（运行时样式）：Shopify Restyle、React Native Paper --- Paper 的 Material 全量包会撑大体积，需开 Babel 插件 tree-shake。
低级（遗留）：NativeBase、UI Kitten --- 每次 render 都算样式，动画密集页会掉帧。

备注：Tamagui 和 gluestack 已标准支持 tree-shaking；React Native Elements 默认打包未用组件，体积大。

评测维度二：设计系统就绪度

Shopify Restyle 类型安全 token 最强（企业级）；Tamagui 有 Figma 插件（Takeout）；Paper 偏死板（仅 Material）。

Paper 最强（原生遵循 Material 48dp 触控目标/读屏标签）；gluestack 基于 react-native-aria，焦点陷阱做得好；Dripsy 和 Elements 只顾视觉，a11y 要手动加。

评测维度四：Web & Expo 兼容

gluestack、Tamagui 通用化最好（Web 渲染语义 div，移动用 View，支持 Fabric/TurboModules）；Elements、UI Kitten Web 体验差。

社区健康度（npm 周下载量）

NativeWind：403k/周（从 Web/Tailwind 转 Native 的首选）
React Native Paper：337k/周（Callstack 维护，Material 最稳）
Tamagui：75k/周（创新高但采用小众）
React Native Elements：46k/周，且改名 @rneui/themed 后碎片化、式微，只适合维护遗留项目

交叉验证与淘汰项确认

LogRocket 评测与我们前面 GitHub/npm 核实的结论高度一致：

gluestack vs Paper 双雄：明确把 gluestack（无障碍/通用）和 Paper（Material/稳定）作为两个主流方向。
NativeBase 已停维：直接列进「低级/遗留」，印证「Evolution to gluestack」。
React Native Elements 式微：改名 @rneui/themed 后碎片化，只适合遗留维护。
UI Kitten 性能硬伤：运行时算样式、动画密集页掉帧，归入遗留档。C 端商业 App 别选它。

淘汰项：NativeBase（停维）、React Native Elements（式微 + 改名碎片化）、UI Kitten（运行时性能硬伤）。

最终收敛：四个方向

综合 LogRocket 评测 + GitHub/npm 核实，RN 端结论收敛为四个方向：

方向	适合场景	代表库
C 端自定义视觉、重交互、要无障碍	设计自由 + 编译优化 + a11y 开箱	gluestack v5
Material 风、求稳、文档成熟	社区最大、最稳定	React Native Paper（注意开 Babel 插件瘦身）
企业级自建设计系统、有 token 体系	类型安全，但需配合自建组件	Shopify Restyle
极致性能、愿意学新 API	编译优化最强，但采用小众	Tamagui

本项目选择

React Native Paper。最成熟、最稳定、社区最大（337k/周），作为 RN 端唯一组件库。两个注意事项：

Material 全量包体积大，必须开 Babel 插件 tree-shake 瘦身。
如果 App 有大量动画/列表等重交互场景，gluestack v5 在性能档位上优于 Paper（编译优化 + tree-shaking），可作为备选切换。

九、问题八：antd-mobile 的框架限制

antd-mobile（蚂蚁移动端组件库）仅支持 H5（React），不支持 Taro 编译、不支持小程序。如果选它，H5 和小程序/App 必须用不同组件库，违背统一初衷。三端方案直接排除，只在纯 H5 项目中考虑。

十、最终方案：双路线最优选

路线一：React 全栈（推荐）

css 复制代码

App 端：     RN + React Native Paper
H5/小程序：  Taro + NutUI-React-Taro
共享层：     hooks / 请求层 / TS 类型定义 / 状态管理（React 全复用）

优势：App 与 H5/小程序同为 React，逻辑层最大程度复用。一套技术栈，团队不用维护 Vue + React 双语言。这是拆栈方案中复用率最高、维护成本最低的组合。

代价：Taro 组件库绑死 NutUI（单点依赖），App 与 H5/小程序仍是两套代码两套构建。

路线二：Vue + React 混合

css 复制代码

App 端：     RN + React Native Paper
H5/小程序：  UniApp + Wot UI（商业主力）/ uView Pro（C 端电商备选）
脚手架：     unibest（Vue3 + TS + Vite5 + UnoCSS）

优势：H5/小程序用 UniApp 生态最广、组件库选择面最宽（7 个候选）。Vue 团队上手快。

代价：App（React）与 H5/小程序（Vue）跨语言，逻辑复用归零。团队需要 React + Vue 双语言能力。

选型建议

团队以 React 为主 -> 路线一。RN + Taro 共享逻辑，是拆栈方案的最优解。
团队以 Vue 为主 -> 路线二。UniApp 生态成熟，但接受 App 逻辑不复用。
无论哪条路线，App 端都是 RN + React Native Paper，这是 App 原生体验的唯一答案。

十一、选定库详解

以下介绍最终方案中选用的核心库，分框架层、组件库层、工程化层三部分。

框架层

React Native（RN）

Facebook 开源的跨平台移动开发框架，用 React + 原生组件渲染，不走 WebView，直接映射到 iOS/Android 原生 UI。App 端体验最接近原生，动画、手势、长列表性能优于 Hybrid 方案。本项目用它做 App 端唯一框架，原因是三端方案中只有 RN 能提供商业级原生体验。代价是不覆盖小程序，所以必须拆栈。

Taro

京东凹凸实验室开源的跨端框架（React/Vue 双支持），一套代码编译到 H5、微信/支付宝/百度/字节小程序、RN 等多端。React 语法 + JSX，与 RN 同技术栈，可共享 hooks、请求层、TS 类型。本项目 React 路线选它做 H5/小程序主力，核心收益是与 RN 的逻辑层复用。京东官方维护，社区活跃，版本迭代稳定。

UniApp

DCloud 出品的跨端框架，Vue 语法，编译到 H5、全小程序、App。国内生态最大，组件库选择面最宽（7 个候选），文档和社区资料最丰富。本项目 Vue 路线选它做 H5/小程序主力。App 端体验弱于 RN，需 nvue/uts 补关键页面。适合 Vue 团队、对 App 体验要求不极端的项目。

组件库层

React Native Paper

Callstack 团队维护的 RN Material Design 组件库，npm 周下载 337k，RN 生态中最成熟、最稳定。组件覆盖全（Button、Card、Dialog、TextInput、List、Drawer、Appbar 等），主题系统完善，支持深色模式，a11y 最强（原生遵循 Material 48dp 触控目标/读屏标签）。本项目选它做 RN 端唯一组件库。两个注意事项：Material 全量包体积大，必须开 Babel 插件 tree-shake 瘦身；性能属中级（运行时样式），如果 App 有大量动画/列表等重交互场景，gluestack v5（编译优化）在性能档位上更优，可作为备选。

NutUI-React-Taro

京东凹凸实验室出品的组件库，React/Vue 双版本，Taro 版本与 Taro 框架同厂开发，兼容性最好。MIT 全开源无会员门槛，组件覆盖电商高频场景（商品卡片、价格、倒计时、地址选择等）。本项目 React 路线选它做 Taro 端组件库。是 Taro 生态唯一成熟选择，单点依赖有风险但同厂维护确定性高。

Wot UI

社区维护的 UniApp 组件库，仅 Vue3，MIT 全开源无门槛（赞助制非会员）。v2.2.0，文档基于 VitePress v2，提供 LLMs.txt 和 Skills 文件，AI 友好。80+ 组件，包含 FloatingPanel、ImgCropper、Signature、SlideVerify、Tour、Watermark 等新式交互组件。本项目 Vue 路线选它做 UniApp 商业主力组件库。短板是工具层空白（http/route/校验全得自己补），用 VueUse + 自研解决。

uView Pro（备选）

独立项目（非 uView Plus），基于 uView 1.8.8 用 TypeScript 重构，MIT 全免费。80+ 组件 + 17 个工具函数（http 请求、route 路由跳转、test 规则校验、time 时间格式化）+ 10 个开箱页面模板，全家桶形态。本项目作为 C 端电商场景备选，开箱模板（登录/订单/收货地址/支付）能提速。短板是版本 0.6.x、基线偏老、社区小，维护风险需持续监控。

工程化层

unibest

社区维护的 UniApp 脚手架模板，集成 Vue3 + TypeScript + Vite5 + UnoCSS，CLI 一键创建项目，内置目录结构、请求封装、路由管理最佳实践，支持可配置集成 Wot UI / uView Pro。本项目 Vue 路线用它省去基建时间。Taro 路线用官方 taro init 即可，无需第三方模板。

VueUse

Vue 3 组合式 API 工具函数库（Anthony Fu 等维护），200+ 工具函数覆盖状态管理、DOM 操作、网络请求、浏览器 API、传感器等。本项目用它补 Wot UI 缺失的工具层，替代 uView Pro 的 http/route/test 等函数。轻量、按需引入、Tree-shaking 友好。

Vite 5

Evan You 开发的下一代前端构建工具，基于 ESBuild 预构建 + Rollup 打包，dev server 毫秒级冷启动，HMR 极速。Taro 和 UniApp（通过 unibest）都支持 Vite。本项目全链路统一用 Vite 5 构建。

UnoCSS

Anthony Fu 开发的即时按需原子化 CSS 引擎，Tailwind/Windi 兼容语法，性能更快、扩展性更强。unibest 默认集成。本项目 UniApp 线用它做样式方案，与 Vue 3 + Vite 配合最佳。

TypeScript

全链路类型安全。RN、Taro、UniApp 均原生支持 TypeScript，共享的 hooks/请求层/TS 类型定义可跨端复用（React 路线）。本项目所有代码均用 TS 编写，接口、枚举、权限码不硬编码，类型先行。

十二、落地建议

各端跑最小 Demo：文档对比再多不如真机验证。先把表单、列表、弹层三个高频页面在各端跑通。
共享层优先设计：路线一的关键收益是逻辑复用，项目第一天就要把 hooks、请求层、TS 类型、状态管理抽成独立包，App 和 H5/小程序共同引用。不要等到后期才补。
组件库双跑验证：UniApp 线把 Wot UI 和 uView Pro 各拉一份，业务最高频的 3 个页面各实现一遍，比组件清单对比更准。
App 体验早期验证：动画/长列表/地图等重交互页面尽早用 RN 验证可行性。
监控组件库维护状态：uView Pro 版本号低、社区小，定期检查 GitHub 提交频率和 issue 处理情况，一旦维护停滞果断切换 Wot UI。NutUI 虽同厂维护，也要关注 Taro 大版本升级时的兼容节奏。
工具层统一封装：无论选哪个组件库，http 请求、路由跳转、表单校验建议统一封装，不直接依赖组件库内部实现，便于后续替换。