小游戏做不出来，多半不是引擎选错了
三个月，一个能跑的小游戏，最后卡在提审。
代码没写错，玩法也完整，测试同事玩了十几分钟没崩。卡住它的是四件事：首包超了 1.2MB、好友排行榜渲染不出来、用的一张背景图没有商用授权、以及后台资料里「游戏类目」填错了。
这四件事，没有一件跟「引擎选得好不好」有关。
有人问过我一个很实在的问题：想做个微信小游戏，到底该用 Cocos 还是 Unity，或者干脆原生写？我翻完一份 170 个项目的开源清单之后，答案变成了另一句话——
引擎的选择决定你写得顺不顺手；平台的四道闸，决定你做的东西能不能出现在别人手机里。
一、一份清单照出来的尴尬
这份清单收了 170 个微信小游戏相关仓库，来自 16 个技术社区，作者标称核实了 220 多个仓库，分成 7 组：官方示例、引擎适配、完整游戏、源码合集、服务端与工程化、逆向类、以及 2026 年的个人新项目。
把它按 Star 排一遍，你会发现注意力全堆在同一个地方：Cocos 引擎、白鹭、LayaAir、Phaser、Three.js 适配层——这些教你怎么把画面渲染出来的项目，动辄几千星。
再看另一头：监控、CI、发布、异常上报这些「配套」项目，Star 数普遍只有几百，甚至个位数。
但项目死掉的地方，恰恰在另一头。
一个人做小游戏，前两周通常很顺：模板跑起来了，角色能动，分数能加。第三周开始卡，卡的不是渲染，是「怎么让别人也能玩到」。这一步需要的不是更漂亮的精灵图，是一串很枯燥的工程动作。
生态里最热闹的地方，是教程最多的地方；项目最常死的地方，是教程最少的地方。
二、真正卡人的四道闸
第一道：首包 4MB
微信小游戏的主包有明确体积限制（长期规则是 4MB，具体数值以官方最新文档为准）。这不是建议，是硬门槛：超了就是上传失败，连提审的机会都没有。
于是问题从「怎么把游戏做出来」变成「怎么把游戏塞进 4MB」。答案只有两个：分包，和把资源放到 CDN 按需加载。
这两件事都不难，但都必须在第一天就设计进目录结构。等到素材堆到 30MB 再回头拆，等于重做一遍资源管线。用 Unity 转小游戏的项目更容易踩：官方转换插件会把原有工程直接放大，照搬示例的资源组织方式，第一次打包就超。
所以判断一个教程靠不靠谱，有个很快的办法：看它有没有一开始就讲分包。只讲渲染、不讲分包的小游戏教程，基本可以判定作者没真正上线过。
第二道：好友排行榜
这是微信小游戏最容易被低估的一块。
排行榜不是「画一个列表」那么简单。它跑在一个独立的 JS 上下文里，叫开放数据域，只能用一块专门的共享画布渲染，不能直接读主域的数据，也不能用普通的 DOM 那套。
官方给了一个轻量的 Canvas 引擎专门解决这个场景，也有几个开源的最小实现，整个子域只有十几 KB，比引擎自动生成的几百 KB 省得多。
但如果你用的引擎版本较老，或者照抄了 2018 年的项目，很可能会遇到同一个报错：接口不存在。
排行榜是那种「不做也能玩、做了才算完整」的功能，也正好是最容易在最后一周才想起来的功能。
第三道：素材版权
清单里最值钱的一句话，不是任何一个仓库地址，而是这句：
代码开源，不等于素材开源。
一个仓库可以标着 MIT，代码随便用；但里面的角色图、背景音、字体，往往是作者从别处找来的，授权状况完全不同。清单里专门点名了几个坑：有的项目代码是 Apache-2.0，但素材明确禁止商用；有的项目干脆没有任何 LICENSE——在法律上，没有许可证等于「保留所有权利」，不是「随便用」。
还有一个更隐蔽的：GPL 类协议有传染性，接进商业项目会把你的代码也拖下水。
这件事的成本不在钱，在时间。等美术资源全部铺完、包也打好了，再回头换素材，前面的排版、动效、甚至关卡设计都要跟着改。
第四道：提审与备案
资料填写、类目选择、隐私协议、内容合规——这些听起来是行政工作，实际是产品设计的一部分。
比如「游戏类目」选错，会被打回重填；比如涉及用户信息，隐私政策必须能对应到实际采集的字段；比如国内上线的服务端如果涉及备案，时间要以周计，不能等最后一天才想起来。
这些闸门的共同点是：它们不在代码里，所以不会在本地测试时暴露。
三、这份生态其实分六层
把 170 个项目按「在工程里承担什么职责」重新排一遍，会比按 Star 排清楚得多。
| 层 | 职责 | 判断标准 | 典型落点 |
|---|---|---|---|
| L0 平台约束 | 首包体积、分包、开放数据域、审核备案 | 不满足就无法上线 | 官方分包文档 |
| L1 官方基线 | 平台自己维护的骨架与类型 | 是否仍在维护 | 官方示例、类型声明、轻量 Canvas 引擎 |
| L2 引擎与适配 | 渲染、场景、跨端抹平 | 存量技术栈 + 是否要 3D | Cocos、LayaAir、Godot 导出、Three.js 适配 |
| L3 可运行工程 | 抄结构、找玩法 | 能跑起来比写得好重要 | 跳一跳类复刻、官方教程工程 |
| L4 上线配套 | 服务端、排行榜、监控、CI、发布 | 决定能不能上线 | 异常监控、上传助手、跨端 API 抹平 |
| L5 AI 闭环 | 构建、预览、读日志、提审 | 是否真的闭环 | 调试 MCP、发布 Skill |
这张表最有用的一列不是「典型落点」，是「判断标准」。
因为清单会过期——Star 会变，仓库会停更，新的引擎会冒出来。但判断标准不会过期：这一层的东西，是在帮我满足平台约束，还是在帮我省自己的事？
L2 是省自己的事，所以可以自由替换。L0 和 L4 是满足平台约束，所以只能照做。
选型的顺序错了，越努力越远：先挑引擎再补配套的人，最后都在补同一批课。
四、2026 年的新变量：AI 工具链自成一整层
这份清单里最值得注意的，不是哪个引擎星多，而是第五组里突然出现的一整串新项目。
它们干的事高度一致：把「构建 → 预览 → 读日志 → 提审上架」交给 Agent。
有让 AI 直接调试小游戏的：截图、模拟触控、读控制台日志、一键重开。有把 Cocos 编辑器自动化、直接拼场景并触发构建的。有把整个仓库交给 Agent，按上架经验自动走完注册、资料、提审步骤的。还有在 Web 界面里预览、截屏、真机预览并发布的插件。
配套地，引擎侧也开始「为 Agent 设计」：有的新引擎在仓库里直接放一份给大模型看的 API 说明，有的用声明式界面把 UI 变成可校验的契约。
这里有个很实际的判断标准：能不能看见效果，决定这套 AI 工具链是真闭环还是假闭环。
只让 AI 写代码、不让它截图看结果的，等于闭着眼睛改代码。写完能自己跑起来、截图、读报错、再改——这才叫闭环。清单里那几个带调试能力的项目，价值不在「AI」两个字，在于它们补上了这条反馈回路。
顺带说一句成本：这套东西目前几乎全是免费的，主要成本是你的时间——把一个项目的构建和预览链路跑通，大概需要半天到一天；之后每改一版，省下的是重复点击的那些分钟。
五、按目的选型，而不是按热度
清单原文给了 8 条按目的组合的路径，我把它压成 4 条，够覆盖大多数情况：
只想跑通一个原生小游戏。 官方示例起步，配官方轻量 Canvas 引擎，再加一个完整的小工程当参照。不要一上来引第三方引擎，多一层就多一堆适配问题。
要正经上线一个 2D 游戏。 主流引擎打底，官方类型声明保证接口对得上，再配工作流模板、排行榜方案、异常监控、上传助手、登录分享广告模板。后面这几样缺一个，就会多一段手工流程。
手里已有 Unity 项目。 走官方转换链路，先读分包文档，再考虑自动化上架。存量工程的体积问题比新项目严重得多。
想学联机。 官方帧同步示例 + 房间服务器 + 一个完整联机工程，三个都要看，少一个就拼不起来。
这四条路径的共同点是：先定约束，再挑工具。反过来做，就会在第二周发现选的引擎不支持某个平台能力，然后开始改架构。
六、三条硬规则，比清单更耐用
清单会过期，这三条不会。
第一，先看许可证，再看素材。 没 LICENSE 等于保留所有权利；GPL 有传染性；代码开源不代表图片、音效、字体可商用。素材是独立的版权客体，要单独核。
第二，别把小程序和小游戏混着叫。 小程序是页面体系，小游戏是 game.js 加 Canvas 运行时。构建产物、开放数据域、广告组件全都不同。中文社区长期混用，照着一个「小程序」教程做小游戏，第一步就会走错。
第三，年份就是风险。 2018 到 2019 年那批项目，基于的是 Cocos Creator 1.x/2.x 和旧基础库，用户信息、共享画布、子域字段这些接口后来都变过。搜得到，不等于能用。
七、这份清单的正确用法
不是收藏，是排错。
我的建议顺序是倒着来：
先问 L0——首包预算多少、要不要排行榜、素材从哪来、提审资料谁来填。这四个问题答不出来，先别选引擎。
再问 L4——上线要用的监控、CI、发布链路有没有现成的。没有就先挑，别等做完再找。
最后才看 L2——在你剩下的约束里，哪个引擎最省事。
这么走一遍，大概率会发现一个反直觉的结论：引擎之间的差距，远小于「有没有提前想清楚这四道闸」的差距。
所以回到开头那个问题。Cocos 还是 Unity，还是原生写？
正确的问法是：你的首包还剩多少空间、排行榜要不要做、素材授权清了没有、提审资料准备好了没。这四个答案定了，引擎自己就浮出来了。
小游戏的门槛不在渲染，在交付；把交付想清楚，剩下的都是熟练度问题。
你手上如果有正在做的小游戏，不妨先算一下首包还剩多少——那个数字，比任何引擎评测都更能说明你现在的处境。也欢迎在评论区说说你卡在哪一道闸，我看看是不是同一个坑。
相关阅读
来源与说明
- 项目数量、分组、Star 与更新时间等数据，来自一份 2026 年 11 月的公开开源项目盘点（作者自述核实 220 多个仓库，部分条目为社区页面快照，未经接口复核）；本篇只引用其结构与判断，不复制原文表述。
- 首包体积、开放数据域等平台规则以微信官方最新文档为准，本篇写作时为 2026 年 11 月。
- 许可证的法律含义为通行解释，具体项目请以其 LICENSE 文件与实际授权说明为准，不构成法律意见。