小程序开发框架选型指南

做小程序这些年，被问得最多的问题之一就是：到底该用原生写，还是上框架？这个问题没有标准答案，但有一套可以复用的判断逻辑。这篇文章把我自己在项目里踩过的经验整理成一套选型方法，供你参考。

一、先搞清楚框架解决了什么问题

微信小程序原生开发用的是 WXML + WXSS + JS/TS 这一套，逻辑清晰、官方支持最全。但它的短板也很明显：

• 只能跑在微信里，想上支付宝、抖音、H5 就得重写一遍；
• 工程化能力弱，组件复用、状态管理、构建流程都要自己搭；
• 多端 UI 差异需要手工适配。

框架的价值就是把这些重复劳动抽象掉。主流方案大致分三类：

• 编译型跨端框架：Taro、uni-app。用 React/Vue 语法写一套代码，编译成各平台的小程序或 H5。
• 运行时框架：如 Remax、kbone，把 Web 运行时塞进小程序，适合已有 Web 项目快速迁移。
• 原生增强方案：在原生基础上引入 TypeScript、组件库、状态管理，不改变运行模型。

二、按项目类型选，而不是按流行度选

1. 只做微信、追求稳定和性能

优先原生 + TypeScript。微信官方的 Skyline 渲染引擎、分包、按需注入这些能力，原生支持最及时。工具链上配好 ESLint、Prettier、miniprogram-api-typings，体验并不差。

2. 需要多端覆盖

Taro 和 uni-app 是主流。选型时重点看两点：团队现有技术栈，以及目标平台的覆盖度。团队熟 Vue 就 uni-app，熟 React 就 Taro，学习成本最低。注意跨端框架的坑集中在平台 API 差异和原生组件上，业务里要预留适配层。

// Taro 中按平台做条件编译
// #ifdef WEAPP
const pay = () => Taro.requestPayment({ ... })
// #endif
// #ifdef H5
const pay = () => window.location.href = "/pay"
// #endif

3. 已有 Web 项目要快速上小程序

考虑 kbone 或 Remax 这类运行时方案，改造成本低，但包体积和首屏性能要提前评估，复杂交互页面容易掉帧。

三、几个容易忽略的决策点

• 包体积：主包 2MB 是硬限制。跨端框架会带入运行时，务必用分包和依赖分析工具控制体积。
• 云开发：如果后端人手紧张，微信云开发能省掉服务器和运维，适合 MVP 和中小项目；但复杂业务、需要多端共享后端时，还是自建服务更稳妥。
• 长期维护：框架版本升级、社区活跃度、官方文档质量，都会影响两三年后的维护成本。选之前看一眼最近半年的 issue 和 release 频率。
• 开发成本：跨端框架前期省人力，但适配和调试的隐性成本不低。项目只有微信一端时，上框架反而可能增加复杂度。

四、我的默认建议

如果是新项目、只做微信：原生 + TS，配一套好用的组件库，先把业务跑通。如果明确要多端：Taro 或 uni-app，从第一天就建立平台差异适配层，别等到上线前才补。如果团队小、后端弱：微信云开发起步，把精力放在产品验证上。

框架只是工具，选型的核心是匹配团队能力和业务边界。能用一个团队熟悉的方案把需求稳定交付，比追新更重要。

最后提醒一句：无论选哪种框架，小程序上线前的性能优化、包体积控制、审核规范这几件事都绕不开，框架帮不了你，得靠工程习惯。