一套代码跑五端：多端App开发的取舍

多端App开发这件事，真正难的不是“能不能跑起来”，而是“跑起来之后还愿不愿意维护”。选框架的时候大家看的是编译产物，上线半年后决定成败的却是构建链路、原生能力和团队习惯。下面按我自己的项目经验，把几个关键取舍讲清楚。

先想清楚“多端”到底指哪几端

很多人说多端，其实指的东西差别很大：

• iOS + Android：最经典的跨平台，重点在原生能力与包体积。
• App + 小程序：重点在两端生命周期和登录体系不同，业务代码复用价值高。
• App + 小程序 + H5：再加一个浏览器环境，路由、存储、支付差异成倍增加。
• 桌面端：Electron 或 Tauri，和移动端复用 UI 的意义其实不大。

端越多，抽象层越厚，调试成本越高。我的建议是先锁定“核心两端”，第三端用同一套业务逻辑但独立 UI，比强行一套 UI 打通要稳得多。

框架选型看三个硬指标

1. 原生桥接能力

跨端框架最终都要落到原生。要确认它能不能方便地调用平台 API，能不能写原生插件，以及社区里有没有现成的 SDK 封装。比如推送、蓝牙、地图、相机这类能力，如果每个都要自己写插件，多端省下来的时间很快会被吃掉。

2. 构建产物与包体积

同一份代码编译到不同平台，产物差异可能很大。上线前一定要看实际包体积，尤其是小程序有 2MB 主包限制。业务代码分包、静态资源外链、按需引入，这些要在项目初期就设计好，不要等包超了再拆。

3. 团队熟悉度

框架再好，团队不熟就是负债。如果团队以 Vue 为主，选对应技术栈的跨端方案，学习成本会低很多。反过来，为了“技术先进”选一个没人会用的框架，后期招人和排障都会很痛苦。

代码复用的边界在哪里

我的经验是把代码分成三层来管理：

• 纯逻辑层：请求封装、数据格式化、校验规则、状态管理。这一层可以 100% 复用，收益最高。
• 组件层：按钮、列表、弹窗这类基础组件，尽量复用，但允许各端做样式覆盖。
• 页面层：导航、生命周期、权限交互差异最大，建议各端独立实现，只共享业务逻辑。

很多项目失败在试图把页面层也完全统一，结果到处是平台判断分支，代码比写两遍还难读。

// 逻辑层：与平台无关
async function loadOrders(params) {
  const res = await request.get('/api/orders', params);
  return res.list.map(normalizeOrder);
}

// 页面层：各端各自调用
// 小程序页面
onLoad() { loadOrders({ page: 1 }).then(list => this.setData({ list })); }
// App 页面
mounted() { loadOrders({ page: 1 }).then(list => { this.list = list; }); }

登录与支付是最容易出问题的两处

小程序用 code 换 openid，App 用手机号或第三方登录，H5 又是另一套。支付上，小程序走平台支付，App 走应用内支付或第三方支付，H5 还要考虑回调地址。这两块建议做成独立的适配层，用统一接口对外暴露：

interface AuthAdapter {
  login(): Promise<Token>;
  logout(): Promise<void>;
}

interface PayAdapter {
  pay(order: Order): Promise<PayResult>;
}

业务层只依赖接口，各端提供实现。这样新增一端时，只需要补一个适配器，而不是回头改业务代码。

发布与灰度要提前设计

多端意味着发布节奏不同：App 要过审、有版本留存，小程序可以快速回滚，H5 随时上线。如果所有端共用一个后端接口，接口变更就必须向后兼容。我的做法是接口带版本号，新增字段可以，删除字段要等所有端的最低版本都升级完。同时用远程配置控制功能开关，出问题时按端、按版本关闭，而不是紧急发版。

什么时候不该做多端

如果产品还处在验证阶段，只有一端有真实用户，那就先把一端做好。多端开发的固定成本包括框架学习、构建配置、多端测试、发布流程，这些在需求没验证前都是纯投入。等核心端的留存和付费跑通了，再考虑把逻辑层抽出来复用到第二端，节奏会更健康。

多端App开发本质上是一道成本题：用抽象换复用，用约束换效率。把复用边界划清楚，把平台差异收进适配层，剩下的就是老老实实维护构建和发布流程。