6.4 小程序平台限制与兼容
6.4 小程序平台限制与兼容
本节导读：小程序是限制最密集的端，但限制不是玄学——它们有明确的文档边界与对应的工程绕法。本节把限制收进五张清单：体积与请求、授权模型、登录支付流程、页面与交互、审核红线，每条给"边界是什么、怎么绕、兜底是什么"。读完你应当能在评审阶段就把踩线需求拦下来。
体积与请求：两道最刚性的门
第一道门是包体积（4.5 节已细拆，此处只提醒核对点）：主包两兆红线对 static 与公共依赖的挤压是持续性的，每次引入新 UI 组件与新插件都该顺手看一眼包分析。第二道门是请求域明白名单：小程序端只允许向后台登记过的 https 域名发请求，开发期可以勾"不校验合法域名"蒙混，上线后没有登记的域名一律失败。工程公约两条：请求域名集中在一个常量文件（5.3 的管道已满足），后台登记与代码同步维护；websocket 与上传下载各有独立的白名单分类，别只登记 request 类。
授权模型：一次性、可撤回、分类型
小程序的授权是"一次性同意、可随时撤回、按类型分开"的模型，工程侧要有三件套。先查再调：授权过的调 API 静默成功，没授权的弹窗、拒绝过的静默失败——判断用户当前授权状态用 getSetting；拒绝后的唤醒路径：引导用户去 openSetting 打开开关（6.1 的位置例子是标准模板）；scope 分型：位置、相册、摄像头各自独立授权，别假设"用户同意过 A 就会同意 B"。写成通用工具避免每处重写：
// utils/auth.js —— 小程序端授权三件套（其他端走各自权限模型） export async function ensureScope(scopeName, introText) { const setting = await uni.getSetting(); if (setting.authSetting[scopeName]) return true; // 已授权 if (setting.authSetting[scopeName] === undefined) { // 从未询问：直接触发授权弹窗 const res = await uni.authorize({ scope: scopeName }); return !!res; } // 曾拒绝：只能引导去设置页 const { confirm } = await uni.showModal({ title: '权限申请', content: introText }); if (confirm) { const back = await uni.openSetting(); return !!back.authSetting[scopeName]; } return false; }
登录与支付：平台专属流程的兼容面
微信端的登录不是"账号密码"而是** wx.login 换 code、服务端换 openId** 的流程，与自建账号体系的绑定关系要在服务端设计好；获取手机号要用 button 的 open-type（3.1 的矩阵）且要求企业主体认证。支付在 6.2 已进适配层，这里补审核视角：小程序内购买虚拟商品（会员、课程）走微信支付以外的通道会被审核卡住（iOS 端尤其严格），实物电商不受此限。商城的会员业务因此做成"iOS 端隐藏购买入口、引导至 H5 完成"，这是行业通行绕法，但要在审核说明里写清楚，藏着掖着反而更容易被拒。
页面与交互：容易被忽略的四条
其一，页面层级上限十层（4.2 的栈深提醒），深导购链路要设计"归位"逻辑。其二，web-view 组件的域名也要白名单，且个人主体小程序不支持业务域名的 web-view；内嵌 H5 帮助中心这类需求先查主体资质。其三，没有动态执行代码的通道：eval 与 new Function 在小程序端不可用，模板引擎类方案要选编译期方案。其四，本地文件与缓存的清理时机由宿主管理，把"永久保存"的假设换成"重要数据进服务端或用户相册"。
图 6-4 五张限制清单的核对地图
拒审不是终点：沟通与申诉的姿势
提审被拒是常态工程，处理姿势决定返工速度。第一原则，先读全拒绝理由再动手——多数拒绝文案对应明确的平台规范条目，按条目修改比按猜测修改快得多。第二原则，能沟通就沟通：审核后台有申诉与客服通道，功能确实合规但被误判时，附上复现路径与说明材料，一轮沟通常能翻案；争不过的规则别硬顶，改方案比耗时间划算。第三原则，沉淀台账：每次被拒的原因、修改方式、再次提交的结果记进团队文档，半年后这本台账就是你们团队的审核预测模型，评审阶段就能拦下九成的踩线设计。对审核保持"工程师对规范"的心态，比抱怨平台规则有用得多。
兼容性测试的最小矩阵
小程序的兼容测试不可能覆盖所有机型与版本，给出最小可行矩阵。机型维度：iOS 与 Android 各一台主力机加一台低配老机，老机专测启动与长列表。基础库维度：开发工具里切最近版本与团队承诺支持的最低版本各跑一轮冒烟，重点验证能力检测降级分支是否真的兜住。宿主维度：微信端为主的话，支付宝或字节端的接入期再拉对应开发者工具全量回归。矩阵总共四到六个环境，一轮大约半天，配合发版纪律每个版本必跑——兼容事故的大头（新 API 用在老基础库、降级分支写错）都能被这张小矩阵拦下。
限制清单的维护机制
五张清单如果不更新，半年就会过期——平台的规则随版本演进持续变化。维护机制建议轻量：团队文档里为清单建一张变更表，每次平台公告涉及包体积、授权、审核政策的调整就追加一行，注明生效日期与影响面；每季度由一人对照官方公告全量校对一次。清单的价值不在"当时记了什么"，而在"现在还是不是对的"。把校对责任挂到人、更新动作写成习惯，这张地图才能一直带路。## 本节要点回顾
- 体积与域名白名单是两道刚性门，三类请求白名单分开登记；
- 授权三件套：getSetting 先查、authorize 首调、拒绝后 openSetting 唤醒；
- 登录走 code 换 openId 的绑定设计，虚拟支付 iOS 严格，端策略要主动设计；
- 栈深十层、web-view 域名、无动态代码、缓存可被清理，四条交互限制常被漏判；
- 审核红线进评审清单，拒审记录沉淀为团队资产。
各端领地走完，下一章进入交付段：编译原理、构建发布、性能调优与生态前沿。