小游戏平台与浏览器环境
Category
client / Web 前端。节点定位：小游戏不是 H5 页面——App 内置环境的运行模型、包体与分包、生命周期、社交能力与合规的对照表。
Definition
小游戏平台（微信小游戏为代表）把「点开即玩」做成了默认形态：没有安装、没有 URL、靠社交链路分发。它运行在 App 内置环境里，不是完整浏览器——开发模型与 H5 页面有实质差异。本页讲清运行环境、包体与生命周期；平台运营与渠道视角见第 15 章《平台生态、渠道与 SDK》。
Problem
拿 H5 直觉做小游戏会在四处撞墙：没有完整浏览器 API（DOM/BOM 缺失）、包体与分包有硬上限、切后台生命周期不同（音频与定时器的暂停语义）、社交与合规是平台强制的（开放数据域隔离渲染、实名防沉迷）。这些差异是开发模型级的，不是兼容性小坑。
小游戏不是 H5 页面
浏览器里跑 H5 游戏，JS 可以访问完整的 DOM、BOM 与各种 Web API；小游戏环境刻意裁掉了这些——没有 DOM、没有 window/document 的完整能力、没有跳转任意 URL 的入口。平台提供一个薄适配层：给一块画布（Canvas）、基础文件系统、网络与音频接口，引擎（如 Cocos Creator）在这层适配之上工作。对开发的直接含义：
- UI 与渲染走引擎或 Canvas，不存在「抄个 DOM 组件」的捷径——第三方库要确认无 DOM 依赖
- 每个平台一套适配层：跨平台框架的价值就在这里，但适配层的 API 覆盖度与平台一致性要按平台实测
- 浏览器特有的能力（如部分调试工具、桌面特性）在平台内不可用，调试要在平台开发者工具里做
包体、分包与首屏
小游戏对包体有硬性上限，且主包与总包的上限不同、随平台版本调整（以平台当前文档为准）。工程上的应对是一套固定的三板斧：
- 主包只放首屏必需：启动场景、核心脚本、最小资源；主包越小，首屏进入越快，转化率越高
- 分包按玩法与场景切：资源与逻辑按模块下放，运行时按需加载——分包粒度就是「玩家第一次等待」与「运行中加载次数」的平衡点
- 远程资源承接溢出：超出总包上限的资源走 CDN，配合第 8 章 03 页的加载预算与生命周期管理
包体治理要在立项期定资源分组规范，发布前的「包体瘦身周」通常已经是返工。
生命周期与切后台
小游戏的生命周期由平台事件驱动：启动、前台（onShow）、后台（onHide）、销毁。切后台时渲染循环暂停、网络可能断开——这正是教程 03「切后台误判掉线」案例的场景来源。工程要点：onHide 时保存关键状态与暂停计时器（用游戏内时钟而非墙上时钟，避免回前台时「被扣了一夜体力」）；onShow 时校验会话与增量拉取；任何「回前台立即全量重连」的策略都要先过会话幂等这一关（见第 15 章的会话与鉴权页）。
与浏览器环境的差异对照
| 维度 | 浏览器 H5 | 小游戏平台 |
|---|---|---|
| 宿主 | 完整浏览器 | App 内置环境 + 适配层 |
| DOM/BOM | 完整可用 | 基本不可用 |
| 入口 | URL 分享/搜索 | 社交链路/平台中心 |
| 存储 | Cookie/LocalStorage/IndexedDB | 平台键值与文件接口，容量有限 |
| 网络 | 自由请求 | 平台接口，域名需在平台登记 |
| 音频 | 自动播放受限 | 首次交互后解锁，接口各异 |
| 分发与登录 | 自建 | 平台身份与好友关系 |
存储与网络的差异最容易被低估：键值存储容量小、同步接口为多，拿来存配置与进度可以，拿来当数据库不行（对照第 11 章《数据建模与数据库》的边界）；网络域名不登记直接白屏，是联调期最高频的坑。
社交能力与合规
小游戏平台的独特价值是社交链路：好友排行、群挑战依赖平台的开放数据域机制——好友关系数据在隔离环境中渲染，开发者拿不到明细、只能按平台接口展示。这是「排行榜即增长」玩法的技术前提。合规侧，实名、防沉迷、概率公示等要求在平台内是强制的，接平台能力即接合规（对照第 17 章《安全、风控与合规》）。
常见误区
- 按 H5 习惯写小游戏：DOM 思维的 UI 方案、无分组的资源引用，到了平台环境全线返工
- 主包塞满：首屏资源不加节制，进入转化率直接受损
- 切后台不处理：计时器走墙上时钟、回前台不做状态校验，工单与刷资源漏洞一起来
- 把平台存储当数据库：容量与同步模型都不支持，玩家进度丢失的工单就是这么来的
- 忽略审核周期：小游戏版本同样要过平台审核，发版节奏要把审核时间算进去
实战案例：一次「H5 搬进小游戏，首屏白屏 8 秒」的移植排查
案例为教学示例（非摘自真实项目），数字经过取整简化。它把本页「小游戏不是 H5 页面」「包体、分包与首屏」「生命周期与切后台」用到深水区：拿 H5 直觉过平台，四处撞墙一起爆——这是移植欠账的归因排查，也是「三板斧治包体」的完整展开。
背景与现象：H5 游戏移植微信小游戏：首屏白屏 8 秒，进入转化率 41%（同类产品 68%）；主包 7.8 MB，超出当期主包上限（4 MB，以平台文档为准）近一倍；联调期 5 个接口域名未登记直接白屏；上线两周「挂后台一晚被扣一夜体力」工单 130 条。
第一步：现象与口径——把白屏、包体、生命周期三本账分开对
环境口径：第三方库 26 个里有 7 个带 DOM 依赖，平台环境裁掉了 DOM，运行即抛错白屏——平台不是 H5 页面，不存在「抄个 DOM 组件」的捷径。
包体口径：主包 7.8 MB 里，未压缩音频 3.1 MB、未分组纹理 2.4 MB——首屏必需的只有启动场景与核心脚本，两块都不是。
生命周期口径：计时器走墙上时钟，挂后台不暂停；回前台不校验会话、不做增量拉取，130 条工单全是同一形态。
第二步：分层归因——按本页常见误区清单比对
移植事故归因 占比
按 H5 习惯写小游戏，DOM 依赖库没清 38%
主包塞满，资源分组没在早期定 34%
切后台不处理与域名漏登记 28%逐项比对：7 个 DOM 依赖库正中「按 H5 习惯写小游戏：DOM 思维的 UI 方案、无分组的资源引用，到了平台环境全线返工」；3.1 MB 音频加 2.4 MB 纹理正中「主包塞满：首屏资源不加节制，进入转化率直接受损」；130 条体力工单正中「切后台不处理：计时器走墙上时钟、回前台不做状态校验，工单与刷资源漏洞一起来」。
第三步：根因——移植被当成「换个打包目标」，环境差异是开发模型级的
项目把移植排期成两周的「适配期」，实际按 H5 直觉做小游戏会在四处撞墙：没有完整浏览器 API、包体与分包有硬上限、切后台生命周期不同、社交与合规是平台强制的——这些是开发模型级的差异，不是兼容性小坑。资源分组规范到发布前才补，本页提醒的发布前「包体瘦身周」通常已经是返工，这个项目把它整周活成了现实；网络域名登记清单没人管，联调期最高频的坑全踩了一遍。
第四步：处置与回填——三板斧加一张清单
- 清 DOM 依赖：7 个带 DOM 的库替换或封装掉，第三方库入库前先确认无 DOM 依赖；7 → 0 个。
- 包体三板斧：主包只放首屏必需，玩法与场景切分包，溢出走 CDN；主包 7.8 → 3.2 MB，首屏白屏 8 → 1.9 秒。
- 域名登记：平台侧域名清单随构建流程核对，漏登 5 → 0 个。
- 生命周期修正：onHide 存状态并暂停计时器（游戏内时钟），onShow 校验会话与增量拉取；体力工单 130 → 0 条。
复核账：主包 7.8 → 3.2 MB；首屏 8 → 1.9 秒；进入转化率 41% → 63%；DOM 依赖库 7 → 0 个；漏登域名 5 → 0 个；体力工单 130 → 0 条。
回填清单：
| 回填项 | 动作 | 回填处 |
|---|---|---|
| 环境差异对照 | 第三方库无 DOM 依赖入库前必查，调试进平台开发者工具 | 小游戏不是 H5 页面 |
| 包体三板斧 | 主包只放首屏必需、分包按玩法切、远程承接溢出 | 包体、分包与首屏 |
| 生命周期协议 | onHide 存状态停计时器，onShow 校验会话增量拉取 | 生命周期与切后台 |
| 平台登记清单 | 网络域名随构建核对，存储只当存储不当数据库 | 与浏览器环境的差异对照 |
案例的三个教训
- 小游戏不是 H5 页面——DOM 思维的库与方案，到平台环境全线返工。
- 主包越小，首屏进入越快，转化率越高——资源分组在立项期定，瘦身周通常已是返工。
- 计时器走游戏内时钟——墙上时钟加切后台不处理，工单与刷资源漏洞一起来。
Used By
H5 游戏移植小游戏平台的评估（工作量清单）；包体规划（主包/分包/远程资源）；平台合规接入（实名、防沉迷、概率公示）与开放数据域设计。
Related
关系链：运行环境 → 包体与分包 → 生命周期 → 环境差异 → 社交与合规。上游：引擎构建链（web/03）。下游：database/cache/04（远程资源与 CDN）、industry 树的平台生态（industry/platforms）。
Reference
各小游戏平台（微信/抖音/支付宝等）以官方文档为准；本页其余为工程经验归纳；页内实战案例为教学示例（数字取整简化）。