一套代码多端跑的现实

微信、支付宝、百度、抖音、快手都有自己的小程序平台。理想状态是一套代码到处跑，现实是：它们长得像，但语法细节、可用 API、审核要求处处不同。多端开发的真正功夫，不是「写完一份」，而是「让同一份代码在每一端都能正常过审、正常跑」。

做了多端之后你会发现，大部分代码是共享的，真正需要按平台区分的只是少数——某个 API 这端没有、某个组件那端叫别的名字。把这些差异收敛好，多端就不痛苦。

多端不是写 N 遍，而是把差异收敛成 N 个小分支。

做之前先想清楚为什么要多端。如果你的目标用户主要在微信生态里，硬上六端往往是精力分散。多端是有收益才值得做的事，不是技术上能跑就要跑满所有平台。

本文核心知识点
  • 条件编译用平台标记把不同端的代码分开。
  • 能力差异知道哪些 API 哪些端能用。
  • 审核差异每端审核重点不同，分别准备。
  • 版本管理多端同步发布，别漏发。
小程序多端发布示意：蓝调渐变背景上一个中心节点向多块平台面板分发的扁平科技插画
一份代码，多条发布线：条件编译管代码差异，分别过审管平台差异。

条件编译：按平台写不同代码

多端框架（或自建脚本）通常支持条件编译：在代码里用平台标记把「只在某端生效」的部分括起来，编译时自动裁剪。

// #ifdef 表示只在某端编译
// #ifdef WECHAT
wx.login().then(doLogin);
// #endif

// #ifdef ALIPAY
my.getAuthCode().then(doLogin);
// #endif

条件编译的关键是：共享逻辑尽量不包条件，差异逻辑才包。如果你到处加 #ifdef，代码就变成一团端内分支，以后维护谁都看不懂。

各平台能力差异

同一段功能，在不同平台上的 API 名字和能力可能不一样。发布前要把用到的能力逐端核对一遍。

能力说明
登录授权各端换登录凭证的接口名不同
支付微信用微信支付，支付宝用支付宝支付，不能混用
分享分享到的场景和触发方式各端有别
 
// 封装一层，对外统一接口，对内按平台分发
function login() {
  if (isWechat()) return wxLogin();
  if (isAlipay()) return alipayLogin();
}

除了 API，界面细节也有差异：同一套样式，在不同端的渲染可能差几个像素，个别样式属性的支持程度也不一样。上线前要在每端的真机上都过一遍关键页面，别只在开发者模拟器里看。

审核差异与过审要点

技术能跑通不等于能上线。每个平台的审核侧重点不一样：微信看隐私合规和类目资质，支付宝看交易与登录体验，内容平台还要看内容合规。

  • 逐端准备好对应类目和资质，别用一套资质闯所有端。
  • 隐私协议按各端要求分别填，字段别照抄。
  • 被打回别慌，按驳回理由逐条改，再提审。

还有一个实操经验：第一次提交某端时，先只提一个最小可用版本把流程跑通，确认能过审之后再把功能逐步加上来。一上来就塞满功能被打回，反而拉长了上线时间。

发布流程与版本管理

多端最容易出的事故是「发了这端忘了那端」。一次产品改动要同时发好几端，版本号最好统一管理，别这端 1.2 那端还是 1.0。

// 版本号统一维护在一处，各端发布时读取
// 发布清单：微信 / 支付宝 / 抖音 逐端确认已提审、已上线
const VERSION = "1.2.0";

把每端的发布步骤列成清单，发一个勾一个，比靠脑子记靠谱得多。

版本管理之外，灰度也值得一做。新版本先放给一小部分用户，观察稳定了再全量，这样哪怕多端同时发，出问题也能及时止损。