企业官网建设流程全解析

微信小游戏这个圈子，有个很有趣的现象：喊“一个人也能做游戏”的人很多，真正把产品走完开发、提审、上线、调数据这条链路的人很少。Vibe Gaming 是我一个人撑起来的小工作室，名字听着挺潮，实际就是一张桌子、一台电脑，周末和深夜各占一半。这篇文章我想把这一路踩过的坑掰开揉碎，围绕微信小游戏开发实战过程中的 Unity 打包、视频播放、广告接入、资源管理和上线运营，写给那些同样想靠一人之力做出小游戏的人。内容不吹不黑，都是我实操过的方案和判断，你能直接拿去复用的流程，我会尽量写清楚，不能照搬的部分也会告诉你为什么。

1. 一人工作室做微信小游戏，到底图什么

1.1 为什么是微信小游戏，而不是 App 或 Steam

我在最早立项时，其实犹豫过是做一个手机 App、Steam 单机，还是微信小游戏。最后选了微信小游戏，核心原因就两个：触达成本低，变现路径短。

App 的痛点是下载和安装这一步能过滤掉 90% 的潜在用户，Steam 更是要先买再玩，对独立开发者非常不友好。微信小游戏不一样，玩家看到分享卡片，点一下就能进入游戏，完完全全跳过了“安装”这个心理门槛。这个差别在单人项目里尤其重要，因为我没有市场预算，也没有专门的地推渠道，只能指望用户愿意点进来。

另外，小游戏的变现不需要我去对接支付、绑卡、处理退款，直接用流量主广告就能产生收入。虽然单个用户贡献的收益不高，但如果游戏本身具备传播性，让用户愿意主动分享，那么“点击即玩 + 广告变现”就是一个能自我造血的最小商业闭环。对一个人来说，这比做一个空有口碑但没收入的作品要现实得多。

1.2 Vibe Gaming 的定位：轻中度休闲 + IAA + 快速验证

定下平台之后，接着是品类。我在 Vibe Gaming 定的调子很明确：只做轻中度休闲玩法，坚持 IAA（In-App Advertising）变现，不碰重养成、不碰强社交、不碰长线数值。

为什么这么定？因为单人开发最大的敌人不是技术，是时间。一个重养成游戏需要大量内容填充、数值平衡、系统循环，这些在合理工期下根本不是一个人能完成的。相比之下，休闲玩法可以把核心循环压缩在 3 到 5 分钟一局，美术可以用低多边形、扁平插画来降低产能压力，代码也能用 Unity 里的成熟框架快速迭代。

“Vibe”这个前缀也代表了选品标准：游戏给玩家的第一感觉要轻松、解压、有节奏感。我不会做让人肾上腺素飙升的竞技游戏，也不会做需要看长篇剧情的东西。只有把体验做得足够轻，玩家才会在碎片时间随手打开，这正好匹配微信小游戏的使用场景。

1.3 一人工作室的时间分配和“工具外援”

一个人干活，最怕的是把时间花在重复劳动上。我在 Vibe Gaming 的日常大致分成三块：产品迭代占 50%，修线上问题占 20%，运营和数据复盘占 30%。

产品迭代里，我用 Unity 和 C# 写核心逻辑；资源批处理、日志分析这类脏活交给 Python 脚本；日常配置、文案生成、埋点代码补全，我会用一些 AI 智能体辅助完成。很多人觉得“用 AI 写代码不靠谱”，其实关键是怎么用。我通常不会让它直接写整个系统，而是让它生成重复度高的模板代码，比如一堆相似关卡的 JSON 配置、一个 UI 弹窗的按钮绑定、一段上报事件封装，这类工作花不了多少时间，但胜在量多，能省一点是一点。

这套组合下来，我才能把更多精力放在真正影响体验的地方，也就是玩法手感、性能和线上问题排查。单人工作室不是什么都自己死磕，而是要把力气花在刀刃上。

2. Unity 微信小游戏打包：从项目到小游戏包的完整链路

2.1 选 Unity 的理由和版本选择

微信小游戏的技术栈其实有好几条路可选：原生 JavaScript、Laya、Cocos，以及 Unity。我选 Unity 不是因为它最轻量，而是因为它最适合我这种 C# 背景、同时需要资源商店大量现成素材的人。

Unity 对 2D 和 3D 混合玩法的支持很成熟，资源商店里有很多可以直接商用的 UI 套件、粒子特效、模型和音频，这些对没有专职美术的我来说太重要了。Cocos 和 Laya 在 2D 小游戏开发上也有优势，但 Unity 的编辑器界面、动画系统和调试工具我更熟悉，一个人做项目，用熟不用生，这个选择基本没有悬念。

版本方面，我现在主力用的是 Unity 2021.3 LTS。这个版本被微信小游戏适配方案覆盖得比较早，踩坑资料也多。如果你想用更高版本，建议先做一个 Demo 包验证通过再整体升级，不要一上来就追新版本，否则适配层可能跟不上。

2.2 导出前的关键配置：内存与 IL2CPP

Unity 项目要变成微信小游戏，不是直接把 UWP 或 Android 包丢上去，而是需要先导出成 WebGL 风格的小游戏工程，再通过微信官方适配方案做一层转换。实际开发中，我会在 Build Settings 里选择名为 WeChat Mini Game 的构建目标，这个目标由官方“Unity 微信小游戏适配方案”提供，不是 Unity 自带默认支持的平台。

在 Player Settings 里，我一般会把 Scripting Backend 设为 IL2CPP，目标架构选 ARM64。为什么必须用 IL2CPP？因为微信小游戏运行在浏览器 JS 引擎上，Unity 自己生成的 C# 托管代码没法直接执行，需要先把代码变成 C++，再通过 WebAssembly 跑到小游戏环境里。IL2CPP 就是这条链路的起点。

内存配置也要提前留意。小游戏端是一个受限环境，加载的 Unity WebAssembly 内存池是有限额的，不建议盲目把堆内存调得特别大。我习惯按照最差设备的内存表现来设，宁可让游戏在低端机上降一点画质，也不要因为它内存占用超过平台限制被直接杀掉。

2.3 打包流程与体积控制实操

我现在的标准打包流程大概是这样的：

1. 在 Unity 菜单安装并导入官方“微信小游戏适配方案”相关包；
2. 在 Project Settings 里填好小游戏的 AppID；
3. 把场景切换成正式的启动场景；
4. 切到 WeChat Mini Game 平台，Player Settings 里关闭不需要的模块；
5. 执行构建，导出一个包含 game.js、wasm 和资源文件的小游戏目录；
6. 用微信开发者工具打开这个目录，确认预览正常，再上传版本。

上面这个流程看起来简单，但真正决定你能不能顺利上线的，是包体控制。微信小游戏对主包大小有严格限制，我记得主包要控制在 4M 左右，总包也有上限，具体数值要以官方文档为准。这里我踩过一个很重的坑：第一次打包的时候，把一套完整的美术资源全部塞进首包，结果主包直接超限，开发者工具都拒绝预览。

后来我的做法是“首包只放启动场景和必要 UI”，一个启动界面、一个 Logo、一段最简单的加载进度条，其他玩法美术、音频、关卡数据全部打成 AssetBundle 放到 CDN，运行时按需下载。这样主包被压得非常小，玩家最先看到的东西永远是那几个静态资源，后面资源加载完全不影响首屏曝光。字体也特别值得注意，中文字体体积通常很大，不要无知地把系统字体打进包里，最好做字体裁剪或用动态字体方案。

2.4 真机性能怎么看：别只看开发者工具

微信开发者工具的模拟器，只能看出“大概能不能跑”，真机上的表现经常完全不一样。原因很简单：小游戏最终跑的是 WebAssembly、渲染在 WebView 环境下，不同手机的内核、驱动、内存带宽都不一样，模拟器根本复现不了真机性能。

我上线前一定会在几台不同档位的 Android 手机和 iPhone 上跑一轮真机预览。Unity 侧可以用 Profiler 拿到内存、CPU 耗时和加载耗时；微信开发者工具也自带性能面板，能看到 FPS、网络请求和内存曲线。如果游戏出现明显掉帧，我会进一步看安卓侧的渲染报告，比如 Perfetto 这类性能追踪工具，来判断是 DrawCall 爆了、纹理内存太大，还是某个模块在持续占用主线程。

真机性能排查有个原则：先看最差的机器，再优化主流机型。一个人不可能买全所有手机，但我至少会准备一台百元级安卓机、一台中端安卓机、一台老款 iPhone。如果你的游戏在这三台机器上都能稳定 30 帧以上，那大部分用户的问题就不大了。

3. 微信小游戏最容易被卡住的三个功能模块

3.1 视频播放方案：从黑屏到同层渲染

小游戏里用到视频的场景很多，包括宣传动画、剧情演出、甚至激励视频广告的兜底素材。我最早天真地以为在 Unity 里放一个 VideoPlayer 组件，导出小游戏后自然就能播。结果真机一跑，iOS 端直接黑屏，安卓端有的型号可以、有的不行。

后来我才搞明白，微信小游戏环境里不能直接用 Unity 的 VideoPlayer 走传统视频管线，必须调用小游戏平台的视频能力，也就是wx.createVideo。这是原生组件，和普通 HTML 的<video>不完全一样，它会被渲染在小游戏画布之上，需要处理好位置和层级，这里面最关键的一个概念叫同层渲染。

同层渲染的意思是，小游戏的 Canvas 可以和原生视频组件在同一个层级里混合显示。听起来很美好，但实际适配要非常小心。iOS 上有些版本会自动切到全屏播放，安卓上不同厂商的 WebView 对同层渲染的支持也有差异。我的落地做法是：

• 视频播放前，先监听用户的一次点击或触摸事件，不要在启动时自动播放；
• 创建视频时，把 x、y、width、height 明确传给wx.createVideo，不要让它自己找位置；
• 播放结束和出错都要监听回调，出错后立即销毁视频对象，避免残留黑屏；
• 在 Unity 侧用一个 C# 工具类封装这些调用，方便暴露给游戏逻辑。

代码层面，我在小游戏适配层常用的是类似这样的逻辑：

let video = wx.createVideo({ src: 'https://your-cdn.com/video/clip1.mp4', x: 0, y: 0, width: 375, height: 211, objectFit: 'contain', controls: false, autoplay: false }); video.onPlay(() => { console.log('video started'); }); video.onError((err) => { console.error('video error', err); video.destroy(); });

第一次调用视频播放的时机，我建议放在用户点击按钮的事件回调里，因为很多端上自动播放会失败，只有用户主动触发的播放才可靠。如果你在 Unity 里接这个能力，不要把它封装成一个“后台静默加载”的模块，最好做成“点击后返回回调再创建”，稳定的优先级高于省事。

3.2 广告接入：激励视频是单人工作室的命脉

对小游戏这样的 IAA 产品来说，广告就是收入来源，而所有广告位里最值得做细的就是激励视频。Banner 和插屏虽然能挣钱，但体验损失大，eCPM 也明显更低，我把它们放在次要位置。

激励视频的接入逻辑不复杂，核心问题是“用户看完没有”和“广告有没有拉到”。小游戏创建一个激励视频广告大致是这样：

let videoAd = wx.createRewardedVideoAd({ adUnitId: 'xxxxx' }); videoAd.onLoad(() => { console.log('ad loaded'); }); videoAd.onError((err) => { console.log('ad error', err.errCode, err.errMsg); }); videoAd.onClose((res) => { if (res && res.isEnded) { // 用户完整看完，发放奖励 grantReward(); } else { // 用户中途关闭，不给奖励 } }); // 需要时调用 videoAd.show().catch(() => { videoAd.load().then(() => videoAd.show()); });

这里有几个细节很关键。第一，广告要提前 load，不能等用户点击“领取奖励”再去拉取，否则会看到几秒白屏，用户会直接关掉。第二，onClose里的isEnded必须检查，不能因为用户关闭广告就发奖励，否则会被玩家薅羊毛。第三，show()可能会失败，常见原因是广告拉取过期或者没有填充，所以一定要 catch 住并且降级处理，比如提示“暂时没有可观看的广告，请稍后再试”。

关于开通流量主的条件，我印象里是累计独立访客达到一定数量后，后台会开放流量主申请入口，具体数值要以你后台看到的为准。我在项目中不会为了快速达标去刷量，因为微信对异常流量的打击很严，一旦判定作弊，封号封广告位都是很麻烦的事。

广告还需要注意频次控制。别在玩家每玩一局、每次点按钮都弹激励视频，那会让游戏变成“广告启动器”。我一般会控制每位用户每天能看的激励视频次数，比如 15 到 20 次，把“看广告”变成一种有限度的资源交换，而不是打断体验的惩罚。

3.3 排行榜到底在哪看：后台数据与开放数据域

“微信小游戏排行榜在哪看”这个问题，我经常在玩家群看到，也经常在开发者群里看到。

玩家视角很简单：在微信里的发现页找到小游戏，进入游戏后如果开发者做了好友排行榜，就能直接看到；或者在微信小游戏模块里找到“排行榜”入口，可以看好友在玩什么。但对开发者来说，排行榜不是一个简单的“入口”，它是开放数据域能力，逻辑上是小游戏主域和开放数据域分离的。

主域负责正常游戏逻辑，但关系链数据只能放到开放数据域里读取和渲染。我在第一次接排行榜的时候犯过错误，想直接在 Unity 的主场景里读取好友微信昵称和分数，结果接口根本拿不到数据。正确做法是：

// 主域 const openDataContext = wx.getOpenDataContext(); openDataContext.postMessage({ type: 'updateScore', score: 100 });

然后要在独立开放数据域中监听这个消息，自己把排行榜绘制到一块独立 canvas 上。开放数据域里不能用主域的 DOM API，也没有游戏引擎帮你渲染，通常是在 canvas 上用纯 Canvas 2D 画。如果用 Unity 做小游戏，这块需要额外处理，官方适配方案里有开放数据域的示例，核心思路是让开放数据域的上屏画面通过插件覆盖到 Unity 界面之上。

排行榜的价值不只是“社交攀比”，它也是很好的数据洞察入口。我会把排行榜上的数据和自己服务端的数据做交叉对比，观察顶级玩家玩到哪一关、分数分布如何，这能帮我判断难度曲线到底合不合理。同时，玩家端的好友排行榜天然有传播效果，一个人玩容易流失，但看到好友分数比自己高，就会想再玩一局追上去。

4. 小游戏资源获取与远程包管理

4.1 关于“获取小游戏资源”，我的合规建议

网上时不时有人问“电脑微信获取小游戏资源”之类的问题，类似问题本质上是想拿到已发布小游戏里的图片、音频和配置。这里我必须先说清楚：如果你想拿的是别人家游戏里的资源，这大概率涉及侵权，而且很多资源本身就是别人的劳动成果，不建议动这个心思。

但如果目标是“找回自己开发的游戏资源”，实在有合规场景。比如你有一个发布过的旧包，但本地源文件丢了，只有线上版本还在跑，那确实可以从微信 PC 端的缓存目录中尝试恢复一部分文件。微信 PC 端会在本地缓存运行过的小游戏内容，通常需要找到对应的项目文件目录，里面可能包含 wasm、资源和若干配置文件。

但我要提醒一下，这个过程有几个现实问题：缓存目录里的资源可能被混淆、改过文件名，也可能因为版本更新已经被旧缓存覆盖，不一定能还原成可用的原始资源。真正靠谱的做法，是从第一天开始就做好版本管理：源文件放版本库，构建产物定期备份，AssetBundle 上传 CDN 时保留对应的版本清单和 md5 文件。这样不管过多久，你都能恢复出某个历史版本，根本不需要去依赖微信缓存。

4.2 远程资源更新与版本管理

小游戏不像 App 一样可以随便发一个大安装包让用户去应用商店更新，包体有严格限制，所以绝大部分非首屏资源都要走远程加载。这里面最容易被忽略的是“版本管理”。

我通常会在 CDN 上维护一个资源根目录，目录里按版本号放 AssetBundle，比如https://cdn.example.com/game/res_v1.2.0/。游戏启动时先请求一个version.json，里面写当前需要的资源版本号和每份资源的 md5，客户端再根据这份清单去下载缺失资源。

为什么一定要有 md5？因为 CDN 的缓存策略有时会让客户端拿到旧文件，如果没有 md5 校验，轻则显示错误贴图，重则出现资源读取崩溃。我在实践中会把这些校验放到一个单独的加载管理器里，下载完成先比对 md5，不一致就删除重下，最多重试两次再报错。

版本更新也要考虑平滑性。比如线上版本是 1.1.0，你发了一个 1.2.0 的资源配置，但旧版本玩家还在线，这时候最好做到“1.1.0 也能继续玩，不强制立即跳版本”。我一般会兼容最近两个大版本，避免玩家因为一次更新被卡在加载页。

4.3 包体压缩和首屏加载优化

加载体验是休闲小游戏口碑的重要一环，玩家点进游戏，如果 5 秒内还看不到可交互的界面，流失率会急剧上升。

我优化首屏加载的经验是：先“能出画面”，再“完整可用”。启动场景只加载一个非常简单的加载界面，背景可以是纯色或一张经过压缩的启动图。等 Unity wasm 初始化完成后，再进入加载逻辑，按优先级拉取玩法资源。

图片压缩上，我统一把 PNG 转成 WebP 或压缩纹理格式；音频则优先用低采样率的压缩格式，能一句话表达清楚的效果音绝不用几兆的 WAV。这些看起来很小，但每一个资源体积减少一点，首屏加载速度就能快不少。

5. 单人上线到持续运营的完整动作

5.1 提审前 Checklist 和常见驳回理由

游戏做得再好玩，过不了审核也白搭。微信小游戏审核和 App Store 不太一样，它更看重功能完整性、内容安全和用户体验。我提审前都会按下面这个清单过一遍：

• AppID 和开发信息是否完整；
• 是否配置了隐私保护指引，用户首次进入是否能看到隐私弹窗；
• 游戏内是否包含广告组件，广告位 ID 是否真实可用；
• 是否存在测试代码、报错弹窗、空数据页面；
• 素材里有没有明显侵权风险的音乐、图片、字体；
• 游戏内是否有诱导分享、强制关注之类的违规设计；
• 是否有明显的敏感词或违规内容。

最容易被驳回的是隐私弹窗和广告位问题。有些开发者觉得游戏里没有收集用户信息就不用管，但小游戏实际上会用到微信头像、昵称等数据，后台要求有清晰的隐私说明。广告位如果填了虚假 ID，审核员点开广告发现死链，大概率也会被打回。所以提审前一定要用真机跑一遍完整流程，尤其是“点击广告按钮”这个环节。

5.2 用数据做迭代而不是拍脑袋

没有数据的迭代都是赌运气。我在后台最常看的几个指标是：新增用户、次日留存、人均使用时长、关卡完成漏斗、广告人均展示次数。

举个例子，我之前做一款小小的闯关游戏，发现第二关的流失率接近 80%。刚开始我以为是玩法问题，后来把埋点数据拉出来一看，发现大多数玩家在第二关开局后 5 秒内退出，而不是打了很久才放弃。我判断是第二关的教学引导没做好，玩家看不懂要求。后来我在第二关开头加了一个明确的前进方向提示和奖励预告，流失率立刻降到了 55% 以下。

这种问题，如果只靠后台的“留存率”这一个指标，根本定位不了。所以我从项目一开始就埋好了关卡事件：玩家进入了哪关、在哪一步停留超过 10 秒、因为什么原因退出。单人工作室虽然没有分析师，但只要用 Python 写一个简单的日志汇总脚本，把每天的事件表拉出来归类看，一样能发现很多问题。

5.3 低成本获量：分享、社群和关系链

我没钱做大面积投放，所以获量核心会放在“自传播”上。微信小游戏最好的获量工具就是“分享”，但不是让你在每个界面都放一个假的分享按钮诱导玩家，而是要让分享变成一个自然动作。

比如玩家完成了一个高难度挑战、解锁了某个稀有皮肤、拿到历史最高分，这时弹出一个“分享战绩给好友”的按钮，文案写得有趣一点，被分享的人点进来，看到好友的成绩，也很容易产生“我也来试试”的冲动。

关键是分享卡片要被点开，我的一个经验是分享文案里不要写“快来玩”，而要写一个具体结果，比如“我居然在 30 秒内通关了 XX，你们谁行”，这种有挑战性的文案点击率明显更高。当然，这一切的前提是符合微信平台规则，不要诱导、不要用奖励绑架分享。微信对诱导分享的处理很严厉，我宁可少一点裂变，也不要冒被封的风险。

小游戏中心的正规推荐位也需要争取，但那个优先级我没有办法控制，更实际的是先做好自然增长的数据表现，留存好了，系统算法才有机会把游戏推到更多用户面前。

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

6.1 高频问题速查表

一个人开发很容易被同一个问题反复折腾，我这里整理一个速查表，大部分都是我在真机调试时遇到的真实情况。

6.2 一次真实的黑屏排查记录

有段时间我接到反馈，说游戏里某个剧情视频在 iPhone 上黑屏，安卓却正常。我一开始以为是视频格式问题，把 MP4 重新转码、换码率，问题依旧。后来看到日志才发现，视频的onPlay回调根本没触发，src已经给到了wx.createVideo，但 iOS 端要求视频播放必须处于用户点击的调用栈里，而我代码里是在异步加载完成后才调用的video.play()，这个异步调用链把“用户手势”上下文丢了。

修复方式很简单：把视频创建和播放移动到用户点击按钮的同步回调里，虽然在设计上没那么“智能”，但稳定优先。之后我在注释里专门写了“不要将 play 放到 setTimeout、requestAnimationFrame 或异步回调中”。这个坑真的很经典，尤其是从 Unity 侧封装的时候，调用链路一绕，回到小游戏环境就失效了。

6.3 我建议你尽早养成的 3 个小习惯

第一，每次构建版本都要保留一份构建日志。包括 Unity 打包时间、导出目录、资源版本号、CDN 路径、微信开发者工具上传的版本号。这样哪天线上出问题，你能快速定位是哪个版本、哪份资源配置出了问题，而不是靠猜。

第二，把“埋点”当成功能，不是可选项。就算是一个只有三个界面的小游戏，我也建议把启动、进入主界面、点击开始、过关、失败、观看广告这些事件全部埋好。单人工作室最缺的就是用户反馈渠道，埋点是你最忠实的数据来源。

第三，给自己设一个“必须有产出”的截止日期。一个人开发最大的风险不是做不出来，而是永远在优化、永远不上线。Vibe Gaming 的很多项目，我都是先做最低限度的可玩版本，然后逼自己走完提审上线全流程。哪怕玩法不够丰富，至少管道跑通了，之后的版本迭代才有意义。

这些坑看起来零散，但对一个人工作室来说，每一个都可能耗掉一整个周末。我在做 Vibe Gaming 过程中最大的体会是：小游戏不是“做出一个 demo 就行”，而是“能用最低成本把它稳定送到玩家手里，并持续优化”。如果你也在做微信小游戏，建议第一版尽量砍到最小可玩状态，把打包、视频、广告、上线这 4 个管道全部打通，再回来加玩法。后面再遇到问题，也可以先从这几个章节找思路，大概率能少走我走过的弯路。