微信小游戏生态与立项约束

玩法已经能在开发工具里运行，你计划下周正式上线并接付费。到了后台才发现，主体、材料和能力状态与预想不同。为什么原型跑通，还不能推出商业化路径成立？

公开资料复核日期：2026-10-31。未访问你的账号后台。 本篇帮助你把平台条件转成早期产品选择，具体资格和可用能力仍以适用原文与后台为证。

为什么要把“能做”拆成几个状态

能注册、能预览、能提交、能发布和能变现，检查的是不同条件。把它们合成一个“微信支持”，就会在最晚、投入最多的时候发现依赖未成立。

微信把小游戏放在小程序体系的相应类目中，开发应从 小游戏指南 进入。普通小程序的页面模型与能力不能直接套用。先列本产品实际需要的能力，再逐项查账号条件，才知道是否必须调整范围。

产品假设	应核对的证据	为什么会改变范围
这个主体能正式运营	类目、注册与实际发布材料	原型可运行不保证可商业化
广告或付费能支撑收入	开通条件、协议与后台状态	未确认收入不能承担固定支出承诺
玩家能从目标入口到达	实际入口、分享与渠道能力	调起分享不代表送达或新增
设备能顺畅表达玩法	目标机型与加载、运行记录	开发机顺畅不能替代低性能测试

能力清单用已确认、待确认、不适用，并附文档、后台日期和责任人。费用、分成、审核时限与激励政策变化较快，本篇不把无账号依据的数字写进通用计划。

一个付费选择，为什么要在立项时看

复核的 IAA 指引把当前及未来不需要虚拟支付列为对应选择；IAP 指引列出出版物号核发单、软著及相关授权等材料路径。

因此不能为了先提交随意选择，再把未来付费当作无条件选项。先明确商业模式依赖哪条路径，保留材料与账号状态；若未确认，玩法原型可以继续研究，正式商业计划则保留关键未知。这是材料依赖的推导，不是断言某一主体必然能或不能走某条路径。

版本审核指引还把版本审核与小程序备案分别列为发布条件。两个状态解决不同问题，所以清单需单独记录，不能用一个审核勾选替代。

为什么入口与性能属于产品设计

玩家从分享、内容或历史入口进入，带着不同预期，可能落到不同关卡。下载、授权和拉取都发生在首次价值之前；如果这里大量退出，继续改关卡未必触及原因。

建立目标设备矩阵，记录启动、帧率、内存、发热和后台恢复，质量目标写成能体验、能验收的条件。具体约束查 性能指南，不把引擎调参细节混进玩家流程。

从依赖关系推导推进顺序

适用边界：公开文档不是账号授权

本文的读取不代表登录、注册、提交或开通，也不保证某系统、地区、协议版本都相同。公开原文甚至可能仍描述历史流程，实际计划应继续核对当前后台与适用接口。

练习：从 官方介绍 和 运营入口 核对自己的能力表。每个未知都写：不成立会影响什么、什么替代仍能验证玩法，再进入 上线清单。