企业官网建设流程全解析

选型永远不只是技术问题。当领导抛出“做一个微信小程序，顺便以后还要覆盖支付宝、百度、抖音，甚至以后可能还要 App 端”这种需求时，摆在桌面上的选项看起来很多，但你真正纠结的其实是两句话：用原生写，稳但慢；用跨平台写，快但要接受某些不可控。这样一个朴素的问题，背后却牵扯工程化程度、团队技术栈、长期维护成本、多端一致性、第三方 SDK 适配这些现实阻力。

本文尝试把原生小程序开发、uni-app、Taro 三者放在同一张表里做对比，不预设立场，从语法、运行机制、工程化、性能、生态、团队成本、踩坑边界等方面完整拆开来看。如果你手头正有一个小程序项目要启动，或者你在负责团队的技术选型，这篇文章的建议部分可以直接拿来做评审参考。全文不依赖任何商业机构的官方宣传口径，尽量用工程上的实际约束来说话。

1. 背景与核心概念

1.1 小程序开发为什么会出现“框架之争”

从 2017 年微信小程序上线开始，小程序这种“无需安装、即用即走”的应用形态逐渐成为移动端业务的一个重要入口。随后支付宝小程序、百度智能小程序、字节跳动小程序、QQ 小程序陆续出现，各家平台在底层能力和开放接口上各有侧重，但又都遵循相似的页面-组件-API 逻辑。

问题也出在这里。如果只做微信小程序，原生开发完全足够。但一旦业务需要覆盖多端，每个端都从零开始写一套逻辑，维护成本会成倍上涨。比如一个电商项目，微信小程序一套代码，支付宝小程序又要重新处理登录、支付、路由，抖音小程序可能还要改组件写法。这种重复劳动催生了跨平台框架的需求：写一套代码，通过编译和运行时适配，同时输出到多个小程序平台，甚至还可以输出到 H5 和 App。

这就是 uni-app 和 Taro 存在的最根本原因。它们不是要取代原生开发，而是在“多端交付”这个约束下，提供更高效的生产力方案。

1.2 几种技术路线的准确区别

先明确三个概念，后面所有对比都基于这个框架。

原生小程序开发

原生小程序开发指直接使用微信官方提供的 WXML、WXSS、JS/TS 以及微信开发者工具进行开发。需要注意，这里说的“原生”是相对于跨平台框架而言，不代表没有工程化工具。现在做原生小程序，同样可以用 npm、TypeScript、ESLint、自动化测试等现代前端工程化手段。原生方式的优势是：不依赖任何中间编译层，微信新增能力官方会第一时间支持，调试链路最短，出现问题时定位最快。

uni-app

uni-app 是由 DCloud 团队推出的跨端框架，基于 Vue 语法，使用 Vue 2 或 Vue 3 编写代码，通过 HBuilderX 或 CLI 方式创建项目。编译器会把 Vue 单文件组件（.vue）编译成各个小程序平台能够识别的代码。uni-app 的覆盖面很广，支持微信、支付宝、百度、字节、QQ、快手小程序，还能编译到 H5 和 App（App 端通过 WebView 或 uni-app x 这样的新方案实现）。

Taro

Taro 是由京东凹凸实验室（现京东前端团队）开源的跨端框架，以 React 语法为基底，支持 React 语法写小程序。Taro 3 之后的架构发生了变化，不再像 Taro 1/2 那样把 React 代码编译成小程序原生语法，而是将整个 React 运行时直接在小程序上运行，这样能够保证 React 生态中大量成熟库在 Taro 项目中继续可用。Taro 支持微信、支付宝、百度、字节、QQ 小程序及 H5 端，也能通过 Taro Native 的方式去做 React Native 端的扩展。

1.3 一个容易混淆的话题：小程序跨平台框架算不算“编译型”方案

经常能看到关于 Taro/uni-app 是编译时还是运行时的讨论。Taro 3 之后采用的是“运行时 + 编译时”结合的方式，把 React DOM 树映射到小程序的自定义组件树，而不是把 React 代码逐行翻译成 WXML。uni-app 则更偏向编译时方案，会在编译阶段解析 .vue 文件、拆分模板与逻辑，把模板转成目标平台支持的模板语法。理解这个差异对后面排查性能问题很有帮助：凡是带运行时的方案，框架代码本身会有基础包体积；凡是带编译的方案，某些动态渲染、复杂表达式、高阶组件用法可能都会因为编译限制而被卡住。

2. 环境准备与版本说明

做技术对比不能停留在口头上，最好把本地开发环境搭起来，实际创建项目试试。下面给出三套环境的搭建方式，重点是演示配置思路，不同时间节点下你安装到的工具版本很可能不同，所以这里不锁死版本号。

2.1 原生小程序开发环境

原生小程序开发至少需要：

• 微信开发者工具（稳定版即可，建议开启“服务端口”）
• Node.js（用于 npm 包管理，建议 LTS 版本）
• 微信小程序后台申请一个测试 AppID；没有正式 AppID 时，可以用测试号，但部分能力受限

创建项目时，在微信开发者工具中选择“小程序”，填入 AppID，模板可先选择 JavaScript 基础模板，后面按需加入 TypeScript。

2.2 uni-app 开发环境

• HBuilderX（DCloud 官方 IDE）或纯 CLI 方式
• Node.js 环境
• 微信开发者工具

使用 HBuilderX 创建项目的路径是：文件 -> 新建 -> 项目 -> 选择 uni-app 模板。如果习惯 CLI，也可以执行：

npx degit dcloudio/uni-preset-vue#vite my-uni-app cd my-uni-app npm install npm run dev:mp-weixin

说明：dev:mp-weixin是编译到微信小程序端的开发模式命令，执行后会在dist/dev/mp-weixin目录生成编译产物，然后通过微信开发者工具导入这个目录。

2.3 Taro 开发环境

• Node.js（建议 16 以上）
• pnpm 或 npm
• 微信开发者工具

创建项目的标准命令：

npx @tarojs/cli init my-taro-app

CLI 会交互式询问框架类型（React/Vue）、模板类型、TS 支持等，选择 React + TypeScript + 微信小程序模板即可。

cd my-taro-app npm install npm run dev:weapp

编译完成后，产物位于dist目录，同样通过微信开发者工具导入。

这里给你一个发自实战的建议：不要只看“创建项目成功”就下结论。选型前一定三家各跑一个 Hello World，分别体验一下改一行代码后的编译耗时、首次预览包体大小、真机调试的顺畅度。这三项体验差异往往比官方文档的性能对比数据更真实。

3. 核心技术机制拆解

3.1 原生小程序的双线程模型

理解小程序原生开发，必须先理解微信小程序的运行环境。小程序不是跑在普通浏览器里，而是基于微信客户端提供的 JSCore（iOS）和 V8（Android）环境运行逻辑层，同时用 WebView 渲染视图层。

逻辑层和视图层之间不能直接通信，只能通过微信客户端原生注入的setData通道传递数据。setData每次调用，本质上是一次从逻辑层到视图层的异步消息传递。这个机制带来的最直观影响是：

• 不要在setData里塞大对象和频繁变化的数据。
• 不要把整个 list 数据全量 setData，只传变更项。
• 不要在滚动等高频事件回调里直接 setData。

原生开发的所有性能优化技巧，几乎都围绕“如何减少 setData 频率和数据量”展开。这是原生小程序的底层约束，跨平台框架同样无法绕开，因为最终它们还是要调用小程序原生setData来更新界面。

3.2 uni-app 的编译映射逻辑

uni-app 选择了 Vue 语法作为开发语言，一个典型的页面是这样的：

<!-- pages/index/index.vue --> <template> <view class="container"> <text class="title">{{ title }}</text> <button type="primary" @click="handleClick">点击</button> </view> </template> <script setup> import { ref } from 'vue' const title = ref('Hello uni-app') function handleClick() { title.value = '你点击了按钮' } </script> <style> .container { padding: 30rpx; } .title { font-size: 32rpx; } </style>

这段代码如何变成一个微信小程序页面？简要流程如下：

• <template>被编译为 WXML。
• <style>中的 rpx 单位被保留，部分不支持的 CSS 选择器会被处理或移除。
• <script setup>被编译为小程序页面的 JS 逻辑。
• view、text、button这些标签会被映射为微信原生组件view、text、button。

所以，uni-app并不是一个运行时容器把 Vue 应用装进去，而是像一个“源到源编译器”，把 Vue SFC 转换为小程序可运行的代码。正因为如此，它的限制也来自编译层：如果你在代码里用了浏览器独有能力，例如直接操作window、document，编译时能放过你，但运行时在微信小程序里必然报错。

3.3 Taro 3 的运行时方案

Taro 3 的架构与 uni-app 的思路不同。Taro 3 把 React 的 reconciler 层接入到小程序的自定义组件树中，简单说就是在小程序运行时环境中模拟了一个 React DOM 树，让 React 组件逻辑可以直接跑起来，再做一层映射渲染到小程序原生组件。

下面是一个 Taro 页面示例：

// src/pages/index/index.tsx import { View, Text, Button } from '@tarojs/components' import { useState } from 'react' export default function Index() { const [title, setTitle] = useState('Hello Taro') return ( <View className='container'> <Text>{title}</Text> <Button onClick={() => setTitle('你点击了按钮')}>点击</Button> </View> ) }

从开发者视角看，代码中的View、Text、Button都是 React 组件，但它们在运行时并不生成真实的浏览器 DOM，而是经过 Taro 的 React reconciler 映射成小程序原生组件。这个设计让 Taro 项目能直接复用 React 生态里大量不依赖浏览器 DOM 的库，也让 React 开发者上手成本降到很低。

但运行时有代价：将 React 运行时塞进小程序逻辑层后，初始化时间会比原生方式更长，包体积也会增加。这也是 Taro 社区一直关心的性能问题。

3.4 动态渲染能力的边界

原生小程序有wx:if、wx:for；uni-app 有v-if、v-for；Taro 有 JSX 表达式。表面上看都能做列表渲染和条件渲染，但在复杂场景下的动态更新能力不一样。

原生和 uni-app 这类模板编译方案，模板里的结构基本静态化，条件分支、循环都会被预先分析，优化空间大，但写动态组件、根据运行时数据决定渲染哪个组件时会比较吃力。Taro 因为运行时有 React 的参与，理论上可以用 React 的 render props、高阶组件、context 等模式组织代码，在复杂组件逻辑上表达力更强。

需要明确表达力不等于性能。React 在小程序上动态 diff 一棵组件树，开销天然比模板编译出来的命令式渲染大。实际项目中，如果页面结构简单、以静态展示为主，模板方案更稳；如果逻辑复杂、状态联动多、组件复用度高，Taro 的 React 心智模型会让人写起来更顺手。

4. 原生、uni-app、Taro 横向能力对比

进入实操前，先给出横向对比总表。这张表基于常见环境下的通用特性，具体数据要以你当前测试环境为准。

需要重点关注的是“微信新能力跟进”这一项。小程序平台会不定期发布新组件、新 API，例如新的分享能力、新的硬件调用接口等。原生项目可以在能力开放后立刻接入；uni-app 和 Taro 则需要等待框架侧把对应能力封装好，或者在框架里通过条件编译直接写原生小程序代码来绕过，但那样就破坏了跨端一致性，等于为个别能力写平台特化代码。

5. 常见问题与排查思路

框架选型前，试跑几个有代表性的 Demo 往往比读文档有效。下面列的是三种技术栈下最容易踩中的问题，很多都来自开发者社群的真实求助。

5.1 “uni-app 的 scroll-view 高度算不对，内容不滚动”

这是一个非常典型的问题。在 uni-app 里实现多 Tab 固定区域滚动，常见写法是外层 flex 布局，内容区域用scroll-view。很多人会遇到scroll-view即便设置了scroll-y，内容超出后依然不滚动，或者 scroll-view 直接撑开了整个页面。

导致这个问题的根本原因是scroll-view需要明确高度约束，不能依赖内容撑开。你可以给它一个固定高度，也可以让它的父容器变成 flex 子项，通过 flex 布局分配剩余高度。

推荐做法：不让scroll-view自己算高度，而是通过布局“挤出”它的可用高度。以下示例演示如何解决主界面中scroll-view自适应剩余高度的问题：

<template> <view class="page"> <view class="header"> <!-- 顶部固定区域 --> </view> <scroll-view class="scroll-area" scroll-y > <view v-for="(item, index) in list" :key="index" class="list-item" > {{ item }} </view> </scroll-view> </view> </template> <style> .page { display: flex; flex-direction: column; height: 100vh; /* 让页面占据视口高度 */ overflow: hidden; } .header { height: 200rpx; flex-shrink: 0; background: #f5f5f5; } .scroll-area { flex: 1; /* 占据剩余高度 */ min-height: 0; /* 关键：允许子容器收缩到内容高度以下 */ overflow: hidden; } .list-item { height: 100rpx; line-height: 100rpx; border-bottom: 1px solid #eee; } </style>

关键点在于三处：

• page高度设为100vh，然后用overflow: hidden杜绝页面级滚动。
• scroll-view作为 flex 子项设置flex: 1，让布局系统把剩余高度分给它。
• min-height: 0允许 flex 子项收缩到内容高度以下，否则部分浏览器/小程序环境会按内容最小组件尺寸计算，scroll-view依然无法触发滚动。

如果你不用 flex 布局，也可以用onPageScroll或IntersectionObserver动态计算剩余高度并赋给scroll-view，但 flex 方案逻辑更少，也更易维护。

5.2 “scroll-view 已滚动到底部，但普通 view 中的内容滑不动”

另一个高频问题是页面拆成两个区域，一个顶部是普通view，一个是scroll-view。用户希望普通view里的内容滚动到最顶，但手势操作被scroll-view拦截，普通 view 一直没有滚动。

这个问题的根因和 5.1 类似：普通view天然不产生滚动，内容超出后会被裁剪或直接撑开页面。如果你需要让页面里一个普通view内容也能“滑动到最顶端”，建议：

• 改用scroll-view并设置scroll-y和明确高度；
• 或者直接使用页面级onPageScroll滚动，不去做内嵌滚动；
• 如果这段内容只是长列表，可以使用page-meta配合页面原生滚动。

以下是一个让普通 view 中的长内容滚动到最顶端的scroll-view方案：

<template> <view> <scroll-view class="article-scroll" scroll-y > <view class="article-content"> <!-- 长内容 --> </view> </scroll-view> <view class="go-top" @click="scrollTop">回到顶部</view> </view> </template> <script setup> const articleScroll = ref(null) function scrollTop() { // 方案一：直接用 scroll-view 的 scroll-top 属性 // 方案二：通过 SelectorQuery 拿到 scroll-view 节点并调用 scrollTo const query = uni.createSelectorQuery() query.select('.article-scroll').node((res) => { if (res && res.scrollTo) { res.scrollTo({ top: 0, duration: 300 }) } }).exec() } </script>

方案一在该示例中更直接，页面里绑定一个scroll-top变量，点击后置 0 即可。不过需要留意的是，scroll-top在连续点击时需要先置一个非 0 值再置 0，否则可能因为值未变化而不触发事件。

const scrollTopValue = ref(0) function goTop() { scrollTopValue.value = 1 nextTick(() => { scrollTopValue.value = 0 }) }

在使用跨平台框架时，遇到这类惯性滑动、滚动监听、吸顶问题，建议先回退到原生小程序思维想一想：这个能力在微信小程序原生环境里是怎么做的？想清楚了再套框架的 API，排错会轻松很多。

5.3 “Taro 项目引入 React 库时，浏览器 API 报错”

Taro 3 支持 React 生态，但并不是所有 React 库都能在小程序环境正常工作。很多 UI 库、工具库都直接或间接依赖window、document、navigator等浏览器对象，小程序运行环境没有这些对象，就会报 undefined 错误。

排查步骤：

• 判断报错库是纯逻辑库还是 DOM 库。纯逻辑的如 lodash、dayjs 通常没问题。
• 如果依赖了浏览器 API，在小程序里不能直接用。
• 同类能力优先选 Taro 官方或社区封装好的库。
• 自己封装时使用process.env.TARO_ENV判断环境，在不同端差异化实现。

import { getSystemInfoSync } from '@tarojs/taro' function getSafeAreaTop() { // 兼容 H5 和小程序的取值方式差异 if (process.env.TARO_ENV === 'h5') { return window.innerHeight } const info = getSystemInfoSync() return info.safeArea ? info.safeArea.top : 0 }

5.4 “uni-app 项目如何用 Android Studio 做原生打包”

“uni-app x”方向或部分使用原生插件的场景，可能会接触到 Android Studio 原生工程。HBuilderX 自带云打包能力，但如果要本地接入原生 SDK，比如集成某个原生统计 SDK、音视频 SDK，就需要在 Android Studio 中把 uni-app 的离线打包资源与原生工程合并。

常规步骤大体是：

1. 在 HBuilderX 中生成 App 资源，选择“离线打包”相关选项。
2. 使用 DCloud 提供的 Android 离线打包 SDK，把资源放进 Android 工程。
3. 在 Android Studio 中配置签名、包名对应关系。
4. 编译生成 APK。

以上流程涉及较多原生工程细节，且不同版本的 SDK 打包方式有差异，执行时应以 DCloud 官方离线打包文档为准。对于纯前端团队来说，这一步的成本往往被低估，项目排期时要注意预留原生联调时间。

5.5 原生小程序工程化之后，还有必要用跨端框架吗

这个问题经常被拿来讨论。如果团队已经有成熟的原生小程序工程化体系，使用 TypeScript、ESLint、单元测试、CI/CD 构建发布，再引入跨端框架并没有想象中的收益。跨端框架的核心收益是“一端代码多端运行”，如果实际业务就只有微信端，原生的开发和维护体验依然是最直接的。

但反过来，团队一个小程序产品要覆盖微信、支付宝、抖音，或者同时要支撑 H5 端的营销页面，坚持三套原生代码就意味着三倍的开发排期和三倍的 Bug 修复成本。这种情况下，选择 uni-app 或 Taro 的长期收益会大于技术上的额外开销。

6. 性能对比与优化边界

6.1 首次渲染与包体积差异

小程序平台对包体积有严格限制（主包通常限制在 2MB 左右）。微信原生空项目的包体积非常小，只有几 KB 到几十 KB。uni-app 和 Taro 项目因为框架运行时、编译器注入的公共代码，包体积会比同样功能的原生项目大。

• uni-app 空项目编译到微信小程序，包体通常会增加几十 KB 到几百 KB，具体取决于使用的组件和 API。
• Taro 3 由于内置 React 运行时，基础体积相对更大，这也是 Taro 社区优化包体时经常提到的点。

两者都支持分包加载和按需注入，实际生产项目中可以通过合理拆分页面、将非核心页面放入分包、把公共依赖提取到公共 chunk 等方式控制主包体积。

6.2 长列表渲染对比

长列表是两类框架差异最明显的性能场景。

原生小程序的wx:for配合setData更新，需要注意避免全量更新。优化手段包括：

• 把列表拆成子组件，只更新变化项的数据。
• 使用wx:key提高 diff 效率。
• 使用虚拟列表或回收节点的方式控制实际渲染的节点数量。

uni-app 中同样要遵循上面的思路，v-for的 key 必须给，setData的使用还是遵守原生逻辑，避免一次性传入大数组。

Taro 3 的长列表由于有 React diff 这一层，每次状态更新都对组件树做一次协调，列表项数量越多，diff 必然越慢。实际项目中经常要引入虚拟列表方案，Taro 官方提供了VirtualList组件，社区也有@tarojs/components中的虚拟列表，或者自己按滚动位置懒加载。

6.3 减少跨端框架性能损耗的通用手段

无论选择 uni-app 还是 Taro，下面几条性能优化思路都是通用的：

• 减少不必要的页面级setData/setState：状态更新粒度尽量细化到组件级别。
• 避免渲染大数据量：后台分页 + 前端懒加载，前端只维护可视区数据。
• 高频事件手动节流：比如滚动、触摸、输入框实时搜索等场景。
• 静态资源放到 CDN，图片设置合适的宽高，避免图片加载引起的布局抖动。
• 复杂计算不要放在渲染流程里，用computed（Vue）或useMemo（React）做缓存。
• 将纯展示型组件拆出来，避免父组件状态更新导致所有子组件全部重复渲染。

7. 团队成本与选型决策建议

7.1 团队技术栈决定第一优先级

选型首先要看团队里面的人会什么。

• 如果团队主力是 Vue 技术栈，那么 uni-app 的学习成本最低，团队成员可以很快把已有 Vue 组件的样式、结构迁移过来。
• 如果团队主力是 React 技术栈，Taro 的 React 写法接受度会很高，React Hooks 的开发模式可以直接使用。
• 如果团队本来就长期做小程序原生开发，且团队成员对 WXML 的模板语法、setData 的性能约束、小程序生命周期如数家珍，那么没有特别强的理由去切换到跨端框架。

一个残酷的现实是：跨端框架出现的大部分场景，并非技术上的最优解，而是团队“想要一套代码交付多个端”这个业务目标的妥协产物。认清这一点，才不容易在后续的 Bug 排查中被框架限制磨掉耐心。

7.2 多端复用程度评估

选型前先回答几个问题：

• 产品是否必须同时上线微信、支付宝、抖音等多个小程序平台？
• 各平台之间是“完全一致”还是“各自有差异化功能”？
• H5 和 App 是否也在产品路线图内？

如果答案是“只做微信小程序，最多以后试试支付宝”，跨端框架的收益率很低，反而因为平台差异化能力要用条件编译去适配，写起来比原生更别扭。如果答案是“微信 + 支付宝 + 抖音三端同步，每端还要适配平台的登录和支付”，那么用跨端框架统一写业务逻辑，再通过环境判断处理平台差异，效率会高很多。

业务上多端复用程度越高，跨端框架的价值越大。单一平台项目，原生的“直给”优势反而更突出。

7.3 原生能力和第三方 SDK 适配成本

每家平台都有自己的原生能力，例如微信的开放数据域、运动数据、NFC、蓝牙，支付宝的芝麻信用、身份认证，抖音的各种端内能力。这些能力的接入方式和技术规范差异较大。

原生项目中直接调用平台 API 最方便。跨端框架中，如果框架已经封装了同类 API，可以直接使用；如果没封装，通常需要条件编译 + 平台判断 + 调用平台原生方法的方式来实现，这会导致代码的跨端性下降。

对第三方 SDK（如统计、推送、客服、音视频）的支持也要提前调查。很多第三方 SDK 只提供了微信小程序版本或原生 App 版本，直接套用到 uni-app 或 Taro 项目中往往不行。选型前最好把项目计划中用到的第三方服务列出来，逐一查证在对应框架中的接入方式、官方支持程度和社区案例数量。

7.4 长期维护与团队招聘

小程序开发不是一个“写完就结束”的事。上线之后的迭代、Bug 修复、平台升级适配才是长久的维护成本。

原生项目长期维护最大的风险是“知识封闭”，新成员要重新学习小程序平台规则。但小程序平台的规则本身就相对稳定，一旦熟悉后反而很顺畅。

uni-app 项目的维护风险在于随 DCloud 的发展方向波动。DCloud 推出的 uni-app x 等新方向，说明产品路线可能随时调整，对这些商业产品的长期依赖需要评估。Taro 项目则受京东前端团队的开源维护节奏影响，版本升级对项目稳定性的影响也需要团队有人长期跟进社区变化。

招聘维度上，不同技术栈的候选人供给情况差别很大。小程序原生开发的候选人大多来源于业务项目培养；Vue 和 React 候选人基数更大，招到能写 uni-app/Taro 的人更容易一些，但深入掌握框架原理的人占比不高。多数项目需要的并不是框架作者级别的深度，而是能根据报错信息快速定位并在小程序原生机制层面找到解法的人。

8. 实操型选型清单

为了让选型从讨论进入决策状态，建议团队基于下面的清单逐项打分，再结合项目时间与人员情况做最终决定。

表格打分后注意一点：技术选型不能只看当前项目的排期。如果公司未来有统一前端中台的战略，跨端框架的统一收益会放大。如果只是接一个临时外包小程序，且未来大概率不会继续迭代，那么原生开发可能是最干净的交付方式。

9. 三条实战建议与收尾

最后写三条可以直接落地的工程建议。

第一，不要把跨端框架当成万能药。它解决的是多端代码复用问题，而不是解决团队技术能力问题。一个连小程序原生 data 传递和 setData 性能机制都没搞清楚的团队，不管换到 uni-app 还是 Taro，都会在性能和兼容性上反复踩坑。建议无论最终选什么，团队中至少有一两个成员能独立阅读原生小程序编译产物，知道报错发生在哪个环节。

第二，选型阶段一定要做对比 Demo。不仅做页面展示 Demo，更要做网络请求、登录态、列表滚动、条件渲染这些高频率业务场景的 Demo，把三套代码在微信开发者工具里的编译产物都打开看一遍，理解每一行报错来自运行时还是编译期。这个环节花的时间不会白费。

第三，发现框架解决不了的问题时，果断使用条件编译兜底。uni-app 的条件编译可以用#ifdef标记，Taro 可以用process.env.TARO_ENV做环境判断，必要时直接写原生小程序代码。跨端框架的价值是提高效率，但不要让框架的抽象边界绑架业务。关键路径上，直接调用原生能力写一点平台专属代码，比绕来绕去维护一个“看起来跨端但哪端都跑不顺”的抽象更明智。

小程序开发技术的迭代速度不慢，今天基于 Vue 3 的 uni-app 和基于 React 的 Taro 3，明天可能就会被新的框架方案冲击。与其纠结“哪个一定最好”，不如回到你自己的项目约束里回答：你的目标平台是哪些？团队会什么？性能红线在哪里？维护周期有多长？这三个问题有了明确答案，框架选择基本就出来了。