选跨端方案时，“团队会 React 还是 Vue”只是条件之一。更早的问题是用户从哪里进入、需要哪些系统能力、是否愿意安装，以及产品如何分发。一个扫码即用的服务和一个长期使用的原生工具，往往应该采用不同入口。本文以微信小程序为主要小程序场景，其他平台需分别核对能力。
小程序有自己的运行边界
微信小程序的逻辑层与视图层分工、页面生命周期、组件体系和平台 API，都不等同于普通网页。不能假设 window、DOM 操作或浏览器库可以直接运行。原生开发使用 WXML、WXSS 和页面逻辑，跨端框架负责把部分上层表达适配到目标环境。
原生小程序通过 setData 更新视图相关数据。传输不必要的大对象、在高频事件里更新整页状态，都会增加成本。让一次操作只更新必要字段，长列表分页加载；使用框架时也要检查它最终产生的更新行为。
登录需要服务端交换身份
小程序调用 wx.login 获取临时 code
→ 发送 code 到自己的后端
→ 后端调用平台接口交换身份信息
→ 后端签发自己的会话
→ 后续业务请求由后端校验会话与资源权限
应用密钥与平台会话密钥不能下发给客户端。平台用户标识也不是可以直接信任的请求参数；后端应从已经验证的会话恢复用户身份。业务登录、手机号授权和用户资料授权是不同流程，不要在产品文案里合并为一次“授权全部”。
把方案放在同一张表里
| 方案 | 常见适用场景 | 需要承担的成本 |
|---|---|---|
| Web / H5 | 链接分享、搜索访问、快速交付 | 浏览器能力与体验边界 |
| 原生小程序 | 深入单一平台、扫码和社交入口 | 平台组件、审核与限制 |
| Taro | React 团队评估多端交付 | 目标端支持差异、编译适配与插件兼容 |
| uni-app | Vue 团队评估多端交付 | 各端能力差异、原生插件和构建链路 |
| React Native | 需要原生 App 体验与能力 | 原生工程、签名、商店分发和真机验证 |
这些是选型倾向，不是框架能力的完整清单。选定版本后，应逐项核对目标端支持，不能把“支持多端”理解为任意依赖和页面都无需修改。
共享业务，给平台留接口
订单计算、校验规则和接口类型适合放到共享包。登录、存储、支付、文件选择和导航则通过平台适配层实现。例如业务调用 choosePhoto，Web 用文件选择器，小程序用平台媒体 API，RN 用原生模块；返回统一结果，同时保留取消和失败语义。
不要用一个布尔值抹平能力差异。某个平台只支持压缩图、另一个可以读取原图时，接口应明确返回文件信息，让业务决定后续行为。
用最难的一页做验证
做一个包含登录、长列表、照片选择、上传和返回恢复的样板页，在目标平台真机运行。记录首屏、滚动、授权拒绝、弱网和后台恢复表现。它比展示同一份“Hello World”编译到三个平台更能说明迁移成本。
小程序上线还要核对服务器域名、HTTPS、隐私声明与平台审核要求；具体限制以当前平台文档为准。完成本地预览不等于通过真机能力验证，更不等于审核发布。
继续阅读：React Native、Monorepo、Vue 组合式函数。