企业官网建设流程全解析

入行这些年，经常有人跑来问我：想做个小游戏，到底该怎么入手？是先学代码还是先学引擎？是直接开发成App还是做成H5页面？微信小游戏火了之后，问题又变成：小游戏到底算不算H5？用Unity做的游戏能不能搬上去？这些问题问得多了，我就想干脆写一个系列，从零开始把微信小游戏从概念到落地聊透。这篇是第一篇，不聊躁技术，先把一个最基础但也最容易被忽略的问题讲明白：微信小游戏，到底是个什么东西。

这篇内容适合三类人看：一是完全没有接触过小游戏、想入行的新手；二是做过Web开发、想了解小游戏和H5本质区别的前端工程师；三是已经用Unity做了游戏、想多端发布但又对微信小游戏一头雾水的客户端开发者。看完你至少能判断自己该走哪条路，也能听懂后面实战文章里的技术词。

1. 微信小游戏：定义、运行环境与本质

1.1 它到底运行在哪

先把定义说准确：微信小游戏本质上是一种特殊类型的小程序，运行在微信客户端内部。它不是一个独立的App，不通过应用商店下载，而是用户扫个码、点个链接、搜一下，就直接在微信里打开。它在系统中的定位，是一个“免安装的轻量程序”。

很多人会把它和网页游戏划等号，这个理解不完全对。微信小游戏虽然也用JavaScript和TypeScript这类Web语言来写，渲染也依赖Canvas和WebGL，但它运行的环境并不是标准浏览器。你可以把它理解成一个“微信定制版浏览器”加一层微信API：底层是微信提供的JavaScript引擎和渲染能力，上层开放了wx这个全局对象，里面有创建画布、播放音频、获取设备信息、分享好友、拉起支付等一整套接口。

这套环境和标准浏览器的差异很关键。比如你在网页里写document.createElement('canvas')是常规操作，但在小游戏里没有DOM可用，正确姿势是调用wx.createCanvas()。很多从Web转过来的同学第一周都在改这种习惯。可以理解为：微信小游戏借了Web开发的壳，但换了一套内脏，所有能力都围绕微信的生态来开放。

1.2 它和H5游戏、原生App的关键差异

把三个选项放在一起对比，很多取舍就看得清楚了：

从表里能看出微信小游戏的核心定位：它牺牲了一部分上限（性能不如原生、包体受限），换来了极低的使用门槛和极强的社交传播能力。用户不用下载，点了就能玩，玩完顺手分享到群聊，这个传播链路是很多独立开发者最看重的东西。

1.3 包体限制、审核与内容边界

微信小游戏和普通小程序走的是同一套注册、审核、发布机制。新手上线前一定要知道几条硬约束：小游戏主包默认限制在2MB以内，超过部分需要通过分包机制来扩展；整个小游戏的总包体上限会更大一些，但资源加载基本要走网络请求。代码包、图片、音频、引擎库，全部算进这个额度里。

正是这个包体限制，直接催生了一套“首包越小越好、资源全部外链”的优化思路。很多人第一次用Unity做小游戏，导出个WebGL包动辄二三十MB，顺手往微信开发者工具里一拖，立刻傻眼。所以“unity微信小游戏打包”才会成为一个专门的技能方向，它要解决的不是“能不能导出来”，而是“怎么把大包瘦身、怎么把资源拆出去流式加载、怎么让游戏在2MB的硬约束下跑起来”。理解了包体限制，你才算真正迈进了微信小游戏的世界。

2. 开发方式：原生代码还是游戏引擎

2.1 原生JavaScript开发：小体量游戏最快上手

我最早接触小游戏时，走的还是原生JavaScript路线。微信小游戏要求必须有入口文件game.js，项目描述文件game.json，其它代码模块可以随意组织。一个最简的“触摸画点”游戏，核心代码就这么点：

// game.js 微信小游戏入口文件 const canvas = wx.createCanvas() const ctx = canvas.getContext('2d') ctx.fillStyle = '#4a90d9' ctx.fillRect(0, 0, canvas.width, canvas.height) wx.onTouchStart((e) => { const touch = e.touches[0] ctx.beginPath() ctx.arc(touch.clientX, touch.clientY, 12, 0, Math.PI * 2) ctx.fill() })

对应的game.json也很直观：

{ "deviceOrientation": "portrait", "showStatusBar": false }

deviceOrientation决定横竖屏，showStatusBar控制是否显示系统状态栏，这两个字段是每个小游戏项目最早要定的事。

原生JavaScript适合做什么？答案很简单：玩法轻、逻辑简单、美术资源少的项目。答题类、文字类、简单的消除类、音游类，都可以用原生代码搞定，而且上手成本最低，不需要学额外引擎。但坏处也很明显：渲染、碰撞、动画、资源管理、音频播放全部要自己写，游戏逻辑稍微复杂一点，代码量就指数级上升。那时候你就会明白，引擎不是给懒人用的，是给想活命的人用的。

2.2 游戏引擎方案：Cocos、Laya与Egret

在小游戏生态里，国内开发者最常用的引擎是Cocos Creator、LayaAir和Egret（白鹭）。这几个引擎有一个共同点：都内置了微信小游戏的导出能力，开发时用编辑器搭场景、写组件逻辑，打包时一键生成微信小游戏工程，省去了大量底层工作。

以2D休闲游戏为例，Cocos Creator是目前生态最成熟的选择，社区教程多、插件丰富、性能表现稳定；LayaAir的优势是更贴近TypeScript开发习惯，适合脚本能力强的团队；Egret早年很火，但近几年的维护节奏慢了一些。选哪个不完全是技术问题，更多是团队熟悉度的权衡。

如果你已经有Unity基础，而且做的是3D游戏、中度偏重度的玩法，这几个2D引擎可能不太够用，这时候就看下一条路。

2.3 Unity打包微信小游戏：重度项目跨端首选

近两年“unity微信小游戏打包”成了热门搜索词，背后有一大批Unity开发者把游戏搬上微信生态。为什么大家愿意费劲折腾？核心原因就一句话：团队已经用Unity做完了游戏，不想再花半年重写一遍。

Unity导出的WebGL产物本来就能跑在浏览器里，理论上也接近小游戏环境，但微信小游戏不是完整浏览器，很多API没法直接用。于是微信官方提供了一套适配方案：把Unity WebGL的产物转换成微信小游戏工程，再通过一个适配层把WebGL调用映射到微信的WebGL接口、把文件加载映射到本地缓存和网络请求、把音频输入输出映射到wx的音频接口。

用生活类比的话，Unity就像一家做好的餐厅，WebGL是餐厅做的标准化食材包，微信小游戏适配层则是专门为你准备的餐具和上菜流程——食材还是那些食材，但端上桌的方式必须符合微信的规矩。理解了这层原理，后面遇到适配层报错、API不生效之类的问题，你就知道该往哪个方向排查。

3. unity微信小游戏打包：从工程准备到真机测试

3.1 Unity端的前置设置

先说结论：如果你要用Unity做微信小游戏，建议使用Unity 2021 LTS或更高版本，这个区间对WebGL的支持比较稳定。安装Unity时记得在Hub里勾选WebGL Build Support模块，否则导出列表里找不到WebGL选项。

打开项目后，通过Build Settings把平台切到WebGL，然后进Player Settings做几项关键配置：

• Publishing Settings下的Compression Format，建议选Brotli，压缩率高，微信侧也支持对应解压；
• Other Settings里的Memory Size，我一般按实际项目需求设置，休闲游戏256MB通常够，复杂3D项目建议改到512MB，宁可多预留也别让用户玩到一半闪退；
• 开发模式下可以不勾选Development Build，但调试阶段建议开启，方便看报错。

此外，项目的输出路径不要带中文字符，否则构建工具经常会出现一些莫名其妙的问题。这个细节容易被忽略，一旦踩中，报错五花八门，排查起来费时费力。

3.2 导出WebGL包并转换为小游戏工程

Unity端设置完毕，先正常执行一次WebGL Build，生成一份标准的WebGL产物。拿到产物之后，第二步才是微信小游戏的关键操作：使用微信官方提供的Unity小游戏适配工具，把这份WebGL产物转换成一个可以直接被微信开发者工具识别的小游戏工程。

这个过程大致包括以下几个环节：

1. 在Unity中导入官方的Unity WebGL适配插件；
2. 配置首包资源和CDN地址，大体积数据文件都放到你自己的服务器或CDN上；
3. 执行转换，生成带有game.js、game.json以及适配层代码的小游戏工程目录；
4. 用微信开发者工具打开转换后的目录，检查控制台输出，确认适配层初始化成功。

这里有两个实测经验。第一，CDN一定要提前准备好，而且必须支持HTTPS和跨域请求，否则真机上资源加载会直接失败。第二，建议把首包压到极致，本地只保留启动引擎所需的代码和加载逻辑，其余游戏数据全部走网络加载，这样用户点开游戏后很快能看到loading画面，而不是白屏等半天。

3.3 微信开发者工具里的强制配置

转换完成后，小游戏工程里有几个关键文件：入口game.js会去加载Unity生成的loader和启动逻辑；game.json里可以配置横竖屏、是否显示状态栏、网络超时时间等；privacy.json或对应的隐私设置需要在开发者后台同步配置，微信对用户隐私保护管得越来越严，这一步不能省。

打开微信开发者工具，导入工程后先看Console面板。正常启动时，Unity的WebGL初始化会有一系列输出日志，比如版本号、启动时间、资源加载进度。如果Console里一片空白，说明适配层都没执行到，优先查入口文件路径和game.json配置；如果出现红色报错，最常见的就是资源404、CORS跨域被拦截、Brotli解压失败，这些问题都能在Network面板里定位到。

调试阶段强烈建议开启vConsole，它是微信开发者工具里集成的移动端调试面板，真机上可以直接看到console输出和网络请求。很多只在开发者工具里正常、真机就黑屏的问题，靠vConsole才能抓到真实原因。

3.4 真机预览与性能评估

不要只在开发者工具里测试，它模拟不了真实手机的CPU频率和内存上限。正确流程是：开发者工具里确认编译无误后，点“预览”生成二维码，用手机微信扫码进入真机环境跑一遍。

重点观察三项指标：启动时长、帧率、内存走势。启动时长和首包大小、CDN速度直接相关，用户朋友圈里分享出来的游戏，三秒内看不到画面就很容易流失；帧率需要结合游戏复杂度评估，2D休闲游戏稳定在60帧才算合格，3D项目如果长期低于30帧，就要考虑砍特效和降低纹理分辨率；内存走势最容易被忽视，建议打开小游戏后台的性能面板，观察峰值内存是否逼近设备上限，如果频繁接近甚至触发闪退，必须做资源释放和压缩。

这一步也是“unity微信小游戏打包”和普通Web开发的本质区别——你在Chrome里跑得飞快，不代表在微信的运行时里也能跑得飞快，真机上所有性能问题都会原形毕露。

4. 常见问题与排查技巧实录

4.1 报错找不到game.js或入口异常

这是新手期出现频率最高的报错之一。微信小游戏默认入口是game.js，如果你从Unity或其它引擎转换过来，适配工具一般会生成这个文件，但如果手动建工程就很容易漏掉。排查思路很直接：先在开发者工具里看工程目录下有没有game.js；有的话，看game.json里有没有声明入口文件；都没有问题，再看报错信息里提到的具体路径，检查大小写和目录层级。

另一种隐蔽情况是，入口文件存在但代码里报了一个未捕获的错误，导致整个启动流程中断。这时不要盯着入口这一行看，顺着Console里的第一行错误信息往下追，通常是某个模块require失败或者某个全局变量没定义。我的习惯是先清空业务代码，只留一个最简单的入口测试通不通，再逐步加回模块，这样能快速定位到底是入口问题还是代码问题。

4.2 加载过程白屏、黑屏

白屏和黑屏本质上是两回事：白屏多半是页面渲染还没开始，黑屏常见于引擎已经初始化、但画面输出异常。前者优先检查资源加载链路，看看Network面板里第一个请求是否发出、是否被CDN拦截、是否有404；后者优先看适配层的渲染输出，比如Unity的Canvas是否被正确挂载到小游戏的画布上，WebGL上下文是否创建成功。

我踩过最坑的一次经历是CDN服务器没有配置跨域头，开发者工具开着“忽略合法域名”所以一切正常，到了真机直接白屏。后来把Access-Control-Allow-Origin加上，问题立刻消失。记住一条铁律：任何外部资源地址都要在微信公众平台配置合法域名，同时服务器必须返回正确的CORS头，两者缺一不可。

4.3 内存持续上涨然后闪退

Unity WebGL在小游戏里运行的本质，是一切资源都存在虚拟文件系统里，Unity的加载器会把下载的数据文件解压并缓存到内存中。如果你的项目场景多、贴图大，又没有及时释放，内存很容易被吃满。手机和桌面浏览器不一样，可用内存有限，系统会直接杀掉进程，表现出来就是游戏玩着玩着突然没了。

优化方向按权重排：第一优先压缩纹理，能选ASTC格式就别用RGBA直存；第二控制同时加载的资源数量，场景切换时主动UnloadUnusedAssets；第三在转换工具里配置好内存上限，避免Unity自己把内存撑爆。这三步做完，绝大多数闪退问题都能压下来。

4.4 分享、录像、支付等API不生效

小游戏和普通小程序一样，很多API都有用户授权和调用时机限制。分享功能必须用wx.shareAppMessage触发，而且只能由用户主动点击有明确语义的按钮才能拉起；录屏和分享回放要用wx.getGameRecorderManager，同样依赖用户授权。如果你发现某个API在开发者工具里能调用，真机上没反应，先去开发者后台检查接口权限是否申请通过。

虚拟支付是最需要小心的部分——微信小游戏的虚拟支付对安卓和iOS规则不一样，开发者必须针对不同系统做差异化处理，否则iOS上会出现兼容性问题。这部分设计业务合规，上线前一定要仔细阅读微信官方最新的运营规范，别等提审被拒了再回头改。

如果让我给第一次做小游戏的人一句建议，那就是：不要一上来就上Unity。先用原生JavaScript写一个完整的小项目，哪怕是猜数字、打地鼠这种最简单的，把注册、开发、提审、上线的流程完完整整跑一遍。这个过程能让你建立对整个链路最直接的体感，之后再回头看引擎方案，很多概念不用查也知道是在解决什么问题。我自己就是这么过来的，先踩坑，再总结，后面再看官方文档都骂自己当初怎么不早点懂。

这篇先把“微信小游戏是什么”和“有哪些路可以走”聊清楚了。下一篇我会拆一拆微信小游戏的代码结构，把入口、场景、资源管理、模块化组织这些骨架性的东西讲透彻。做完那一步，你对“微信小游戏代码”的理解就不再是零散的API拼凑，而是一套能支撑起完整项目的工程体系了。