企业官网建设流程全解析

一个人做微信小游戏这件事，听起来浪漫，真干起来全是细节。我自己的小工作室“Vibe Gaming”从立项到现在跑通第一款微信小游戏，前后折腾了大半年，踩过的坑比我过去写五年业务代码加起来都多。期间被微信开发者工具的报错折磨过，被打包生成的webgl模板坑过，也差点因为著作权材料不齐全把上架计划整个打乱。这篇文章不聊虚的，把我一个人从技术选型、引擎配置、打包上架到材料准备的全过程，连同那些我查了很多资料才搞明白的为什么，一并写出来。适合正好想做微信小游戏、又只有一个人或几个人、正处在“不知道从哪下手”状态的朋友。

1. 一人工作室的定位与整体设计思路

1.1 为什么微信小游戏是一人团队的理想切入点

一开始我当然也纠结过：是做一个原生App，还是做一个H5网页游戏，或者是直接上微信小游戏？后来对比了一圈，微信小游戏对一人工作室来说有几个其他平台给不了的优势。

第一是分发成本低。微信自带社交关系链，小游戏天然适合做分享裂变，不需要我花一分钱买量就能有第一批玩家。对个人开发者来说，最缺的从来不是产品，而是用户，微信这个入口直接解决了冷启动问题。

第二是技术要求相对聚焦。微信小游戏基于WebGL渲染和JavaScript封装，Unity、Cocos、Laya这些主流引擎都提供了官方导出方案，一个人完全能吃得下来。不需要同时维护iOS和Android两套原生代码，也不需要处理应用商店那一堆隐私合规材料。

第三是迭代速度快。小游戏走的是微信审核通道，修bug、加功能从提审到上线一般一两天就能搞定，对比App Store动不动一周的审核周期，快得多。这种快速反馈对单人开发调整手感、玩法平衡特别关键。

但也要说实话，微信小游戏不是没有代价。包体限制、运行环境差异、基础库兼容性这些问题一直存在，后文会一个个展开。总体结论是：如果你是一个人想靠业余时间做游戏，微信小游戏是试错成本最低的门槛之一。

1.2 从立项到上架的主线流程梳理

一个人做事最怕没有主线。我自己把微信小游戏的完整流程拆成了八步，每个阶段都有明确的出口：

1. 玩法验证：用最简单的原型确认核心玩法是不是好玩。
2. 技术选型：决定用哪款引擎，确认目标平台是纯小游戏还是同时兼容手机浏览器。
3. 工程搭建：初始化小游戏工程，跑通引擎导出到微信开发者工具的链路。
4. 核心玩法开发：把游戏主循环、操作反馈、基础UI做出来。
5. 资源与性能优化：包体瘦身、内存优化、加载进度优化。
6. 材料准备：软著登记、ICP备案（如果涉及域名）、个人主体认证。
7. 提审上架：在微信公众平台创建小游戏，提交代码和材料。
8. 运营迭代：根据后台数据和玩家反馈持续更新版本。

这条主线的关键点在于，技术工作和非技术工作必须并行推进。我见过太多开发者在功能全部做完后才开始准备软著，结果干等审核的时间比做游戏的时间还长，这是典型的流程设计失误。

1.3 一人团队的工位环境与工具清单

虽然是“一人工作室”，但该有的工具不能少。我的实际配置分三层：

• 硬件层：一台性能还不错的开发笔记本（16G内存起步，带独立显卡），一台吃灰的旧手机专门用于真机调试。小游戏开发和传统网页开发的最大不同在于，必须频繁真机验证，因为模拟器永远替代不了真机的性能表现和屏幕适配情况。
• 软件层：代码编辑器（需要支持C#或TypeScript，看引擎选型）、微信开发者工具（必备）、Unity或对应引擎IDE、Git做版本管理、飞书或Notion做任务记录。这里特别强调一下Git，哪怕只有一个人也建议每次版本迭代都打tag，否则一个改动出了问题想回退都不知道退到哪。
• 服务层：云开发平台或自建服务器用于存玩家数据，备案域名（如果走自建接口），对象存储服务用于放远程资源包。

这套配置总成本控制在五千块以内，对个人来说负担不算重。真正的成本其实是时间，所以后面所有方案我都会优先选“稳”而不是“新”，减少折腾本身就是给一人工作室省时间。

2. 技术选型：引擎对比与WebGL模板那些绕不开的坑

2.1 从零选型：原生Canvas、Laya、Cocos还是Unity

市面上做微信小游戏的主流方案有四种，我挨个试过，说下真实感受。

原生JavaScript + Canvas/WebGL：适合极其轻量的休闲小游戏，比如答题类、翻牌类。优点是不需要任何引擎，项目干净，启动速度最快，包体最小。缺点是所有游戏逻辑、渲染循环、资源管理、碰撞检测全要自己写，一旦玩法复杂一点代码量就失控，而且适配各种安卓机型非常痛苦。

LayaAir：老牌的H5游戏引擎，对微信小游戏支持很成熟，性能好，代码是TypeScript或JavaScript写的，上手快。缺点是社区活跃度这两年明显下降，遇到冷门问题可能要自己去读源码。适合2D休闲游戏和H5转小游戏的存量项目。

Cocos Creator：目前国内2D小游戏事实上的主流选择。组件化开发模式对单人开发友好，内置的小游戏适配方案非常完善，教程多、社区活跃。如果做的是2D休闲、棋牌、模拟经营这类游戏，Cocos基本是最好选择。

Unity（含团结引擎）：胜在3D能力、渲染效果、物理系统和跨平台复用。缺点是包体天然偏大，导出微信小游戏需要做大量瘦身和适配工作。适合对画面表现有要求的3D游戏，或者是想从App/PC游戏移植到小游戏的团队。

我的选择是Unity路线，具体说就是Unity加团结引擎的微信小游戏导出方案。原因很简单：我手里有现成的Unity项目资源和经验，不想再学一套新引擎；另外我后续打算同一套代码输出到抖音小游戏和其他H5平台，Unity的多平台能力正好满足需求。

2.2 团结引擎与Unity官方导出方案的差别

这里先澄清一个很多新手容易混淆的点。Unity官方其实一直有“Mini Game”导出选项，可以直接把Unity项目导出为微信小游戏。但是Unity官方WebGL方案转出来的小游戏有体积大、启动慢、兼容性一般的问题。团结引擎是Unity中国推出的本土化版本，针对微信小游戏做了很多底层优化，比如内存管理更贴合小游戏环境、启动速度更快、对iOS和安卓兼容性更好。

如果你打算长期做微信小游戏，我个人建议直接上团结引擎。它内置了“微信小游戏”的导出按钮，且自动帮你处理了大部分适配逻辑。如果你用的是国际版Unity，也可以装官方的WebGL支持模块，再配合微信小游戏适配插件来转换，但中间环节多了，出问题的概率成倍增加。

我实际遇到的怪问题基本都是绕开了团结引擎、想用原版Unity硬转的时候出现的。所以后来的项目就老老实实回到团结引擎，省下的调试时间非常可观。

2.3 WebGL模板配置的正确姿势与避坑指南

这是我在网上搜索时发现很多人都在w问的痛点，也确实是我自己卡得最久的地方。团结引擎打包微信小游戏时，WebGL模板的配置不是随便选默认模板就完事的，有四个关键点务必确认。

第一，模板目录不要乱动。默认情况下引擎会使用内置模板，如果你要自定义模板，必须放在项目的Assets/WebGLTemplates目录下，且模板文件夹名称不能带中文和特殊字符。我在一开始为了改加载进度条样式，手动建了自定义模板，结果路径写错导致打包后的文件找不到模板入口，白屏半天。

第二，压缩格式需要选择正确。微信小游戏的代码包和远程资源加载对压缩格式有要求，团结引擎里通常建议选Brotli，压缩率高，微信基础库也支持。但要注意如果你同时部署到普通浏览器环境，某些旧浏览器不支持Brotli解码，会出现加载后黑屏。所以打包时要想清楚目标平台，多平台兼容优先选Gzip甚至Disabled。

第三，必须手动开启“Strip Engine Code”。这个选项的作用是裁剪掉没用到的引擎模块，能显著减小包体。默认是关闭的，我没及时打开的时候首包体积差了接近20MB，导致微信开发者工具直接警告无法预览。但开了之后要注意，如果你用了第三方库但又没有配置link.xml保留规则，运行时会出现找不到类或方法的诡异报错，代码没写错却无故崩溃。解决方法是把用到的第三方程序集在link.xml里显式声明保留，或者在导出设置里关闭裁剪，等调完再开回来。

第四，图形API要兼容WebGL 1.0/2.0。部分安卓低端机的WebGL实现有兼容问题，团结引擎默认可能只启用WebGL2.0，在一些老机型上会直接白屏。建议导出时把“Auto Graphics API”关闭，同时勾选WebGL1.0和2.0，让引擎自动降级。这个配置能帮你减少一大半真机兼容性问题。

我用表格把这几个关键配置整理一下：

3. 导出打包与微信开发者工具接入实操

3.1 正式打包前的项目配置清单

打包前花十分钟确认一遍配置，比打包后花一小时排查问题划算得多。我的习惯是把下面这份清单贴在工位上，每打一次包就对着走一遍：

• 确定目标包体：当前微信小游戏主包和总包有大小限制，首包最好控制在4MB以内，超过就得分包。这里的包体指的是代码包和内置资源，不是远程CDN资源。
• 检查场景列表：最终导出包只包含你在Build Settings里勾选的场景，漏勾的场景不会被打进去，但运行时加载它会报错。
• 确认资源压缩格式：贴图、音频分别设置合适的格式，比如贴图用ASTC或ETC2压缩，音频用微信推荐的格式，直接省出好几MB。
• 关闭不必要的引擎功能：比如Physics、NavMesh、AI、Shader变体等，这些都会增加包体。
• 设置适配模式：渲染色域，UI参照宽度，iPhone X以上机型的ViewModel适配。
• 填写版本信息：版本号要和后续提审版本一致，避免后台显示混乱。

3.2 导出后的目录结构解析

点击导出后，团结引擎会生成一个带game.json、game.js和webgl目录的微信小游戏工程。这个工程直接用微信开发者工具打开，就能在模拟器里预览并上传代码。

几个关键文件的作用：

• game.json：小游戏配置文件，里面配置了设备方向、请求域名白名单、分包信息等。这个文件依赖手动编辑，比如want to开启横屏，就要在这里改deviceOrientation字段。
• game.js：入口文件，负责启动Unity引擎实例。正常情况下不用改，但如果要做加载进度条定制，或者存在多场景分包，就要在这里加逻辑。
• webgl目录：包含编译好的webgl代码和wasm文件，这是打包的核心产物，相当于Unity项目编译后的“可执行文件”。

在微信开发者工具中上传时，选中的是整个项目目录而不是单个文件，所以目录结构尽量不要手动改动，不然文件哈希对不上会莫名报错。

3.3 导入微信开发者工具后的关键设置

微信开发者工具导入小游戏项目后，第一件事不是点预览，而是检查右侧详情面板里的几个配置：

AppID必须填写自己注册的小游戏AppID，而不是测试号。测试号虽然在开发阶段可以预览，但它不支持云开发和真机调试的完整流程，等到要上传版本时还得换回来，不如一开始就填正式账号。

基础库版本要选一个绝大多数用户都能覆盖到的版本，不用一味追新。微信基础库的API向下兼容做得不错，但有些新API在老基础库里不存在，写代码时要注意用现有API能力检测来兜底，而不是直接调用。

域名校验是另一个容易卡壳的地方。如果你自己写了后端接口，必须在后台配置request合法域名，并且要求是HTTPS且已备案。开发阶段可以在开发者工具里勾选“不校验合法域名”，但真机预览时这个开关无效。所以域名这一块要提前规划，别拖到联调时才想起来。

3.4 真机调试：模拟器正常不代表真机正常

我在这上面吃过一次大亏。模拟器里跑得丝般顺滑，手机上一打开就卡成PPT，一查发现是某个加载逻辑在模拟器环境下走的是本地缓存，真机上走的是网络加载，完全两个性能表现。

真机调试的注意事项有这几条：

• 用微信开发者工具的“真机调试2.0”功能，它会生成一个二维码，扫码后在微信里打开小游戏，同时把调试台信息回传到开发机上，可以直接看Console日志。
• 要特别关注帧率和内存两个指标。在真机上手动打开帧率显示，帧率低于30说明渲染性能有瓶颈；内存持续上涨说明有泄漏或资源未释放。
• 低端安卓机和iPhone老机型都要测。微信小游戏用户群里，中低端安卓机占比不低，越是休闲游戏越是这样，因为玩这类游戏的用户并不都是旗舰机用户。

常见的问题现象和解决办法，我会在第五部分详细展开。

4. 微信小游戏上架背后的著作权登记问题

4.1 上架到底是上架什么，需要哪些资质

很多第一次做微信小游戏的人会问：微信小游戏现在需要著作权登记么？答案是需要。微信小游戏后台有个“游戏信息”的填写步骤，其中有一栏就是要求提交计算机软件著作权相关证明。没有这个证明，版本提审之后很快会被打回。

另外要区分两个概念：一种是软件著作权，保护的是你这个游戏程序本身的代码逻辑和整体表达；另一种是游戏版号，那是更重的资质，但小游戏平台在个人主体和部分类目下并不强制要求前置版号。对绝大多数独立开发者来说，核心要办的就是软著。

需要注意的是软著登记只做形式审查，不审查玩法是否抄袭，但它能证明你是代码的著作权人。如果你做的是有知名IP元素的换皮游戏，或者用了别人美术素材，即便软著办下来了，上线后仍可能被投诉侵权。这跟软著登记是两码事，合规底线不能靠一张证兜底。

4.2 软著登记流程与时间线安排

我刚办的时候觉得软著很神秘，实际操作下来其实就是一套标准的流程：在中国版权保护中心网站上注册账号，在线填报申请表，提交源代码文档和用户手册，等待审查，最后收到电子证书和纸质证书。

过程中最有意思的部分是源代码文档的格式要求。一般需要提交前30页和后30页源代码，每页至少50行，如果代码总量不足60页就全部提交。重点是代码要跟实际项目一致，但又不能把核心逻辑完全暴露，所以大多数人的做法是单独做一个脱敏后的source文档，把无关紧要或者无法公开的模块替换掉，保证代码量足够的同时不算泄漏核心机制。

我特别要提醒时间安排：普通软著登记审查周期大约30到40个工作日，如果加急会有额外费用。对一个人工作室这种现金流紧张的状态，赶早不赶晚。最好在游戏开发中期、核心功能基本定型、代码量已经稳定的时候就开始走流程，等游戏做完、准备提审时软著刚好下来。

4.3 个人主体如何完成认证与提审

微信小游戏后台对个人主体开放，但需要先完成微信认证。认证费用一年三百元，这个躲不掉。整个流程是在微信公众平台注册“小游戏”账号，选择“个人”主体类型，然后做身份认证和企业认证不同，它是绑定管理员个人身份信息的。

资料准备方面要提前备齐：个人身份证正反面照片、手持身份证照片、银行卡信息、常用邮箱和手机号。这些信息在注册时一次性填完，后续修改很麻烦，特别是AppID绑定的主体信息一旦提交，基本改不了，所以注册时务必仔细。

提审时除了软著材料，还需要填写游戏类目、简介、截图。游戏类目的选择会影响审核效率和后续功能权限，比如涉及虚拟支付就要对应特定的类目要求。休闲益智类一般是最宽松的类目，独立小游戏建议优先选这个。

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

5.1 首包过大与分包加载策略

微信小游戏在包体方面的限制非常严格，跟传统手游完全不是一个量级。首包超过限制时开发者工具会直接给出Error，无法进入预览；总包太大则会导致有些人加载失败。我自己的项目第一次打包就有30多MB，完全不可用，最后靠三招把它瘦下来了。

第一招是把核心玩法需要的资源放本地，其他内容放CDN。比如关卡图片、音效这种玩到对应关卡才需要的东西，全部放到服务器上，在游戏中动态下载。微信小游戏支持远程资源加载，配合本地缓存能实现“用多少下载多少”的效果。

第二招是开启引擎裁剪。前面提到的Strip Engine Code就是这招的关键。裁剪后Unity引擎从20多MB降到不到10MB。

第三招是合理分包。微信小游戏允许把代码按功能拆成多个子包，启动时只加载主包，进入特定模块时再加载对应子包。比如把设置界面、成就系统这些不常用的功能放到分包里，虽然有点麻烦，但换来的启动速度提升确实值得。

5.2 启动白屏与首屏加载等待

小游戏通过微信点开，到真正进入游戏画面之间有一段加载时间。这个阶段如果处理不好，用户看到的就是白屏，很多玩家会在两秒内直接关掉。这里的核心矛盾在于：代码包要控制体积，但引擎初始化又需要时间。

我的解决方案是做一个加载封面，用纯图片和文字的形式在游戏启动前显示。具体做法是先把加载封面做成小游戏中的第一个场景，先启动一个轻量场景，显示进度条，与此同时在后台创建Unity的主场景，等主场景ready后再切换过去。这样用户的视觉体验就从“白屏等待”变成了“进度条加载”，留存率提升非常明显。

另外微信开发者工具还提供了一个叫“代码包预下载”的能力，可以在game.json里配置preloadRule，像网络空闲时提前把资源分包下载好。这项能力对新用户的加载体验帮助很大，值得研究并在合适场景下使用。

5.3 屏幕适配与iPhone安全区处理

小游戏的运行环境千奇百怪，屏幕尺寸从iPhone SE到最新的全面屏设备，从16:9到21:9都有。Unity里的解决方案是设置合适的Canvas适配模式，通常用“缩放匹配宽度”或“匹配高度”模式之一，再结合安全区API来调整UI位置。

iPhone的刘海屏和底部Home指示条会遮挡按钮，UI底部至少留出34像素的安全区，否则iPhone用户会点不到按钮。安卓各种挖孔屏也有类似问题，但适配策略可以统一：读取微信提供的safeArea信息，然后动态改变UI层的内边距。

这个部分真机调试才能发现问题。模拟器里可以模拟不同机型，但模拟结果和真机渲染还是有一定差异，特别是UI圆角和异形屏的裁切效果，真机上看最准。

5.4 排查技巧速查表

这大半年的实践走下来，我的体感是：微信小游戏一人工作室真正拼的不是技术多前沿，而是把细节一件件抠明白的耐力。引擎选型、模板配置、打包流程、软著材料，每个环节单独看都不难，但它们串在一起，任何一个环节卡住都会让上线无限延期。我也犯过很多错，比如软著申请拖到游戏做完才办、WebGL模板没配置好白白浪费两天。如果这篇文章能让你少走这些弯路，那就值了。我个人最想分享的一个经验是：把非技术事务当成技术任务一样列进开发计划里，一人工作室的诅咒从来不是代码写不完，而是那些你以为“到时候再说”的杂事，最终都成了真的瓶颈。现在这套流程我已经跑顺了，下一个项目会在这个基础上继续做，希望你们也能顺利跑通自己的第一款小游戏。