《移动游戏产品的架构·商业化与发行工程》前言：卷三的双案例、实验工程与阅读路径

为什么还要一本商业化书

站内已经有不少与商业化相关的散篇：支付接入、广告变现、买量归因、活动运营。它们各自解决一个点，但很少回答一个更基础的问题：这些点应该按什么顺序连起来。

卷三的目标不是再讲一遍 SDK 怎么接，而是给出一条可以评审的链：每个环节输入什么、输出什么、失败时谁负责、用什么证据证明它工作正常。

因此本卷更关心状态、口径与边界，而不是某个平台的后台按钮在哪里。

双案例设定

两款产品同属「潮汐」IP，共用一个发行中台：

数字的用途是对照，不是预测。它们全部是案例设定值，完整表格与口径见附录 B。

两款产品的差异决定了侧重点：消消的广告与买量占比高，问题集中在归因、频控与广告作弊；方舟的客单价高、订单少，问题集中在支付风控、退款与对账。

mga-biz-lab 实验工程

每节配一个可运行的 TypeScript 产物，统一放在实验工程 mga-biz-lab 中：

mga-biz-lab/
├─ src/biz/          # 收入、账号、渠道、支付、订单、广告、归因、风控、运营、埋点、推送、合规
├─ src/lab/          # 商业化基线、指标矩阵、评审门禁
├─ src/release/      # 发行清单与上线门禁
└─ test/             # 与 src 镜像的 node --test 用例

工程约束：

• Node 26 原生类型剥离，零第三方依赖，只用 node: 内置模块。
• 禁用 enum、namespace、参数属性与装饰器。
• 每个产物自包含，不跨章节 import。
• 测试使用 node --test，每节 6–10 条用例。

正文中的代码块与工程文件逐字节一致，代码块开头三行是：

// file: <产物路径>
// tier: L1
// verify: node --test <测试路径>

这三行不是装饰，而是让读者能把文章里的代码直接还原成可运行文件，并用同一份测试验证。

代码能证明什么，不能证明什么

实验工程能证明的是规则自洽：订单状态机不会把「已发货」退回「待支付」，归因去重不会把同一安装算两次，活动库存不会超发。

它不能证明的是外部系统行为：渠道后台的真实回调、商店审核的实际标准、广告平台的填充率、归因平台的数据延迟。这些只能通过对接、压测与线上观测验证。

所以本卷的写法是：能用代码固定的规则写成测试，不能固定的部分写成检查清单与观测口径。

三种阅读路径

商业化负责人：第 1、4、5、6、7、9、13 章。先看收入结构与单位经济，再看支付、订单、广告与买量，最后用 LiveOps 与收口矩阵检查闭环。

发行与渠道工程：第 2、3、4、11、12、13 章。重点是账号标识、渠道 SDK、包体构建、推送深链与合规材料。

数据与风控：第 1、5、7、8、10、13 章。先统一口径，再处理归因、作弊与埋点质量。

三条路径在第 13 章汇合。收口章给出指标矩阵与评审门禁，用来判断这条链是否真的闭合。

与前后卷的边界

• 卷一《客户端与移动运行时》负责客户端内部结构与运行时约束，本卷只在账号、支付、广告 SDK 的生命周期处引用其结论，不重复展开。
• 卷二《网络、资源与热更新》负责协议、连接、资源与热更，本卷在归因回传、推送到达与支付回调处引用其网络结论。
• 卷三不写服务端架构细节，也不写品类数值设计；它只写客户端与中台之间的商业化契约。

与站内其他书稿的分工：

• 《游戏服务端架构》《MMO 服务器开发》负责服务端拓扑与协议内核，本卷不重复。
• 《小游戏开发实战》负责小游戏平台与买量生态，本卷只写原生移动产品的渠道与商店。
• 《SLG 游戏产品设计》负责品类与经济系统，本卷不写数值设计。

写作约定

• 每节结构固定：问题 → 判断规则 → 可运行产物 → 双案例对照 → 边界与代价。
• 正文数字只引用附录 B；出现第二套数字即视为错误。
• 涉及平台政策时只写通用口径，不冒充最新条款；上线前必须以平台当期文档为准。
• 所有「应该」都尽量给出可检查的证据：状态、字段、测试或清单。

一个使用建议

读第一遍时，可以先跳过代码块，只看每节的问题、规则与对照表。读第二遍时，再打开代码与测试，确认规则真的能跑。

商业化问题往往不是「不知道怎么做」，而是「以为已经做了」。代码与测试的作用，是把「以为」变成「可以指给你看」。