聊透小程序开发框架：别急着上uni-app

上周有个做餐饮 SaaS 的朋友找我，说他们小程序要重构，技术选型吵了两天。一派要上 uni-app，一派坚持原生。我问他现在遇到什么问题，他说：卡，列表滑到 200 条就掉帧。我说那先别吵框架，先看看你这 200 条是不是一次性渲染的。后来一查，果然。框架背了锅。

这种事我见得太多。很多人把「框架」当成万能药，觉得换个框架就能解决性能、效率、多端问题。实际上框架只解决它该解决的问题，剩下的还得靠人。

先把「框架」这个词拆开

小程序开发框架大致分三层，很多人混着说：

• 宿主框架：微信、支付宝、抖音各自那套运行时和 DSL。你写的 wxml、axml 本质上是各家自己的模板语法，底层是双线程架构——逻辑层跑 JS，渲染层跑 WebView 或原生渲染。
• 跨端框架：uni-app、Taro、Remax 这类，用 Vue 或 React 写一套，编译成各家小程序代码，甚至能出 H5 和 App。
• 工程化框架：原生项目里引入的构建、状态管理、组件库，比如用 webpack/vite 打包、用 MobX 管状态。

选型时先问自己：我是只做微信一家，还是要铺三四个平台？只做一家，跨端框架的编译层就是纯成本；要铺多端，自己维护多套代码的代价通常比学一个框架高。

原生不是落后，跨端不是银弹

原生开发最大的好处是「所见即所得」——文档怎么写，你就怎么调，出了问题查官方社区准没错。新能力（比如微信的 Skyline 渲染引擎、分包异步化）原生总是第一时间支持，跨端框架往往要等社区适配，短则几周，长则几个月。

跨端框架的甜头在于复用。我有个做工具类产品的客户，一套 Taro 代码同时出微信、支付宝、H5 三个端，人力省了一半。但代价也真实存在：调试链路变长，报错栈指向编译产物，得开 sourcemap 才能看；某些平台特有的 API 要写条件编译，写多了代码里全是 #ifdef，比维护两套还难受。

我的经验判断：

• 业务重交互、强依赖平台新能力、团队小只想快速上线——原生优先。
• 多端是硬需求、UI 一致性要求高、团队本来就会 Vue/React——跨端框架值得上。
• 已有原生项目想渐进迁移——别整体重写，先抽公共逻辑层，页面逐個换。

一个容易被忽略的性能点

不管用哪个框架，setData 都是绕不开的坎。逻辑层和渲染层通信是有成本的，数据量越大越明显。下面这段是常见的错误写法：

// 错误：每次只改一个字段，却把整个大对象传过去
this.setData({ list: this.data.list })

// 正确：只传变化的路径
this.setData({
  'list[3].status': 1
})

还有长列表，别指望框架帮你做虚拟列表。200 条以上就该考虑分页或者用 recycle-view 这类方案。我那个餐饮朋友的问题，改成每次渲染 20 条、滚动加载，帧率立刻回来了，跟框架一点关系没有。

选型清单，照着问一遍

1. 目标平台到底是哪几个？未来一年会不会加？
2. 团队现有技术栈是什么？学新框架的成本算进去没有？
3. 有没有必须用的平台新特性？跨端框架支持了吗？
4. 出问题的时候，你能接受等社区修，还是必须自己啃源码？
5. 构建产物体积、首屏时间，有没有实测过？

框架是工具，不是信仰。我见过用原生写得一团糟的项目，也见过用 uni-app 跑得很稳的产品。真正决定质量的，是你对小程序双线程模型的理解、对数据流的控制、对边界情况的处理。选型前多花两天做个小 demo 压测一下，比在网上看十篇对比文章管用。