企业官网建设流程全解析

1. 项目概述：从一次小程序项目重构说起

去年年中我接手了一个运营了大半年的微信小程序项目，第一件事就是看它的代码结构。结果一句话总结：页面目录下一堆.js文件，公共逻辑散落在各个页面里，请求层没有封装，每个页面自己拼 URL。更要命的是，原始开发团队用的是原生框架，但分包、组件化、状态管理这些本该在项目启动时就定好的架构决策，全都缺位了——业务跑得越快，代码腐化得越厉害。

这个项目让我下决心梳理一份关于微信小程序开发框架的完整选型和架构笔记。所谓“框架”，在微信小程序语境下有两层含义：一层是开发框架——原生的WXML/WXSS/JS体系，以及Taro、uni-app、mpvue这类编译型跨端框架；另一层是项目架构——目录分层、组件设计、状态管理、请求封装、分包策略这些工程化决策。两层缺一不可，前者决定你怎么写代码，后者决定你能写多久。

这篇内容适合三类人：准备从零启动小程序的新手团队——需要一次选型避免日后返工；正在痛恨现有代码混乱的维护者——可以参考我的架构拆分思路；想从原生迁移到跨端框架的负责人——我会给出真实的迁移成本和踩坑记录。

每类读者都能从这里拿到直接可用的东西：架构图、目录模板、框架对比表、以及我在真实项目中遇到的坑和排查套路。接下来我从架构思路开始讲，再逐一切入主流框架对比、工程化实操和问题排查。

2. 架构设计：别急着写代码，先回答四个问题

2.1 决定架构好坏的四个前置问题

很多团队拿到需求就开干，页面写完一大半才意识到：登录态怎么统一处理？每个页面都写wx.request不累吗？公共组件放哪儿？代码越来越多之后，WXML 里业务逻辑和展示逻辑搅在一起怎么办？

我总结的架构设计四问如下：

第一问：小程序生命周期内的运行环境是什么？微信小程序跑在双线程环境，逻辑层（App Service）和视图层（WebView）分离，通信通过 JSBridge。这意味着你的架构必须避免在视图层做重的逻辑计算，同时要关心setData的通信成本——不是简单的 JS 对象赋值，而是跨线程的消息传递，频繁大流量 setData 会成为卡顿元凶。

第二问：业务体量和迭代速度如何？如果只是几十个页面的工具类小程序，原生轻量方案足够；如果是中大型电商、社区产品，需要引入状态管理、数据层抽象、组件库，甚至考虑跨端复用。架构永远是为业务扩张方式服务的，不能为了技术炫技把简单项目搞复杂。

第三问：团队技术栈积累在哪？Vue 技能强的团队选 uni-app 上手极快，React 背景的选 Taro 沟通成本最低。这个问题直接影响后续招聘、培训和代码维护效率。

第四问：需要覆盖哪些平台？只做微信，原生或 Taro 都行；需要同时输出支付宝、百度、抖音小程序以及 H5，uni-app 的多端编译能力更占优势。

这四个问题的答案，决定了你走原生、跨端框架、还是混合方案。强力建议启动前召开一次技术评审会，哪怕只是半小时，也比项目做到一半发现架构选错了强。

2.2 原生架构 vs 跨端框架的本质区别

原生小程序开发的代码是.wxml + .wxss + .js + .json四件套，直接运行在微信开发者工具提供的编译链路里。它的优势很直接：没有中间编译层，调试直观，新 API 支持最快。但短板也很明显：不能在浏览器里直接跑，无法复用 Web 生态的代码，而且没有传统意义上组件化开发的工程化底座——虽然有 Component 构造器，但大型项目的状态共享、路由管理还是得自己造轮子。

跨端框架如 Taro、uni-app 走的则是“写一套代码，编译到多端”的路线。你在 React/Vue 的语法体系里写页面，通过 Babel/Webpack 编译链把代码转换成各平台可运行的文件。核心价值不是绕过原生，而是解决代码复用、组件化、状态管理和现代前端开发体验的问题。

这两种路线不是对立关系。实际上，Taro 编译出来的产物仍然是原生小程序代码，跨端框架的 runtime 只是在原生能力之上做了一层抽象和运行时适配。所以我一直主张：无论选哪种，都必须先懂原生运行机制，否则遇到编译解决不了的疑难杂症会束手无策。

2.3 成熟项目架构分层参考

这里给出一份我经过多次实战验证的分层架构模板，它适合中大型项目，也适合从第一天就有扩张预期的项目：

• 视图层：页面目录 + 组件目录，只处理展示和用户交互，不直接请求数据
• 应用逻辑层：services 目录统一封装 API 调用，stores 目录管理全局状态，utils 目录放纯函数工具
• 基础能力层：request 封装、登录态管理、缓存策略、埋点上报、错误监控
• 配置层：环境配置（开发/测试/生产）、路由表、常量定义

对应到目录结构，通常长这样：

project-root/ ├── app.js # 入口逻辑，全局生命周期 ├── app.json # 全局配置（页面路由、window、tabBar） ├── app.wxss # 全局样式 ├── pages/ # 页面目录（按业务模块分组） │ ├── index/ │ ├── user/ │ └── order/ ├── components/ # 通用组件 │ ├── navbar/ │ ├── product-card/ │ └── empty-state/ ├── services/ # 接口请求层 │ ├── request.js # 封装 wx.request，拦截器 │ ├── user.js │ └── order.js ├── stores/ # 全局状态管理 ├── utils/ # 纯函数、工具方法 │ ├── format.js │ └── storage.js ├── assets/ # 静态资源 └── config/ # 环境区分配置

这套结构的核心思想是“单向依赖”：视图层依赖应用逻辑层，应用逻辑层依赖基础能力层，各层之间不反向调用。这样做的收益非常明显——替换底层 API 或增加新业务模块时，不会引发连锁修改。

3. 主流开发框架横向对比：Taro、uni-app、原生到底怎么选

先给结论：没有绝对最优的框架，只有最适合当前团队的框架。下面是主流方案的详细对比分析。

3.1 原生小程序开发框架

原生框架的优势体现在：零依赖、调试链路最短、官方能力同步最及时。微信每次更新新能力（比如新的组件、新的 API），原生写法永远最先支持。而且原生开发的包体积控制最精准——你写了什么，就打包什么，不存在编译时注入的 runtime 冗余。

劣势同样明显：开发效率相对低。没有热更新、没有组件库生态、没有成熟的 CLI 工具链。写复杂交互时，WXML 的数据绑定语法比 Vue/React 的模板语法简陋得多；状态管理需要自行引入 MobX 或 Redux 的小程序适配版本。在团队没有框架负担、产品复杂度可控的前提下，原生依然是不错的起点。

不过我认为现在纯原生启动一个新项目，至少要满足三个条件之一：产品极简单（不超过20个页面）、团队对原生机制已积累深厚、业务对性能和稳定性有极致要求（比如低门槛机型的流畅度）。

3.2 Taro：React 语法 + 多端编译

Taro 3.x 是完全基于 React 语法体系的跨端框架，支持 React Hooks，代码通过编译转换输出到微信、支付宝、H5 等平台。它的核心优势是：如果你是 React 技术栈团队，Taro 的学习成本几乎为零。且因为底层是 React 的运行机制，逻辑复用可以通过 Hooks 实现得比较优雅。社区活跃度、npm 生态和第三方库的适配都算跨端框架里最成熟的。

需要注意的点是：

• Taro 编译后的产物比手写原生多一层 runtime，对性能敏感的场景需要额外调优
• 部分原生 API 或特殊组件不支持跨端，需要写条件编译代码，实际上做不到“一套代码完全通用”
• 团队如果没人懂编译原理，排查奇怪问题时容易陷入“是不是框架 bug”的猜疑

用 Taro 做一个标准的电商小程序，最理想的分工方式是页面业务代码全在 Taro 层，底层原生能力通过 Taro 提供的 API 或自定义原生组件混写。

3.3 uni-app：Vue 语法 + 多端发布

uni-app 是 Vue 语法体系的跨端框架，支持编译到微信小程序、App、H5、各种小程序平台。它的最大卖点是“一次编写，多端发布”，而且在 Vue 开发者群体里认可度极高。DCloud 官方生态完善，插件市场有大量现成组件和模板，拿来即用的概率很高。

从工程实践看，uni-app 的上手曲线确实平缓，但对编译细节的控制力比 Taro 弱一些。在微信小程序端运行时，部分 CSS 效果和特殊 API 需要平台判断；尤其涉及地图、蓝牙、视频流等原生能力时，条件编译代码会很常见。关于这些细节，我在后面的实操部分会展示具体写法。

性能方面，uni-app 的 Vue runtime 也有一定开销。实测同一个复杂列表页面，uni-app 编译产物体积通常比原生大 30% 左右，首屏渲染时间也会略长。对于以微信小程序为主要阵地、又要兼顾 H5 的团队，uni-app 是性价比很高的选择。

3.4 mpvue、Remax 与其他方案简述

mpvue 是美团开源的 Vue 小程序框架，曾经火过一阵，但目前基本处于维护停滞状态，新项目不建议选用。Remax 是支付宝开源的使用 React 语法的跨端框架，通过运行时渲染到小程序原生组件树，思路很前卫，但社区规模和成熟度不如 Taro。Kbone 是腾讯官方提供的 Web 代码转小程序方案，适合已有 H5 页面需要快速小程序化的场景，但它更多是“移植”而非“跨端开发”，性能表现需要慎重评估。

选型建议一句话总结：

• 微信生态 + 性能优先 + 团队懂原生：原生开发
• React 技术栈 + 多端诉求：Taro 3.x
• Vue 技术栈 + 多端诉求 + 快速出活：uni-app
• No 跨端诉求 + 快速验证：原生或 uni-app 均可，看团队熟悉度

3.5 框架优劣对比速查表

4. 工程化落地实操：从项目初始化到发布全流程

4.1 项目初始化与依赖安装

以 Taro 3.x 为例，初始化项目的命令是：

# 使用 Taro CLI 初始化项目 taro init my-mini-app # 进入项目目录 cd my-mini-app # 安装依赖 npm install # 启动微信小程序编译 npm run dev:weapp

如果用 uni-app，通过 HBuilderX 可视化创建，或者用 CLI 方式：

# 创建 uni-app 项目 npx degit dcloudio/uni-preset-vue#vite my-vue3-project # 进入目录并安装依赖 cd my-vue3-project npm install # 运行到微信小程序 npm run dev:mp-weixin

这里分享一个关键经验：项目初始化时必须顺手配置miniprogramRoot。Taro 和 uni-app 默认编译产物输出到dist目录，但微信开发者工具默认读取项目根目录。需要在project.config.json中指定编译输出目录：

{ "miniprogramRoot": "dist/dev/weapp", "projectname": "my-mini-app", "setting": { "urlCheck": false, "es6": true, "enhance": true, "postcss": true, "minified": true } }

这一步不做，开发工具里根本加载不到代码。我第一次用 Taro 时在这上面卡了二十分钟，一直怀疑是不是安装失败了。设置好之后，开发工具里就能实时看到编译结果。

4.2 页面列表加载更多功能的完整实现

从热搜词里看到“页面列表加载更多”，这几乎是每个小程序都要面对的高频需求。以原生框架为例，最稳妥的做法是在页面的onReachBottom钩子函数里触发加载逻辑：

// pages/list/list.js const DEFAULT_PAGE_SIZE = 10 Page({ data: { list: [], pageNo: 1, pageSize: DEFAULT_PAGE_SIZE, hasMore: true, loading: false, isFirstLoad: true }, onLoad() { this.loadList(true) }, // 页面滚动到底部时触发 onReachBottom() { if (this.data.hasMore && !this.data.loading) { this.loadMore() } }, // 下拉刷新时触发 onPullDownRefresh() { this.loadList(true).finally(() => { wx.stopPullDownRefresh() }) }, async loadList(reset = false) { if (this.data.loading) return this.setData({ loading: true }) const pageNo = reset ? 1 : this.data.pageNo + 1 try { const res = await request({ url: '/api/list', data: { pageNo, pageSize: this.data.pageSize } }) const list = reset ? res.list : this.data.list.concat(res.list) this.setData({ list, pageNo, hasMore: res.list.length >= this.data.pageSize }) } catch (e) { wx.showToast({ title: '加载失败，请稍后重试', icon: 'none' }) } finally { this.setData({ loading: false, isFirstLoad: false }) } }, loadMore() { this.loadList() } })

这段代码里藏着几个关键细节：

第一，loading标记必须加。小程序的onReachBottom触发频率取决于滚动速度，没有防重逻辑，页面会同时发出多个重复请求。这是新手最容易犯的错。

第二，总条数判断不要用total字段。后端接口往往返回total，但前端分页滚动加载时，用“当前页返回条数是否等于分页大小”来判断是否还有更多，逻辑更简单也更可靠——不用额外请求一次才能知道还有没有下一页。

第三，concat 比 push 更安全。直接this.data.list.push(...res.list)虽然代码更少，但可能触发 setData 时引用同一块内存导致渲染异常。先构造新数组再整体 setData，性能上也是更好的选择。

在 Taro/uni-app 中对应实现是useReachBottom/onReachBottom（组合式 API），思路完全一致，只是把数据更新方式换成useState或ref。但有一点必须提醒：跨端框架下的列表分页要特别关注内存，长列表数据无限累加会导致页面卡顿，需要引入虚拟列表或分页截断策略。

4.3 顶部导航栏高度适配方案

热搜词里出现“微信小程序顶部导航栏高度”，这也是典型的坑。小程序导航栏分为原生导航栏和自定义导航栏两种模式。原生导航栏由系统渲染，在不同机型上高度不同：iPhone X 及以上带刘海，状态栏高度约 44px；普通机型约 20px。如果用wx.navigateTo跳转，原生导航栏会自动适配，不需要开发者关心。

问题出在自定义导航栏场景——很多电商和内容类小程序为了视觉统一，会在页面 json 中配置"navigationStyle": "custom"，此时状态栏到页面顶部的距离需要自己计算：

// utils/system.js function getNavBarInfo() { const systemInfo = wx.getSystemInfoSync() const menuButtonInfo = wx.getMenuButtonBoundingClientRect() // 状态栏高度，单位 px const statusBarHeight = systemInfo.statusBarHeight || 20 // 胶囊按钮高度通常是 32px，导航栏高度 = 胶囊按钮高度 + 上下留白 const navBarHeight = (menuButtonInfo.top - statusBarHeight) * 2 + menuButtonInfo.height return { statusBarHeight, navBarHeight, // 总高度 = 状态栏 + 导航栏 totalHeight: statusBarHeight + navBarHeight } }

核心原理就是通过wx.getMenuButtonBoundingClientRect()拿到右上角胶囊按钮的位置信息，再结合状态栏高度反推导航栏高度。不同机型上胶囊按钮的垂直位置会自适应，所以用这个方法可以稳妥地算出导航栏真实高度。CSS 中记得用px而不是rpx，因为这是基于物理像素的计算结果。

在 Taro 中可以通过Taro.getMenuButtonBoundingClientRect()拿到同样信息；在 uni-app 中则走uni.getMenuButtonBoundingClientRect()。逻辑完全一致，只是 API 前缀不同。

4.4 数据请求层封装与登录态管理

无论选哪个框架，数据请求层都值得一开始就做好。我的封装模块长这样：

// services/request.js const BASE_URL = config.baseUrl function request({ url, method = 'GET', data = {}, needAuth = true, retryCount = 0 }) { return new Promise((resolve, reject) => { const header = { 'Content-Type': 'application/json' } const token = getToken() if (needAuth && token) { header['Authorization'] = `Bearer ${token}` } wx.request({ url: `${BASE_URL}${url}`, method, data, header, success: (res) => { // 统一处理 HTTP 状态码 if (res.statusCode === 401) { // token 过期，重新登录 handleTokenExpired() reject(new Error('登录已过期')) return } // 业务状态码判断 if (res.data && res.data.code === 0) { resolve(res.data.data) } else { wx.showToast({ title: res.data.msg || '请求失败', icon: 'none' }) reject(new Error(res.data.msg)) } }, fail: (err) => { // 网络错误，支持一次重试 if (retryCount < 1 && !isNetworkErrorHandled) { retryRequest(url, method, data, needAuth, retryCount + 1) } else { wx.showToast({ title: '网络异常，请检查网络', icon: 'none' }) reject(err) } } }) }) }

关于登录态，微信小程序最常用的方案是wx.login()获取临时 code，后端用 code 换 openid 并生成自定义登录态。这里有两个经验值得分享：

第一，token 存储务必用wx.setStorageSync，但要封装一层过期管理。不能只存字符串，至少要存{ token, expireAt }的结构体，请求前检查过期时间。

第二，401 后的重新登录不能简单地跳转登录页。电商类小程序从分享链接点进来时，用户可能在未登录状态下浏览了很多页面，突然因为一个接口 401 就强制弹登录页，转化率损失很大。更合理的做法是：静默尝试刷新 token，失败后再引导登录。

4.5 分包加载与包体积控制

“uniapp 微信小程序打包 source size 2612kb exceed max limit 2mb”这个热搜词我太有共鸣了——微信小程序主包上限 2MB，超过就无法上传。第一次遇到这个报错时，项目还没交付，所有页面都堆在主包里，一编译就爆红。

解决方案是分包加载。微信小程序支持把页面拆分成主包和分包：主包只放公共代码、tabBar 页面和核心页面，分包按业务模块划分，小程序启动时只下载主包，用户访问到分包页面时才按需下载。

在 app.json 中配置：

{ "pages": [ "pages/index/index", "pages/user/user" ], "subPackages": [ { "root": "packageA", "pages": [ "pages/product/detail", "pages/order/list" ] }, { "root": "packageB", "pages": [ "pages/activity/coupon" ] } ], "preloadRule": { "pages/index/index": { "network": "all", "packages": ["packageA"] } } }

几个关键策略：

• tabBar 页面必须在主包里，这是微信的硬性规定
• 公共组件不能放在分包里，只能放主包；如果有多个分包共用组件，就得提升到主包
• 分包之间不能互相跳转，需要通过主包中转或者使用wx.navigateTo到主包页面再转发
• 预加载规则preloadRule很有效：进入主包首页后提前静默下载分包，用户点击分包页面时几乎无感知

按这个方案调整后，我的项目主包体积降到 1.6MB，分包最大 800KB，顺利过审。

4.6 抓包调试：Charle s 配置全流程

移动端小程序调试，实际上经常需要在 PC 端抓包看请求详情。最常用的工具是 Charles，配置流程如下：

1. 安装 Charles 并启动
2. 配置 SSL 代理：Proxy -> SSL Proxying Settings，勾选启用，添加*通配符
3. 手机和电脑连接到同一 Wi-Fi
4. 手机 Wi-Fi 设置 HTTP 代理为电脑 IP + 8888 端口
5. 手机浏览器访问chls.pro/ssl下载并安装 Charles 根证书
6. 在 Charles 的Proxy -> Access Control Settings中允许局域网访问

完成以上配置后，手机上的小程序请求就会显示在 Charles 的 Structure 或 Sequence 列表中。有一个坑要提醒：微信开发者工具自带 Network 面板已经足够日常调试，只有需要查看加密请求、修改请求参数模拟异常场景时，才需要爬到 Charles 这一层。如果是调试真机上的小程序，直接在开发者工具里开启“真机调试”模式更高效。

5. 常见问题与排查技巧实录

5.1 常见错误码与处理方案

10002 错误码有细分类，和权限相关比较多，我实际最常遇到的是与用户 openid 获取相关。排查时先用wx.login手动调用一次，看返回信息是否正常；再检查请求头中的 token 是否正确传递。如果是后端解密问题，常见原因是session_key过期，重新登录即可解决。将错误信息搜集沉淀成团队内部文档，对新人排查问题能省很多时间。

5.2 小程序在开发者工具里黑屏/白屏的排查

真机和模拟器表现不一致是跨端框架最磨人的问题。常见的白屏原因：

• 编译产物不完整：Taro/uni-app 编译时 console 报错，但产物已部分生成。先清空 dist 目录，重新编译
• ES6+ 语法不兼容：低版本基础库不支持某些新语法，检查项目里是否用了可选链或空值合并，必要时配置 Babel 降级
• CSS 兼容问题：某些 CSS 属性在部分 iOS 版本上不支持，导致页面渲染异常但无 JS 报错。排查路线是二分注释法——批量注释部分样式代码，缩小问题范围

我在真机白屏的场景中，最高频的原因是分包路径配置错误。开发者工具有时能自动修正，但真机不会。检查app.json的subPackages配置是否与pages里的路径重复，或者某个页面路径写到了不存在的文件中。

5.3 微信开发者工具其他常见问题

开发者工具本身也常常出幺蛾子，简单列几个我亲眼见过的问题和解决方式：

• 导入项目后页面空白：清除项目缓存：开发者工具菜单栏工具 -> 清除缓存 -> 全部清除，然后重新编译
• 真机预览时提示版本过低：在开发者工具详情 -> 本地设置中调整调试基础库版本；如果用户手机微信版本过旧，需要在后台设置最低基础库版本
• 多人协作代码冲突：微信开发者工具默认没有代码合并能力，必须配合 Git；在project.config.json中配置"ignoreDevUnusedFiles": false之类的选项能减少文件误删

5.4 如何发给别人试用并收集反馈

热搜词里还有“微信小程序怎么发给其他人试用收集几天的试用反馈”，这里一并解答。常用路径是：

1. 预览二维码：开发者工具点击“预览”，会生成一个二维码，有效期约 25 分钟，适合快速给同事看一眼
2. 体验版：在微信公众平台后台版本管理 -> 开发版本 -> 选为体验版，设置体验成员后，成员通过小程序码或分享链接进入。体验版长期有效，是收集反馈的主阵地
3. 测试号：如果不方便注册正式 AppID，可以申请测试号，但部分能力（如支付、订阅消息）不可用

反馈收集方面，除了让体验者口头反馈，强烈建议在项目里埋一个轻量的反馈入口：固定一个页面或按钮，调用wx.showModal收集用户文字描述，连同当前页面路径和基础库版本一起提交到后端。这样比微信聊天里东一句西一句的反馈高效得多。

6. 关键工具链与调试技巧补充

6.1 微信开发者工具的高效用法

工欲善其事必先利其器。微信开发者工具远不止是写代码和编译的窗口，以下功能值得深挖：

• 真机调试：在工具顶部点击“真机调试”，手机会打开一个调试模式，能看到 Console 日志、网络请求和页面对应的 DOM 树。这个方法比电脑端模拟器更接近真实性能表现
• 性能面板：工具自带性能分析面板，能显示页面加载时间、setData 调用频率、脚本执行耗时。我在做复杂列表优化时，全靠这个面板定位到哪个组件 setData 太频繁
• 代码覆盖率：开发者工具支持记录代码执行覆盖率，帮助找到从未被执行的冗余代码，对瘦身很有帮助
• 多账号调试：同一台电脑可以添加多个微信账号，方便测试不同登录态下的页面表现

6.2 移动端抓包与网络调试手段

真机调试模式下，wx.request的全部请求已显示在开发者工具的 Network 面板中。但真机预览、体验版阶段无法连开发者工具时，就需要外部抓包工具了。除了前面讲到的 Charles，Fiddler 和 whistle 也是常用选择。whistle 作为 Node 生态的抓包调试工具，支持规则配置和 HTTPS 解密，对前端更友好。不过要提醒的是，抓包时务必遵守用户隐私和数据安全规范，不要采集敏感信息。

6.3 组件的设计与封装原则

中大型小程序的组件体系是架构质量的分水岭。我在项目中沉淀了几个原则：

第一，组件只做展示，不做请求。数据由页面传入，事件由页面处理。这样组件的复用范围最大，也最容易测试。

第二，复杂组件必须考虑数据不可变。属性对象如果被组件内部修改，在 setData 时会引发页面 diff 的不确定性，排查起来很痛苦。

第三，微信自定义组件的relations能力值得利用。父子组件之间可以用relations建立联动，例如一个表单组件内部包含多个输入项，父表单组件可以统一校验逻辑。

第四，组件的样式隔离是默认开启的。如果希望外部样式影响组件内部，需要在 options 中配置styleIsolation: 'apply-shared'。很多团队在开发组件库时被这个默认行为坑过。

6.4 蓝牙定位等特殊场景的开发提示

热搜词里提到了“微信小程序蓝牙定位”，这里补充说明一下。蓝牙相关 API 在原生和跨端框架中的表现存在差异：

// 原生蓝牙初始化 wx.openBluetoothAdapter({ success: () => { wx.startBluetoothDevicesDiscovery({ services: [], allowDuplicatesKey: false, success: () => { // 开始监听新设备 wx.onBluetoothDeviceFound((res) => { console.log('found device', res.devices) }) } }) }, fail: (err) => { console.error('蓝牙初始化失败', err) } })

蓝牙和定位是典型的原生能力深度依赖场景。Taro 和 uni-app 虽然对蓝牙 API 做了封装，但遇到特殊机型兼容问题时，还是要回到原生方式排查。我一个做智能硬件配套小程序的朋友，就在 uni-app 中用条件编译写了原生蓝牙代码，才解决了某安卓机型的偶发连接失败问题。

7. 我的选型建议与经验总结

翻来覆去讲了很多，最后结合这几年踩过的坑，提炼几条带主观色彩的建议。

如果你的团队是两三个人的小团队，产品逻辑不复杂，以内容展示为主，原生是最好的选择。不需要纠结跨端复用，不需要折腾编译链，把精力全部放在页面体验上。微信开发者工具的原生调试体验，依然是目前所有小程序开发路径中最顺滑的。

如果团队规模中等，有明确的多端规划，且主要技术栈是 Vue，uni-app 会是效率最高的方案。它的插件市场能省下大量“轮子时间”，社区案例也多，遇到问题能搜到很多现成答案。代价是性能上限相对原生低一些，但大多数业务场景感受不到差异。

如果团队是 React 背景，且多端诉求强，Taro 是更融洽的选择。不过要提前做好心理建设——Taro 的编译体系比 uni-app 复杂，报错信息有时晦涩难懂，需要一个懂编译链的人坐镇。

如果项目涉及大量原生能力——蓝牙、NFC、复杂地图交互、实时音视频——优先考虑原生，或者用混合开发方案，把原生模块做成自定义组件嵌入跨端框架。一方面跨端框架对这类能力的适配总有滞后，另一方面排查问题的路径更短。

我在做架构选型时，喜欢把团队成员拉到一起花半天时间做个技术预研：每个候选人用框架写一个包含列表加载、登录态、组件化的小 demo，内部评审时互相 review。方案文档写得再漂亮，不如真正动手写几十行代码来得直观。最后投票决定，比某一个人拍脑袋定的方案要好落地。

技术选型没有标准答案，但有一个标准原则：选团队能长期驾驭的，而不是看起来最潮流的。架构和框架的终极目标不是炫技，而是让产品迭代更稳定、更快速。这句话，是我从一次次重构学到的最深刻的经验。