张老板经营着一家连锁餐饮品牌，口味、菜品、后厨流程都是一套成熟体系。如今他要同时在三处开店：一家开在成熟社区（微信分店），一家开在高端商场（支付宝分店），一家开在网红打卡街（抖音分店）。照理说“一套功夫走天下”就行，可实际开起来才发现——社区店熟客多、复购靠群聊；商场店顾客信任会员积分、喜欢花呗分期；网红店流量汹涌但都是新面孔，大家来的目的就是“拍个视频顺便消费”。三家店的收银机、会员卡、物业规则、消防标准还都不一样。 小程序开发也是同一个道理。微信、支付宝、抖音三大平台，底层代码都是“一套功夫”，但每家平台的用户画像、API能力、支付体系、审核规则、组件规范各有各的脾气。开发者如果只盯着微信小程序做，贸然搬到支付宝、抖音上，轻则功能报错，重则类目审核不过、支付通道根本开不了。这篇文章就用“张老板开三家分店”的故事，带你摸清三家平台的差异，学会用条件编译的“一店三开”策略，把跨端维护成本压到最低。

岗位关联

理解三端差异是移动端开发者的基本功。掌握了平台特性与适配策略，你就能在跨端项目里少踩坑、少返工，成为团队里那个“hold 住全平台”的关键角色。

目录
  1. 可视化演示
  2. 一、平台生态差异：开店先看商圈
  3. 二、API能力对比：后厨能借到多少家伙
  4. 三、组件与开发规范：同一道菜，三种写法
  5. 四、支付接口差异：三台收银机，各收各的钱
  6. 五、审核与发布规范：三本“开业证”各跑各的流程
  7. 六、跨平台适配策略：一店三开，共享后厨
  8. 七、功能设计差异化：顾客口味必须区别对待
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

对比微信、支付宝、抖音三大小程序平台的API能力、审核规则与跨端编译策略，点击按钮切换不同维度视图

本节配有交互动效（进入视口后自动加载，约 3KB）。

三平台差异总览 微信生态最完善API覆盖最广 支付宝支付与金融能力突出 抖音内容与媒体API更丰富 三平台UI组件存在命名差异 审核规则严格程度各有不同 微信支付宝抖音三端各有优势

一、平台生态差异：开店先看商圈

张老板第一次选址就发现，商圈决定了一切。社区店的顾客是住在这里的居民，每天买菜、接孩子、遛弯，顺手进店；高端商场的顾客是逛街的白领，逛累了想找个地方歇脚；网红打卡街的顾客则是被短视频吸引来的游客，举起手机拍完就走。微信小程序的用户就像社区居民，日常刚需高频，习惯在聊天过程中顺手点开小程序；支付宝小程序的用户活跃在“办事”场景，带着明确的消费目的，信任支付宝的信用体系；抖音小程序的用户则是被内容种草，浏览时被“击中”才下单。

技术上看，三端平台的基因差异决定了生态逻辑。微信是“社交关系链驱动的熟人生态”，流量来自私域转发和群聊；支付宝是“商业信用驱动的工具生态”，流量来自搜索和首页推荐；抖音是“算法推荐驱动的内容生态”，流量来自短视频挂载和直播。三者的支付体系更是完全隔离：微信走微信支付，支付宝走支付宝收银台，抖音用抖音支付。你说“我习惯了用支付宝扫码”，在抖音小程序里却只能干瞪眼。

因此，做跨端之前先算一笔账：

所以，别急着“三店同开”，先像张老板一样蹲在商圈门口数人头——你的目标用户到底在哪个平台闲逛？

S=∑i=1nwi×ciS = \sum_{i=1}^{n} w_i \times c_i
公式解释：适配度评分 \( S \) 等于每个平台特性权重 \( w_i \) 与业务匹配度 \( c_i \) 的乘积之和。权重越高代表这个维度对你业务越重要，匹配度越高说明平台越适合。
  1. 求和符号\( \sum \) 表示把后面所有项目逐一相加，意思是“综合评估每一个平台维度的适配情况”。
    ∑i=1n\displaystyle \sum_{i=1}^{n}
  2. 权重 \( w_i \)代表第 \( i \) 个平台特性（如用户匹配度、流量成本、支付便利性）的重要程度，你越看重的维度权重越大。
    wi\displaystyle w_i
  3. 匹配度 \( c_i \)表示该平台特性与你的业务类型是否合拍，取值范围通常在 0 到 1 之间，1 表示完全匹配。
    ci\displaystyle c_i

二、API能力对比：后厨能借到多少家伙

每家分店的厨房配置完全不同。社区店的厨房有全套蒸笼烤箱（微信提供了丰富的开放API）；商场店的厨房有会员体系和积分工具（支付宝强化了信用授权的接口）；网红店的厨房则最看重拍摄、分享相关的能力（抖音把内容创作API放在了核心位置）。同样做一个小程序，你在微信里调用 wx.getLocation 轻松拿到定位，到了支付宝要查 my.location 有没有开放；想分享给好友，微信有 onShareAppMessage，抖音则要求用 tt.share 配合短视频挂载组件。

API的差异不仅体现在名字前缀上（微信 wx.、支付宝 my.、抖音 tt.），更体现在能力覆盖范围：微信因为起步早、生态厚，开放接口数量最多，涵盖支付、卡券、物流、微信运动等；支付宝的优势在商业能力，芝麻信用、花呗分期、生活缴费等接口独树一帜；抖音的开放接口相对集中，围绕内容创作、直播带货和社交分享展开，但地理定位等基础能力反而受限。

判断一个平台能否承接你的核心业务，可以算一笔“API支持率”的账：

所以，写第一行业务代码之前，先做一张“API 清单对照表”，像张老板借厨房前先列清单：这家店有没有烤箱？有没有蒸锅？缺了哪口锅，要么换菜谱，要么自带家伙。

R=∑j=1NajNR = \frac{\sum_{j=1}^{N} a_j}{N}
公式解释：\( R \) 表示你的业务需要的 \( N \) 个关键 API 中，该平台实际可用的有多少个。\( a_j \) 取值 1 表示第 \( j \) 个 API 可用，0 表示不可用。
  1. 分子求和\( \sum_{j=1}^{N} a_j \) 数出业务必需的 API 中在该平台能用的有几个，例如必需 5 个 API，能用 4 个，分子就是 4。
    ∑j=1Naj\displaystyle \sum_{j=1}^{N} a_j
  2. 总量 \( N \)分母是业务必需的 API 总数，把这个数固定下来，再看每个平台的分子。
    N\displaystyle N
  3. 支持率 \( R \)两者相除得到一个 0 到 1 的比例，超过 70% 才值得做跨端适配，低于 50% 不如单独开发原生小程序。
    R\displaystyle R

三、组件与开发规范：同一道菜，三种写法

张老板的招牌红烧肉，在社区店用砂锅炖，在商场店用铁锅烧，在网红店用高压锅压——做法一样，工具不同。小程序的组件语法也走过了类似的路：微信用 <view>、<text>、wx:if；支付宝用 <view> 但条件指令写成 a:if；抖音小程序的基础组件虽然也叫 <view>，事件绑定指令却用 tt:for 这类前缀。看似都叫“视图容器”，细节差异足以让你粘贴复制的代码直接报错。

更大的坑在生命周期。微信有 onLoad → onShow → onReady → onHide → onUnload 五段论；支付宝的 onReady 更名为 onRender 且时机不同；抖音小程序的页面生命周期与微信大体相似，但组件的 lifetimes 支持范围又不一样。样式方面，微信和支付宝都支持 rpx 响应式单位，抖音小程序却同时支持 rpx 和 vw/vh，且某些 CSS 属性（如 position: sticky）在部分平台失效。

假设你有一段共用的业务逻辑，真正运行时要付出的“改写工程量”可以用代码复用率来衡量：

与其硬记每家的写法，不如把平台差异封装进自定义组件里——就像张老板统一规定“红烧肉必须提前烧好半成品”，到了哪家店只需要按那个店的器具加热上桌。

M=SsharedStotal×100%M = \frac{S_{\text{shared}}}{S_{\text{total}}} \times 100\%
公式解释：复用率 \( M \) 等于三端可共享的代码量 \( S_{\text{shared}} \) 占全部代码量 \( S_{\text{total}} \) 的比例。复用率越高，迁移成本越低。
  1. 共享代码 \( S_{\text{shared}} \)指与平台无关的逻辑代码，比如价格计算、购物车管理、用户行为记录这些“菜谱配方”，三店通用。
    Sshared\displaystyle S_{\text{shared}}
  2. 总代码量 \( S_{\text{total}} \)全部代码包含共享部分与平台差异部分，差异部分就是需要单独维护的“灶台适配层”。
    Stotal\displaystyle S_{\text{total}}
  3. 百分比换算乘以 \( 100\% \) 把比值变成直观的百分比，方便和团队沟通开发量。
    ×100%\displaystyle \times 100\%

四、支付接口差异：三台收银机，各收各的钱

张老板开店最头疼的就是收银台。社区店装的是微信收款音箱，商场店摆的是支付宝蜻蜓刷脸机，网红店则是抖音的小店收银系统。三台机器互不兼容，顾客习惯哪台就只能刷哪台。小程序支付环节完全复刻了这种“物理隔离”：微信小程序必须调 wx.requestPayment 拉起微信支付的收银界面；支付宝小程序调 my.tradePay 走支付宝的支付流程，支持花呗、余额宝；抖音小程序则必须用 tt.pay 走抖音支付，且一笔订单只能挂在一家小店里面。

除了支付流程，认证门槛也分三六九等。微信支付商户号需要营业执照、法人身份证和对公账户；支付宝的商家认证同样严格，但对个体工商户更友好；而抖音支付的小店入驻还增加了内容要求，部分类目需要提供直播资质甚至广告投放承诺。费率上，微信和支付宝标准费率都是 0.6%，而抖音支付新上线时带补贴、常规费率高于前两者，且不同行业的扣点浮动更大。

商家最关心的“实际到手钱”可以这样算：

做多端支付时，请像张老板在三家店分别贴上“本店仅支持XX支付”一样，在前端明显位置展示支付方式，避免用户跳转后才发现“我的钱付不了”。

Pnet=T×(1−r)−FP_{\text{net}} = T \times (1 - r) - F
公式解释：实际到账金额 \( P_{\text{net}} \) 等于交易额 \( T \) 扣除按费率 \( r \) 抽取的手续费，再减去每笔固定费用 \( F \)。
  1. 交易总额 \( T \)用户下单支付的原始金额，是计算手续费的基数。
    T\displaystyle T
  2. 费率 \( r \)平台按比例抽取的手续费，0.6% 意味着每 100 元抽 0.6 元。三端费率政策随时间调整，上线前务必查询最新费率文档。
    (1−r)\displaystyle (1 - r)
  3. 固定费用 \( F \)部分平台会按笔收取固定的服务费（第三方支付常出现），而微信支付宝直连商户一般为 0。
    −F\displaystyle - F

五、审核与发布规范：三本“开业证”各跑各的流程

张老板在社区店开店，物业说“材料齐全三天拿证”；商场店的招商部流程繁琐，要品牌资质、消防验收、油烟管道检测，跑了两个星期；网红街的管委会则最看重“内容风格”，要求店铺门头必须适合拍照打卡，否则不给发临时经营证。审核规则直接决定你上线的速度：支付宝小程序以“快速迭代”著称，一般 1-2 个工作日完成审核，适合做活动抢时间；微信小程序审核周期通常在 3-7 天，且对类目、隐私协议、用户拒绝授权处理机制查得很细；抖音小程序审核最严格，涉及内容导向、直播资质和带货规范的类目，最长可能耗费一周以上。

包大小限制也是硬门槛。微信小程序主包限制 2MB，总包上限 20MB；支付宝小程序主包 2MB，总包 20MB 左右；抖音小程序早期主包限制 1MB，后来逐步放开到 2MB，但资源加载策略与缓存机制又不同。类目资质上，微信有 27 个一级类目，支付宝和抖音各有自己的一套，比如抖音对“小说-短剧”类目有专项资质，支付宝对“金融理财”类目审核极严。

项目从开发到上线的总耗时可以建模为：

从第一天开发就对照三端审核清单准备材料，像张老板同时挂三个号办证，谁先叫号就先开哪家店。

L=∑k=1ntk+w×nL = \sum_{k=1}^{n} t_k + w \times n
公式解释：总上线周期 \( L \) 等于每次提审的审核时长 \( t_k \) 累加，再加上每次审核排队等待时间 \( w \) 乘以提审次数 \( n \)。审核不通过被打回一次，排队时间就要重新付一次。
  1. 历次审核时长 \( \sum t_k \)每提交一次版本，平台审核人员需要一个处理周期，累计起来就是纯审核耗时。
    ∑k=1ntk\displaystyle \sum_{k=1}^{n} t_k
  2. 提审次数 \( n \)被打回重提会成倍增加周期，所以“一次过审”是降本增效的黄金法则。
    n\displaystyle n
  3. 排队时间 \( w \)每次提交后还要在平台队列里等待，这个变量往往被新手忽略——周五晚上提交和周二上午提交，排队时间可能差出两倍。
    w×n\displaystyle w \times n

六、跨平台适配策略：一店三开，共享后厨

张老板想通了：与其在每个商圈各搭一间厨房，不如把洗菜、切菜、腌制这些环节放在中央厨房统一完成，每家门面只保留“加热上桌”的简易操作间。这就是跨端开发的思路——用 uni-app 或 Taro 这类跨端框架写一套代码，再通过编译工具把代码“翻译”成各平台的小程序。但翻译不是万能的，平台专属能力（如支付宝的芝麻信用、抖音的短视频挂载）必须靠条件编译来“开小灶”。

条件编译的原理，简单说就是在源码中标注哪些代码块只在哪些平台生效。例如 uni-app 里：

编译时工具会自动保留支付宝端的 my.request、抖音端的 tt.request，而其他平台的代码被当作注释裁剪掉。这就像张老板给每家店发不同的“后厨操作手册”——社区店手册写“用燃气灶”，商场店手册写“用电陶炉”，中央厨房统一配送的菜谱则是共用的。

多端统一封装也很重要。把常见的 login、request、pay 封装成自定义 API：

总开发成本模型随之变成：

请记住，条件编译是“同一道菜按口味加盐”，不是“一锅乱炖”——保持核心逻辑纯净，把差异都隔离在薄薄的一层适配器里，后续维护才轻松。

C=Cbase(1+∑i=1mdi)C = C_{\text{base}} \left(1 + \sum_{i=1}^{m} d_i\right)
公式解释：使用跨端框架后，总成本 \( C \) 等于一份基础代码的开发成本 \( C_{\text{base}} \)，乘以一个膨胀系数。\( d_i \) 是第 \( i \) 个平台的差异化开发量占比，平台差异越大，系数越大。
  1. 基础成本 \( C_{\text{base}} \)写一套核心业务代码的开发成本，这是“中央厨房”的固定投入。
    Cbase\displaystyle C_{\text{base}}
  2. 差异系数 \( d_i \)每个平台需要额外开发的专属功能占基础代码的比例，比如抖音多了直播组件，支付宝多了花呗分期。
    ∑i=1mdi\displaystyle \sum_{i=1}^{m} d_i
  3. 总成本 \( C \)三端总投入不是三倍基础成本，而是“一份基础 + 若干差异”，这就是跨端框架的价值所在。
    C\displaystyle C
js7 行
// #ifdef MP-ALIPAYmy.request({ url: 'https://api.example.com' })// #endif // #ifdef MP-TOUTIAOtt.request({ url: 'https://api.example.com' })// #endif
js12 行
// 统一登录export function login() {  // #ifdef MP-WEIXIN  return wx.login()  // #endif  // #ifdef MP-ALIPAY  return my.getAuthCode()  // #endif  // #ifdef MP-TOUTIAO  return tt.login()  // #endif}

七、功能设计差异化：顾客口味必须区别对待

张老板的同一道招牌菜，在社区店装盘要实惠量大，在商场店要精致摆盘，在网红店要方便端在手上边走边拍。功能的差异化设计不是炫技，而是顺应平台的用户心理。微信用户习惯“用完即走”，核心流程要三步内完成，支付前别让用户注册会员，登录直接用微信授权即可；支付宝用户带着“办事”心态，功能设计要突出信任背书——展示芝麻信用、支持花呗分期、提供交易保障，会让转化率明显提升；抖音用户处在“刷视频”的场景里，小程序应该“轻到不打断浏览”，挂载在短视频左下角、一键跳转下单，任何需要手动输入的操作都会劝退用户。

分享裂变机制是三端差异的放大镜：微信小程序靠“转发给微信群+好友助力”，裂变链路是社交关系链；支付宝小程序有“吱口令+蚂蚁森林能量激励机制”，基于信用体系的花样玩法；抖音小程序则要配合视频创作和话题挑战赛，让用户“拍视频带小程序链接”参与裂变。调研显示，抖音用户看到小程序的第一反应是“这个能不能拍同款”，而不是“这个好不好用”。

功能上线后，要盯紧这个核心指标：

像张老板定期去三家店“暗中观察”顾客用餐习惯那样，用每个平台的用户行为数据反向迭代功能设计，你的小程序才能在每家店都做出“本地化口味”。

η=NpayNpv×100%\eta = \frac{N_{\text{pay}}}{N_{\text{pv}}} \times 100\%
公式解释：支付转化率 \( \eta \) 等于实际支付用户数 \( N_{\text{pay}} \) 除以小程序页面浏览量 \( N_{\text{pv}} \)。它直接反映功能设计与平台用户是否合拍。
  1. 页面浏览量 \( N_{\text{pv}} \)小程序被打开的次数，相当于“逛店人数”。抖音端这个数字天然很大，但别高兴太早。
    Npv\displaystyle N_{\text{pv}}
  2. 支付用户数 \( N_{\text{pay}} \)真正完成支付的用户数，相当于“掏钱买单”的人数。
    Npay\displaystyle N_{\text{pay}}
  3. 转化率 \( \eta \)两者相除得出百分比。抖音端常出现“流量大但转化率低”的现象，正说明设计没有顺应浏览场景。
    ×100%\displaystyle \times 100\%

AI 应用场景

场景一：连锁茶饮品牌的三端小程序统一运营

阶段：跨平台适配与多端发布

解决的问题：传统开发需要维护微信、支付宝、抖音三套独立代码，新增一个营销活动要重复开发三次，排期长、易出错。AI 辅助编码 + 跨端框架 + 条件编译，让团队写一份核心逻辑代码，通过编译自动生成三端包，配合 AI 代码生成工具自动补齐各端 API 差异，把开发量压缩到原来的 60%。

具体案例：某头部茶饮品牌使用 uni-app 重构点单小程序：抽奖活动等核心逻辑共享一套代码，支付环节用条件编译分别对接微信支付、支付宝花呗、抖音支付；支付宝端额外接入会员积分接口，抖音端挂载“拍视频领券”组件。三端同时发布，活动上线周期从 3 周缩至 1 周。

场景二：本地生活服务商家的支付通道选型

阶段：支付接口集成与商务决策

解决的问题：商家最容易踩的坑就是“默认选微信支付”。AI 将各平台费率政策、结算周期、认证要求整理成对比报告，辅助商家根据自身客群和场景选择收银通道，计算实际到账金额，并自动生成多平台对账单。

具体案例：一家线下烘焙店同时开通微信与支付宝到账：桌贴二维码分别对应两个平台的支付小程序，AI 对账系统每晚拉取两家平台的账单，自动匹配订单并生成日报，老板一眼看出哪端客人更喜欢用花呗、哪端习惯用零钱。如果未来要开抖音小店，系统会先模拟支付费率差，给出定价建议。

场景三：短视频带货小程序的抖音端专属设计

阶段：功能差异化设计与转化率优化

解决的问题：直接把微信小程序的“九宫格功能页”搬到抖音端，用户根本没耐心看完。AI 根据用户行为数据自动识别“浏览型用户”和“下单型用户”，动态调整首页布局：浏览型用户优先展示短视频挂载的商品卡片，下单型用户直接展示购物车入口，将转化率提升 15% 以上。

具体案例：某美妆品牌抖音小程序上线时，首页只保留“正在直播”和“全部商品”两个入口，所有商品支持“拍同款”按钮——用户拍视频带上商品链接即可获得佣金。AI 分析发现，抖音用户下单高峰集中在直播时段，于是功能设计把直播组件置于首屏，并自动生成 “直播专属优惠券”，订单量提升两倍。

Python 演示

python57 行
# -*- coding: utf-8 -*-"""模拟三端小程序 API 差异检测与条件编译分流""" class PlatformConfig:    def __init__(self, name, api_list, pay_fee, audit_days):        self.name = name        self.api_list = set(api_list)        self.pay_fee = pay_fee        self.audit_days = audit_days     def support(self, api):        return api in self.api_list  class MiniAppAdapter:    def __init__(self):        self.config_map = {            'wx': PlatformConfig('微信', ['login', 'pay', 'share', 'location', 'card'], 0.006, 5),            'my': PlatformConfig('支付宝', ['login', 'pay', 'auth', 'location', 'member'], 0.006, 2),            'tt': PlatformConfig('抖音', ['login', 'share', 'pay', 'video', 'live'], 0.014, 7)        }     def detect_platform(self, user_agent):        if 'alipay' in user_agent:            return 'my'        if 'douyin' in user_agent or 'toutiao' in user_agent:            return 'tt'        return 'wx'     def compile_branch(self, platform, api_name):        prefix = {'wx': 'wx', 'my': 'my', 'tt': 'tt'}[platform]        return prefix + '.' + api_name     def compat_report(self, required_apis):        for key, cfg in self.config_map.items():            missing = [api for api in required_apis if not cfg.support(api)]            rate = 1 - len(missing) / len(required_apis)            print('{}: API支持率 {:.0%}, 缺失 {}'.format(cfg.name, rate, missing))  def main():    adapter = MiniAppAdapter()    required = ['login', 'pay', 'share', 'location', 'video']    print('=== 三端 API 支持率报告 ===')    adapter.compat_report(required)     print('\n=== 条件编译模拟 ===')    ua = 'Mozilla/5.0 (iPhone) Mobile alipay 支付宝客户端'    platform = adapter.detect_platform(ua)    line = adapter.compile_branch(platform, 'pay')    print('UA 识别: {} -> 编译分支: {}'.format(ua, platform))    print('最终调用: ' + line)    print('\n模拟完成: 条件编译帮助一份代码对应三端 API')  if __name__ == '__main__':    main()
目的：模拟开发者在三端做 API 兼容检测与条件编译代码分流的过程，帮助理解跨端适配器的设计思路。
  1. class PlatformConfig定义每个平台的配置信息，包括可用 API 集合、支付费率、审核天数，就像张老板给每家分店建的“设备档案”。
  2. def detect_platform(self, user_agent)通过 UA 识别当前小程序运行在哪个平台，对应“判断顾客进了哪家店”。
  3. def compile_branch(self, platform, api_name)根据平台前缀拼接出真正的 API 调用语句，模拟条件编译时wx./my./tt.前缀替换。
  4. missing = [api for api in required_apis if not cfg.support(api)]筛出当前平台缺失的 API，用列表推导式计算“还缺哪口锅”。
  5. rate = 1 - len(missing) / len(required_apis)计算 API 支持率，辅助判断这个平台值不值得投入适配成本。

常见误区

误区我用了 uni-app / Taro，一套代码编译到微信、支付宝、抖音，肯定到处都能跑，不需要再做任何平台适配了。

正解跨端框架只解决了“基础组件和常用 API”的统一，平台独有能力（支付宝的芝麻信用、抖音的短视频挂载、微信的卡券包）框架无法凭空生成。条件编译仍是必需品，框架给你的是“中央厨房”，不是“免检全牌照”。

为何常见：框架宣传强调“一套代码多端覆盖”，容易让新手误以为万事大吉，直到真机上遇到 my.getAuthCode is not a function 才如梦初醒。

误区`wx.requestPayment` 改成 `my.tradePay`、`tt.pay` 不就行了？反正都是拉起支付。

正解支付链路的差异远比接口名更深：微信支付走“商户号+API 证书”，支付宝支持“花呗分期”且需要单独签约，抖音支付要求订单必须挂在小店内且与创作者分账逻辑绑定。费率、结算周期、退款流程都不一样，直接替换接口等于只换了收银机的牌子、没换收银系统。

为何常见：接口看起来都是“传入订单号、拉起收银台、返回支付结果”，掩盖了底层商户体系与资金流转的根本隔离。

误区微信小程序菜单里的“签到打卡”“九宫格功能页”直接搬到抖音端，反正抖音人多，总有人用。

正解抖音用户的浏览场景是“沉浸式刷视频”，任何打断浏览的操作（弹窗、多步注册、复杂表单）都会造成用户流失。正确做法是“内容即入口”——短视频挂载商品、直播一键下单、拍同款做裂变，功能越轻越好。

为何常见：开发者容易把“平台用户多”等同于“平台适合所有功能”，忽略了不同平台的用户心理状态。

误区微信过审了，支付宝和抖音肯定也能过，直接提交就行。

正解三类目清单不同（抖音对短剧、小说有特殊资质要求，支付宝对金融类目审核极严）；二隐私协议要求严格程度不同（微信要求单独的隐私弹窗 SDK）；三内容规范不同（抖音对诱导分享的打击力度更强）。微信过审不等于三端过审，必须单独准备材料、单独提审。

为何常见：“微信是行业老大”的惯性思维让人默认它的标准就是行业标准，忽视了平台竞争带来的规则分化。

面试题

Q1. 支付宝小程序调用支付接口的标准前缀是什么？

单选题 · easy

  • A.wx.pay()
  • B.my.tradePay()← 正确答案
  • C.tt.pay()
  • D.dd.pay()

答案：B。支付宝小程序统一使用 my. 前缀（例如 my.tradePay），微信小程序是 wx.，抖音小程序是 tt.。这就像三家店的收银机各用各的收款软件，不会互相通用。

Q2. 以下哪个平台的 API 支持率对“信用卡还款、花呗分期”这类金融服务最友好？

单选题 · mid

  • A.微信小程序
  • B.支付宝小程序← 正确答案
  • C.抖音小程序
  • D.三端没有差别

答案：B。支付宝的生态基因是商业与信用，花呗分期、芝麻信用、生活缴费等金融接口最完善。微信强在社交关系链，抖音强在内容分发。把金融功能放在支付宝端，就像在商场店装刷卡机，是最匹配的选择。

Q3. 抖音小程序支付费率相比微信和支付宝通常表现如何？

单选题 · mid

  • A.完全相同
  • B.略低一些
  • C.高出不少← 正确答案
  • D.平台不收费

答案：C。行业常规环境中，抖音支付费率高于微信和支付宝的 0.6% 标准，同时不同行业的扣点浮动较大。商家要把费率计入成本，不能只看到抖音流量大就忽略支付成本。

Q4. 一份跨端源码要同时适配微信、支付宝、抖音，合理的做法有哪些？

多选题 · hard

  • A.用跨端框架 Taro 编写，按需编译← 正确答案
  • B.对平台独有 API 使用条件编译隔离← 正确答案
  • C.完全不用任何框架，三套代码人工维护
  • D.将支付、登录统一封装为自定义 API← 正确答案

答案：ABD。跨端框架 + 条件编译 + 统一封装是标准方案。三套代码人工维护会放大成本，显然不可取。记住“中央厨房 + 简易操作间”的模式：共享的放一份，差异的做隔离。

Q5. 微信小程序页面生命周期包含 onLoad、onShow 和以下哪个钩子？

单选题 · easy

  • A.onReady← 正确答案
  • B.onRender
  • C.onDraw
  • D.onPaint

答案：A。微信生命周期是 onLoad→onShow→onReady→onHide→onUnload，onRender 是支付宝对 onReady 的改动，onDraw、onPaint 是 Canvas 相关事件。面试时记不住五段论，可以类比为“备菜、上桌、掌勺、撤盘、关店”五步。

Q6. 抖音小程序在“短视频挂载 + 直播带货”场景的最大优势依赖以下哪类 API？

单选题 · mid

  • A.微信支付 API
  • B.芝麻信用 API
  • C.内容与直播 API← 正确答案
  • D.地图导航 API

答案：C。抖音小程序的核心开放能力围绕内容创作（tt.createVideo）、直播（tt.openLive）和分享展开。这对应着网红街分店的招牌动作是“拍视频、开直播”，而不是像社区店那样靠地图导航吸引人。

Q7. 假设微信小程序包体 2MB，抖音小程序同样限制 2MB，但抖音不支持 WebView 加载 PDF 预览，以下最优处理策略是？

单选题 · hard

  • A.三端都改用图片格式替代 PDF
  • B.微信端用 wx.openDocument，抖音端用条件编译跳转浏览器打开← 正确答案
  • C.弃用抖音小程序
  • D.强制提交 20MB 大包覆盖全部功能

答案：B。多端适配的原则是“共享为主、差异隔离”。微信有打开文档的专用 API，抖音没有，那就让抖音端跳转浏览器——类似张老板在网红店不铺排烟管道，改为要求中央厨房送半成品，而不是放弃整家店或强行改菜谱。

Q8. 支付宝小程序的用户画像通常是哪类群体？

单选题 · easy

  • A.以办事、交易为目的的成熟用户← 正确答案
  • B.只刷短视频的娱乐用户
  • C.仅用于聊天的社交用户
  • D.不联网的离线用户

答案：A。支付宝用户带着明确的办事和消费意图，类似走进高端商场的顾客，目标明确、信任度高。功能设计应突出信用背书和交易保障，这是常识类题目。

Q9. 小程序三端组件与开发规范差异体现在哪些方面？

多选题 · mid

  • A.条件指令前缀不同（wx:if、a:if、tt:if）← 正确答案
  • B.生命周期钩子细节有差异← 正确答案
  • C.样式响应式单位支持范围不一致← 正确答案
  • D.JavaScript 语言版本完全不同

答案：ABC。三者的 JS 语言基础都是 ECMAScript，差异在 DOM 封装层而非语言本身。组件前缀、生命周期、样式单位这些“菜谱写法”各不相同，才是真实开发中的主要坑。

Q10. 一家新零售品牌要同时上线三端小程序，以下哪些做法符合成本与效率最优原则？

多选题 · extreme

  • A.先做微信端验证核心模式，再复制两份代码
  • B.使用跨端框架编写共享业务逻辑，条件编译处理差异← 正确答案
  • C.三端分别规划差异化功能，避免“一刀切”← 正确答案
  • D.把抖音端当作微信端的完全镜像，不做任何调整

答案：BC。先验证微信模式没错，但“复制两份代码”意味着三份代码长期同步，维护成本爆炸。跨端框架加条件编译解决了共享问题，同时要尊重三端用户习惯做功能差异化。抖音端做镜像等于无视网红街顾客“边走边拍”的行为特征，转化率必然惨淡。