小游戏平台与技术约束
Category
industry / platforms 子树。节点定位：小游戏是一类约束完全不同的运行环境——沙盒、首包预算、域名白名单、开放数据域、切前后台的硬边界。
Definition
小游戏平台常被当成“轻量版手游”，实际它是一类约束完全不同的运行环境：代码跑在宿主应用的沙盒里，包体、内存、网络域名、支付通道、社交数据全部受平台直接管控。这些约束大多是硬边界而不是性能建议，超出就运行不了或上不了线。小游戏项目的技术方案，本质上是在这套边界内做设计，而边界的细节会随平台版本调整，所以持续跟踪平台公告本身也是工程工作的一部分。
Problem
把小游戏当「轻量版手游」必翻车：代码跑在宿主沙盒里，包体/内存/域名/支付/社交数据全是硬边界，超出就运行不了或上不了线。边界细节随平台版本调整，跟踪平台公告本身就是工程工作。
约束清单为什么值得在立项时过一遍
小游戏的典型硬约束包括主包体积、分包总量、运行内存、网络域名白名单、接口调用频率、类目资质和内容审核。单看每一项都不复杂，麻烦在于它们相互咬合：包体预算压着资源架构，内存上限压着同屏内容，白名单压着所有网络链路，审核规则压着运营玩法。
立项时把约束清单逐项过一遍，通常能提前暴露三类风险：
- 玩法需要的包体或内存超出平台允许的量级，需要提前裁内容或换方案。
- 现有服务端接口的响应结构在弱网低端机上不可用，需要分页与瘦身。
- 运营规划的裂变、分享、诱导类玩法与平台审核口径冲突，需要换形态。
这些风险越晚发现，返工越贵。许多项目是在提审被驳回或真机闪退之后才回头补这些课，付出的往往是一个完整版本周期的代价。
首包预算如何牵动资源架构
小游戏的首包体积限制通常只有几 MB 量级，具体数值随平台版本调整，以平台文档为准。这个预算里要放下引擎运行时、启动逻辑、首屏界面和必要的协议定义，余量往往很紧。常见的应对是把几乎所有美术资源、关卡配置和玩法脚本放进分包与远程资源，首包只保留拉起游戏所需的最小集合。
首包预算的挤压效应会向整条链路传导：
- 协议描述文件、表格数据这类“小文件”也要争预算，往往催生更紧凑的编码与裁剪。
- 分包与远程资源的加载顺序、失败重试与校验逻辑成为客户端的核心模块。
- 服务端接口的响应体积被同一预算约束，列表类接口通常要分页并裁掉大字段。
一个常见的经验判断是：首包预算宁紧勿松。贴近上限的首包会在平台规则调整或引擎升级时突然装不下，而那时留给团队的往往只有紧急瘦身一条路。预留缓冲的成本很低，收益是长期的选择权。
内存上限与弱机分档
包体约束管的是下载，内存约束管的是运行。小游戏对运行内存有上限，不同机型的实际可用内存差异很大，低端设备上的上限往往明显低于旗舰机。内存超限的直接后果是宿主杀掉小游戏进程，玩家看到的是闪退，而且很难归因。
所以小游戏项目通常要做机型分档：按设备性能划分档位，低端档降低分辨率、裁减特效、限制同屏对象数量。分档策略要写成明确规则，而不是靠美术和程序现场讨价还价。另一条经验是内存验证只能在真机上做，开发者工具给出的内存表现与真机差距很大，高档真机的结果同样不代表低端机的现实。上线后把闪退率按机型分档统计，往往能在玩家大规模投诉之前发现某一档机型的内存问题。
域名白名单与网络链路
小游戏环境里，客户端只能访问平台后台配置过的白名单域名，且通常要求备案与加密连接。请求、长连接、上传、下载往往还要按类别分别配置。这套机制的工程含义很直接：漏配一个域名，对应的线上功能就整体瘫痪，而且问题只在提审通过、真机环境下才暴露。
常见的实践是把域名清单当成发布物管理：
- 域名清单纳入上线检查流程，与本次版本实际要访问的域名做对照。
- 提前在测试环境用真机走完整链路，覆盖登录、资源下载、长连接、支付回调每一环。
- 服务端证书链与加密要求提前验证，避免临提审才发现握手失败。
白名单还限制了架构上的随意性：临时加一个第三方数据源、换一个资源站点，都不能像普通网页那样即改即用。域名规划要在架构设计期就定型，把正式域名、备用域名、各环境域名一次性想清楚。
登录链路与会话设计
小游戏登录有一条平台特有的时序：客户端先从平台拿到一次性临时凭证，把它交给开发者服务端，服务端再凭凭证与应用密钥向平台换取用户身份标识，最后由服务端签发自己的会话。整条链路有几个反复被验证的要点。
- 应用密钥只能放在服务端，出现在客户端就等于公开。
- 临时凭证通常一次有效，服务端要做防重放，避免无效请求反复打到平台接口。
- 换来的身份标识只在当前应用范围内唯一，多端发行时的跨端身份锚点要在立项阶段确认，事后补救往往错过一整个运营周期。
- 游戏自己的会话与平台会话是两条生命周期，过期、续期、踢人逻辑要分开设计。
服务端换取身份的那一步是外部调用，要有超时与降级：平台侧偶发抖动时，玩家应该看到明确的提示与重试入口，而不是卡在登录页无限等待。登录接口还是并发热点，同一玩家重复点击与断线重连可能并发到达，身份解析逻辑通常要按幂等设计。
支付与虚拟商品的合规差异
小游戏支付最容易被低估的是平台间的规则差异。同一款虚拟商品，在安卓侧的支付通道、抽成与到账方式，和苹果侧的可行做法往往完全不同，不少产品在 iOS 环境下对虚拟支付只做受限处理或明确提示。这类差异不是技术能绕过的，方案要提前和发行、法务一起定。
技术侧的核心还是订单可信：
- 支付结果以服务端收到的平台通知为准，客户端的支付成功回执只用来做体验，不做发货依据。
- 通知处理要幂等，同一笔订单的重复通知不应重复发货。
- 掉单补偿依赖主动查单与定期对账，用户投诉“付了钱没到账”时，要有机制能定位这笔订单停在哪一步。
- 沙箱环境与正式环境的凭证、回调地址要严格分开，测试数据污染正式订单是很常见的低级事故。
开放数据域与借来的社交关系
小游戏平台提供好友关系与好友排行能力，但这些数据运行在隔离的开放数据域里，主域与开放数据域之间只能通过特定接口交换，不能自由通信。这意味着涉及好友排行的界面，通常要在隔离域内单独渲染，性能与交互都受限。
设计上值得先分清两类关系：平台好友关系来自开放数据域，是借来的、规则由平台定的；游戏内好友与社交关系应该建在自己的服务端，是自有的。排行榜设计要明确每一块数据用哪一类，避免把关键玩法建立在随时可能调整的平台能力上。借来的能力适合做传播与比较，资产与权益归属永远放在自己这边。
切前后台与重连体验
小游戏玩家切进切出的频率远高于原生应用：一条消息、一个电话都会把游戏切到后台，宿主可能随即挂起连接甚至回收资源。把“一段时间没心跳”当成掉线判定的服务端，在小游戏场景里会批量误杀这类会话，玩家切回来面对的是重新登录与状态丢失。
常见做法是让客户端在切后台、切前台时显式上报状态，服务端对后台会话进入宽限管理：宽限期内不释放会话资源，消息继续入队，切回前台后恢复并补发期间积压的数据；宽限期超时才真正断开。断线恢复则依赖序列号与快照的配合，客户端报出自己最后收到的位置，服务端补发缺口，缺口过大时直接下发全量快照。推送加拉取的双通道也是常见兜底：推送丢了，客户端回来还能主动拉到最新状态。
审核规则与提审节奏
小游戏平台的审核通常比应用商店快，但规则细且对玩法形态敏感。诱导分享、诱导下载、类目不符、资质缺失、内容违规是常见驳回原因。对技术团队的含义是：裂变活动、分享奖励、跳转引导这类功能，要在设计期就对照平台规则评估，而不是做完再赌审核。
提审节奏也有工程含义。小游戏迭代快，一周多审是常态，这反过来要求版本与配置体系支持高频发布：分包与热更承担大部分内容更新，让真正需要提审的代码改动尽量少。审核版本与线上版本、开发版本的环境隔离也要清楚，把未过审的功能提前放进线上配置，是很多运营事故的源头。
真机验证为什么不能省
小游戏开发者工具的运行环境与真机差异很大：内存模型不同、渲染管线不同、网络栈不同。工具里流畅的 demo，在低端安卓真机上可能掉帧明显，在部分机型上可能直接闪退。所以成熟团队的验收标准通常包括一组覆盖高中低档的真机用例，重点验证首屏时间、内存水位、切前后台恢复和弱网表现。
真机验证的成本不高，缺了它的代价却很集中：问题在上线后由玩家发现，归因困难，修复周期被平台审核再拉长一截。把真机环节固定在每次提审之前，是小游戏项目性价比最高的流程投资之一。
常见误区
- 把小游戏当成缩小版手游，套用原生项目的资源与网络方案，上线前才发现预算全对不上。
- 只在开发者工具里验证，真机内存与弱网问题全部留到线上暴露。
- 域名白名单靠记忆管理，漏配一个域名导致整条功能链路在提审后瘫痪。
- 把客户端支付回执当发货依据，缺少服务端通知、幂等与对账，掉单一出现就变成客诉。
- 把玩法建立在开放数据域等借来的能力上，平台规则一调整核心功能跟着失效。
- 用短心跳判定掉线，把切后台的玩家批量误杀，重连体验支离破碎。
小游戏平台的约束清单会随平台演进而变化，但约束的思维方式是稳定的：先确认硬边界，再在边界内分配预算，为借来的能力准备自建底线，为频繁的前后台切换设计恢复链路。把这四件事做在前面，小游戏项目的大部分平台事故都可以避免。
Used By
小游戏立项约束清单评审；小游戏化改造评估。
Related
关系链：立项过清单 → 首包预算 → 白名单与会话 → 开放数据域 → 真机验证。上游：platforms/01。下游：client/web/05（小游戏前端运行环境）。
Reference
本页为工程经验归纳。