同一份代码上多个宿主：小游戏容器接入面要拆成六类差异
一、跨宿主的难点不在画面上，在四个由不得你的接口
据公开报道，有短视频平台正在加速铺开小游戏生态，一批即玩类的模拟经营与解谜产品被送进信息流。平台动向与商业表现一律按公开报道处理，不是本篇判断依据；这篇只谈接入侧的工程问题，不谈任何经营与收益话题。
做过多端的人对”一次开发、多处运行”有一套本能反应：先担心渲染。实际把同一份代码铺到多个宿主容器里之后会发现，图形层反而是差异最小的部分——各家容器大多兼容同一套主流接口，分辨率与帧率适配是体力活。真正吃掉工期的是四个”由不得你”的接口：登录身份由宿主发放，存档同步受宿主能力限制，支付与激励走宿主的通道，推送召回用宿主的触达机制。这四类接口你无权修改、无法等待、版本能力各家不同，而且宿主一次静默调整，你的全部接入端要同时回归。所以跨宿主工程的正确起点，是把接入面拆成可枚举、可测试、可降级的差异清单，而不是先搭渲染抽象层。
二、六类接入面差异矩阵
我们把小游戏宿主的接入面固定拆成六类：登录与身份映射、云存档与冲突合并、支付与虚拟货币、广告与激励、分享与社交关系、推送与召回。每类的差异点与缺能力时的降级做法如下。
| 接入面 | 典型差异点 | 无该能力或能力受限时的降级 |
|---|---|---|
| 登录与身份 | 授权流程版本、会话有效期、游客态定义 | 本地匿名档加显式引导绑定，禁止静默合并 |
| 云存档 | 接口有无、单档大小上限、同步触发时机 | 降级为本地存档加导出导入码，标记未上云 |
| 支付与虚拟货币 | 通道归属、代币体系是否互通、退款接口 | 隐藏入口而非报错，保留已购权益的本地校验 |
| 广告与激励 | 激励视频回调可靠性、频控策略、填充差异 | 奖励改为手动确认加服务端补发，回调超时兜底 |
| 分享与社交 | 关系链可见范围、分享卡片格式、排行榜授权 | 只做不含关系数据的成就卡分享 |
| 推送与召回 | 触达通道配额、时效性、退订状态回传 | 站内信加下次启动提示，不承诺即时触达 |
这张表要按宿主逐个填版本号：同一类接口在不同宿主版本上的能力不同，”宿主A支持”这种表述没有意义，有意义的是”宿主A自某版本起支持、旧版本走哪条降级”。降级路径不是备用方案，是主方案的一部分——每个接入面都必须存在一条宿主能力完全缺席时也能走完的路径，否则宿主的一次接口调整就变成你的线上事故。
三、身份映射的坑：同一个人，五个ID
六类里最深的是登录。每个宿主发的是自己域内的用户标识，同一个自然人在五个宿主里就是五个互不相通的ID。游戏进度、购买记录、排行榜成绩各自落在不同ID上，用户的感觉却是”我玩的是同一个游戏”——他昨天在短视频宿主里打到第三章，今天在安装型宿主里从第一章开始，不会认为这是宿主的错，只会认为你的游戏坏了。
跨端合并的账号策略只有三条正路。第一条是独立账号体系：引导用户注册你的中心账号，宿主ID作为登录方式之一绑定进去，进度以中心账号为权威。这条路工程量最大，但多宿主超过两个之后别的方案都会退化。第二条是保守不合并：各宿主进度物理隔离，界面上明说进度互不相通，防止用户拿A端的记录来对账B端。第三条是受限合并：只同步不冲突的数据，比如全局解锁状态取并集，而进度这类同种资源不合并。绝对禁止的是拿设备指纹或手机号猜测”是同一个人”然后静默合并——猜错一次的代价是两名用户的存档互相污染，而且这类事故无法向用户解释。身份映射要在数据模型里留字段：每条存档标记来源宿主与宿主侧ID，合并决策的输入输出都要可追溯。
四、云存档冲突的四种解法与防作弊边界
多宿主必然多端同时在线，存档冲突的解法有四种，适用面各不相同。
| 解法 | 机制 | 适用 | 主要风险 |
|---|---|---|---|
| 后写覆盖 | 以最后到达的写入为准 | 单关卡内的细碎进度 | 弱网重试把旧数据”后写”，进度回退 |
| 服务端权威 | 全部写入经服务端判定合并 | 有服务端的关卡与资源数据 | 离线宿主端体验差，需要本地缓冲队列 |
| 字段级合并 | 按字段分别取较新值或并集 | 解锁状态、图鉴收集这类集合型数据 | 字段间存在依赖时合并结果自相矛盾 |
| 按关卡分片 | 存档切成分片，冲突只发生在片内 | 线性推进的剧情与解谜类 | 分片边界设计不当，跨片进度无法对齐 |
实际方案通常是组合：集合型数据走字段级合并，线性进度走按关卡分片加服务端权威，纯本地草稿走带版本号的后写。无论哪种组合，写入必须带单调序号或向量时钟，否则连冲突发生了都检测不到。防作弊的边界要顺着这个结构画：客户端上报的进度数值一律视为不可信输入，关键节点由服务端依据行为流水校验——通关事件要能对上操作序列的时间间隔，资源增长要能对上产出来源。校验规则放在服务端、按宿主灰度启用，并且给误判留申诉通道：跨宿主场景里客户端版本参差不齐，一刀切的封禁策略必然错伤正常玩家。
五、宿主给的约束：性能包体与审核口径
性能侧的约束由容器单方面给出且各家不同：首屏时间预算决定冷启动阶段要预载多少资源，包体上限决定主包与分包的切法，内存红线决定贴图与音频的驻留策略，热更新限制决定哪些逻辑必须走宿主发布流程而不是自己下发。这里与自己做App不同的关键点在于：你不知道用户的宿主会同时开着什么——宿主本身是重资源应用，你的内存预算要按宿主余量而不是设备标称值来留，压测必须在宿主内做而不是浏览器里做。发布侧的口径同样按宿主分开：内容分级标准各家解释不同，隐私声明的挂载位置与措辞有各自要求，未成年人相关的时段与功能限制由宿主强制执行，数据出境与存储地域在跨区宿主上各有一套。审核被拒的原因几乎从不重复，所以每次被拒都要归档为宿主知识库的一条，作为下个版本的提交前置检查。
六、测试矩阵与埋点对账
洹拓接跨宿主项目时，交付物里必含一张宿主测试矩阵：行为真机矩阵——每个宿主至少覆盖高中低三档机型，重点跑六个接入面的降级路径而不是游戏玩法；宿主版本清单——记录每个宿主的当前版本、已验证版本与已知能力差异，新宿主版本发布后先跑接口冒烟再谈兼容；灰度开关与远程降级——六类接入面各自挂独立开关，某宿主某接口出问题时能单点降级，不牵连整包。开关的默认值策略要写进发布检查单，历史上最多的事故不是开关没做，而是新版本忘了把开关从灰度拨回全量。
最后一件事是埋点对账。各宿主的埋点通道、时间基准、会话定义互不一致，同一份行为流水在不同宿主报表里会出现对不上的总量。对账方法是建立以自己服务端为准的统一口径：事件在服务端打标宿主来源与校正后的时间戳，日常报表只读打标后的流水，宿主自带报表仅用于交叉验证而不用于决策；每周做一次双向核对，差值超出容差就排查通道丢失还是重复上报。跨宿主项目的统计纠纷，多数最后查出来的不是数据错了，而是两边根本在用不同的”一次访问”定义。接入面矩阵管工程的一致性，对账口径管数据的一致性，两张表都在，”一次开发、多处运行”才是工程承诺而不是一句口号。