1. 个人主体能做微信小游戏吗？先摸清"免版号"的真实边界
很多朋友看到"免版号"三个字，第一反应是"是不是有灰色通道"。这里先把话说明白：不是钻空子，而是按现行平台规则，个人主体、非商业化、不含虚拟支付与随机抽取玩法的轻量小游戏，可以走一条相对轻量化的上架路径。你可以在微信公众平台注册个人主体小程序，选择对应的服务类目，在无内购、无诱导分享、无积分商城的前提下，不需要像商业游戏那样提前备齐全套资质文件。这是一个公开的、可重复验证的流程，不是什么见不得光的操作。
为什么个人开发者会特别关注这条路？因为大多数独立开发者的现实处境是：一个人或两三个人，用业余时间做出一个完整的Unity小游戏已经很不容易，如果再要求先办软件著作权、再去走完整的游戏出版审批流程，时间和金钱成本直接劝退。我自己做第一个微信小游戏时就卡在这上面，项目做完了，一想到要去准备一堆证明材料，直接搁置了两个月。后来认真研究了个人主体和类目规则，才发现轻量互动内容其实有合规出口，关键是要控制好项目形态，不要踩到商业化红线上。
那"免版号"路径到底适合谁？适合纯前端逻辑的休闲交互小游戏——比如益智类、养成类、模拟类、创意工具化游戏，只要不涉及充值付费、不开放随机抽奖、不做用户间交易，都有机会通过审核。如果你的项目计划内置付费道具、会员解锁、抽卡扭蛋这类商业化能力，那必须走完整资质流程，这条路就不适用了。还有一点要注意：个人主体没有办法开通微信小游戏的虚拟支付能力，即使你的游戏做完也无法直接收款，所以商业化的念头趁早掐掉，否则后期改结构非常痛苦。
另外，个人主体在注册时有一些硬性条件：需要年满18周岁、拥有大陆身份证、一个未被占用且已绑定银行卡的微信号、一个可接收验证码的手机号。整个注册过程大概需要10分钟，但要注意一个人身份证最多注册5个小程序，同一个手机号也只能绑定一个小程序，别浪费名额。平台会在注册后要求做身份验证（人脸识别），验证通过后你的个人开发者身份就正式生效了。主体类型一旦选择"个人"，后期是不能变更为企业主体的，能做的只是重新注册新的主体账号，所以注册前一定要想清楚，这个号以后是要用来做商业项目还是只做个人实验项目。
很多教程都会直接跳到"打开Unity开始开发"，但以我实际跑下来的经验，先花半小时把平台规则和注册材料理清楚，比先装软件重要得多。因为平台规则直接影响你后续的工程配置、类目选择、提审材料，先确认自己的项目形态符合免版号的边界，再动手写代码，才不会白干一场。
2. Unity版本没选对，后面每一步都在还债
微信小游戏能跑Unity项目，靠的是官方提供的WebGL转小程序适配方案，而这套方案对Unity版本的依赖相当强。我用过Unity 2020、2021、2022三个大版本，踩了不少版本差异的坑，这里直接说结论：推荐使用Unity 2021.3 LTS或2022.3 LTS，并且必须安装WebGL构建组件。你的电脑上如果是Unity 2023或更新的版本，建议先确认适配方案的Release说明里是否明确支持，不要着急升级。
为什么版本这么挑剔？因为微信小游戏的运行时本质上是一个浏览器环境（iOS上是JavaScriptCore，Android上是V8内核），Unity需要把C#代码编译成WebGL能运行的形态，适配方案根据不同的Unity版本生成不同的导出工程结构。官方适配方案虽然持续在更新，但它的支持矩阵永远滞后于Unity最新版一段时间。如果你用太新的Unity版本，可能遇到构建脚本不兼容、插件API变动、生成的game.json字段不对等问题，排查起来非常痛苦。
安装时最容易忽略的是WebGL组件。很多人装Unity的时候默认只勾了Windows或Mac平台支持，等打包时才发现找不到WebGL选项，又回去补装，白白浪费时间。正确做法是：在Unity Hub的"安装"界面，选中要安装的版本，点击右侧齿轮图标，进入"添加模块"，勾选WebGL Build Support后再安装。
除了Unity本体，还要准备两个工具：一个是微信开发者工具（稳定版即可），用来导入Unity导出的构建产物、编译小游戏代码、生成预览二维码、提交上传审核；另一个是Git客户端，因为官方适配插件通常是以仓库形式提供的，国内网络条件下建议优先在Gitee等平台搜索转存版本，避免直接从海外仓库拉取时的网络不稳定问题。这一步不用觉得奇怪，Git在日常开发中几乎是必需品，后续适配插件的更新、分支切换都靠它。
小游戏的基础库版本也要留意。微信开发者工具内置了不同版本的基础库，模拟器和真机调试时可以切换。Unity适配插件通常要求基础库版本不低于某个阈值（一般要求2.20.2以上），你在开发者工具的"详情-本地设置-调试基础库"里选择较新的版本即可。如果基础库太低，部分Unity转译后的API（比如Audio、WebGL相关接口）会直接不可用，表现就是真机上黑屏但模拟器正常，这类问题排查起来很费劲。
还有一点：直播或录屏中常见的"用Unity 2022国际版"这个说法，在实际发布流程里和国内正式版没有任何区别，你只需要关注Unity的版本号和是否支持WebGL平台，不要被这类名词干扰。个人开发者选用长期支持版（LTS）是最稳妥的路线，因为它修复了已知的严重Bug，且适配插件更新时通常会优先兼容LTS版本。
3. 工程改造：做微信小游戏和做PC游戏完全是两套思路
很多Unity开发者第一版小游戏就是直接把PC工程导出WebGL再转小游戏，结果要么包体过大上传失败，要么真机卡成PPT。这里先说几个和传统开发思路差异极大的点，理解了它们，你就能少走大半弯路。
**第一个差异：包体大小是硬上限。**普通Unity游戏动不动几百MB很正常，但微信小游戏的主包加分包有严格限制，主包不能超过4MB（这是基础包大小，平台会校验），整体包体（主包加所有分包）一般不能超过20MB。所以你在做资源规划时就要有"把包体控制在十几MB以内"的觉悟。实际操作中建议：所有美术资源压到极致（纹理用ETC2/ASTC压缩，音频用MP3格式），减少预制体数量，删除不需要的Shader变体。如果资源实在多，用官方适配插件自带的AssetBundle分包功能，把不常用的资源放进远程包，运行时按需下载。第一次做的时候我天真地把几个GB的素材压缩了一下就往上怼，结果上传时直接被平台拦截，后来老老实实切分包才解决。
**第二个差异：文件系统不再是文件系统。**Windows环境下你可以用System.IO读写本地文件，但在微信小游戏环境里没有传统目录结构，文件操作必须通过适配层封装的文件系统接口。如果你在代码里用了File.ReadAllText、Directory.GetFiles这类API，构建时不会报错，但真机上运行到这段代码就会抛异常。解决办法是：所有配置文件改用Unity的Resources或Addressables加载，运行时数据用PlayerPrefs（适配插件会把它映射到本地缓存），需要下载的文件（比如AssetBundle）用UnityWebRequest加载而不是自己管理路径。
**第三个差异：渲染性能天花板低。**手机的CPU/GPU性能本身比PC弱一大截，加上WebGL跑在浏览器内核里，性能更是打折扣。我的经验是：场景里的实时光源数量控制在1到2个，阴影尽量关掉或只保留方向光阴影，避免使用后处理特效（Bloom、HDR、抗锯齿等），UI的DrawCall控制在60到80以内，粒子和动画数量降到最少。Unity适配插件自带了一个3D渲染优化选项，建议开启。另外，分辨率适配也要处理：小游戏的手机会出现刘海屏、挖孔屏等异形屏，建议用CanvasScaler的"适配屏幕宽度"模式，并预留安全区边距，避免UI被刘海遮挡。
**第四个差异：操控方式完全不同。**PC上的第一人称射击、键盘操作、鼠标悬停等交互方式在手机触摸屏上都要重新设计。大多数小游戏采用单指点击、双指缩放或全屏触摸拖拽，你也可以调用微信小游戏的触摸API获取更丰富的触控信息，比如多点触控坐标、力度和角度。但要注意：普通Unity的Input.GetMouseButton在适配层里也能工作，它会把触摸事件映射为鼠标事件，但映射后的鼠标坐标和手感会和原生触摸有差异，追求精细操控（比如绘图、驾驶类）的游戏应该直接用触摸事件。
**第五个差异：微信小游戏不是沙盒，但你的数据也不是随意存。**登录用户数据、排行榜、好友关系这些能力在Unity适配插件里有对应的JavaScript接口，但在Unity侧不能直接调用微信的JS SDK，而是通过适配插件提供的C#接口桥接。比如要实现好友排行榜，Unity侧需要调用插件的WX.GetUserInfo、WX.SetUserCloudStorage等接口，通过一段C#封装类去调用微信API，再在CS代码中读取返回值。这个过程涉及JavaScript和C#的双向数据传递，Unity侧拿到的是一个字符串或对象，需要自己处理JSON解析。很多教程里说的"获取好友排行榜"功能，其实就是这么做的。
4. 打包前的Player Settings配置：每一项都值得逐字检查
Unity工程准备开始打包时，不是直接Build完事。如果你用默认的WebGL设置导出的包，转成小游戏后大概率跑不起来或者性能极差。这里把我在实践中验证过的配置项整理成清单，照着设置基本不会错。
Scripting Backend和代码裁剪：在Player Settings的WebGL标签下，Scripting Backend必须选IL2CPP，这是官方适配方案的要求，也能让最终代码更小、运行更稳。Managed Stripping Level建议设为Low。有人为了减小包体把裁剪等级设成High或Medium，结果运行时某些类型被错误裁剪掉，反射相关的功能直接崩溃，排查起来极其痛苦。只要你的包体是通过资源优化来控制的，而不是靠代码裁剪，就不要在高等级裁剪上冒险。
**压缩格式：**WebGL打包的Compression Format建议选Brotli。微信开发者工具和真机都能正常解压Brotli压缩的包体，而且压缩率比Gzip高，能进一步缩小首包体积。注意不要选Disabled，否则包体体积可能膨胀30%以上。如果遇到某些Android机型加载缓慢，可以尝试Gzip对比，但绝大多数情况下Brotli是最佳选择。
Shader精度和渲染设置：在QualitySettings里把阴影质量调到最低或关闭，抗锯齿设为2x或关闭，纹理质量设为低或中。这些设置会直接影响最终包体和运行时帧率。另外，建议在Project Settings的Graphics里确认Always Included Shaders中只保留实际用到的Shader，尤其是UI/Default和Sprites/Default这两个常用Shader，否则每次加载新Shader都会触发Shader编译卡顿。
**启用微信小游戏适配插件的构建钩子：**官方适配方案安装后，需要确认项目里存在对应的编辑器脚本（通常在Assets/WebGLTemplates或项目根目录下），它会在Build完成后自动执行转小游戏的步骤。如果没有自动触发，你需要手动运行菜单项里的"转换微信小游戏"，这个步骤会把Unity生成的WebGL目录转化为小程序项目结构，生成game.json、project.config.json、game.js等文件。
还有一个很容易被忽略的配置：Publishing Settings里的"WebGL Memory Size"（内存大小）。小游戏运行时如果内存太小，Unity在真机上会频繁GC甚至崩溃；内存太大，低端手机会内存不足直接闪退。我通常设置为128MB或256MB，具体看游戏资源量调整。如果游戏整体资源不大，可以设置成64MB，但低于64MB时3D游戏基本跑不动。
**模板设置：**官方适配插件通常会提供自定义的WebGL模板（比如带加载进度条的模板），打包时在Player Settings的Resolution and Presentation里把模板选为适配插件自带的"微信小游戏"模板，而不是Unity默认的WebGL模板。这一步如果不做，转换工具可能无法正确识别构建产物，导致转换失败。
这些配置改完之后，建议先用模拟器跑一遍。微信开发者工具里导入小游戏项目后，能看到Unity的启动画面和游戏画面，如果这一步正常，说明工程配置基本没问题。模拟器和真机渲染存在差异（模拟器更容易跑起来），但至少能排查出逻辑和资源加载层面的问题。
5. 微信公众平台后台：AppID、类目、域名这些关键配置逐个讲
很多人把工程打包好了，却在公众平台后台的配置上卡住。后台配置看似简单，但每一步都和后续的上传、审核、真机运行强相关，我实际跑通过一次后整理了一套顺序，按这个顺序来会省掉很多来回折腾。
5.1 注册与身份验证后的首要动作：创建一个小游戏类目的AppID
个人主体注册完成后，进入微信公众平台，在"设置-基本设置"里能看到一个小程序AppID，这个AppID是你后续所有开发工具、SDK接入、开发调试的统一标识，也是小游戏的唯一身份，不要泄露给无关人员。个人主体默认只能创建一个"小程序"，不是"小游戏"，但"小游戏"本质上是小程序平台下的一种特殊类目，开发工具和发布流程完全一样。你需要在后台的"服务类目"里选择你要发布的类目，比如"小游戏-休闲游戏"，选类目时注意看提示，如果提示需要资质文件（比如软著），说明这类目不适合免版号路径；选择不需要额外资质的工具类目，审核风险会高一些，因为平台会判断你的内容到底算不算游戏。
以我的实际经验，完全非商业化、无抽奖、无排行榜的互动内容，在免版号路径下选择"工具-效率"或"工具-教育"类目更容易过审，但前提是你的产品确实有工具属性、不能只是换了皮的打怪升级游戏。平台审核人员的判断标准是：看玩法是否有明显游戏特征（如关卡、积分、排行榜、虚拟奖励），如果有，就必须归入小游戏类目。
5.2 服务器域名的白名单配置
小游戏在运行时调用的所有网络请求地址（不管是UnityWebRequest还是Image下载）都必须在后台配置过合法域名，否则真机上请求会被拦截。这个安全策略是为了防止任意域名下的数据请求，在开发调试阶段可以临时关闭校验，但正式版本必须配置。配置位置在"开发-开发设置-服务器域名"，需要填request合法域名、downloadFile合法域名、socket合法域名、uploadFile合法域名。注意：
- 域名必须支持HTTPS，且证书有效。
- 域名必须有ICP备案（服务器所在地在中国大陆），这一点经常有人卡住，尤其是使用海外服务器的开发者，所以域名和服务器要提前规划好，最好使用国内云服务商。
- 每个月只能修改少量次数，所以域名确定后不要频繁更换，前期尽量对所有子域名做泛解析或规划好固定子域名。
5.3 AppSecret和Token的获取
如果你要自己搭建服务端做用户登录验证、排行榜数据存储等功能，还需要在"开发-开发设置"里生成AppSecret。这个密钥等同你的账号密码，不能放入前端代码，后端调用时才能使用。另外，小游戏前端要拿到用户登录态，需要调用wx.login接口换取code，后续由后端用code去微信接口拿openid和session_key，这里不做展开，但后台的AppSecret生成是前置条件。
5.4 用户隐私保护指引
微信从2023年起对用户隐私保护提出了明确要求，如果你收集了用户信息（头像、昵称、位置、手机号等），必须在后台的"设置-服务内容声明-用户隐私保护指引"中声明收集信息的目的和方式，并在代码中初始化隐私授权接口。小游戏如果不做用户头像昵称填写，通常不涉及敏感信息收集，但默认的wx.getUserInfo接口在新版本中已经受限，需要在代码中调用wx.getUserProfile或新的头像昵称填写能力来获取。我第一个版本因为调了旧接口，审核直接被驳回，后来在后台补齐隐私声明+前端改成新的填写组件才通过。
6. 首次打包上传：从Unity Build到微信开发者工具的真机调试
配置全部就绪后，进入最激动人心的打包环节。这里我把完整的流程走一遍，并标注出最容易报错的几个节点。
第一步，在Unity里打开项目，确保场景和构建设置正确，点击File-Build Settings，选择WebGL平台，点击Switch Platform（如果当前不是WebGL）。然后点击Player Settings做上一节里的那些配置修改。修改完后回到Build Settings，点击Build，选择一个输出目录（比如项目根目录下的WebGLBuild）。
第二步，等待Unity构建完成。构建时间取决于项目复杂度，一般几分钟到十几分钟，期间不要切换Unity进程。构建完成后，输出目录里会有一个Unity生成的WebGL标准工程，此时还没法直接用。
第三步，运行适配插件的转换脚本。安装官方适配方案后，菜单栏会多出类似"WeChat Mini Game"或对应插件的名称，点击转换或构建微信小游戏，工具会自动分析Unity输出目录，生成一个小游戏工程目录（通常名称类似minigame或wechatgame）。生成后查看是否包含game.json、game.js、project.config.json和unity相关适配代码。如果缺少project.config.json，之后微信开发者工具无法正确识别项目。
第四步，打开微信开发者工具，选择"导入项目"，目录指向刚才生成的小游戏工程目录，填入你的AppID（个人主体的小游戏AppID）。注意：如果你是首次导入，可能会提示"未配置合法域名"，在开发调试阶段可以勾选"不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书"，这样可以在工具里直接运行。
第五步，点击编译运行。如果一切正常，模拟器里会出现游戏画面（Unity的启动Logo或你自己场景）。如果只有黑屏和控制台报错，大概率是以下几种情况：基础库版本过低、代码裁剪过度、Shader编译错误、内存设置过低。逐项排查即可。
第六步，真机预览。点击开发者工具右上角"预览"，会生成一个二维码，用微信扫码即可在真机上打开你的小游戏。这个环节是你第一次亲眼看到小游戏在手机上运行，一定要重点关注帧率、内存占用、触摸响应、加载速度这几个维度。如果真机白屏但模拟器正常，优先检查基础库版本和WebGL渲染兼容性；如果有资源加载异常，优先检查网络请求域名或资源包路径。
第七步，上传版本。真机调试通过后，回到开发者工具，点击"上传"，填写版本号和项目备注，上传到微信公众平台。上传成功后，进入公众平台后台，在"版本管理-开发版本"里能看到刚才上传的版本，点击"提交审核"后进入审核排队状态。
这里有一个很容易踩的坑：上传时版本号不能重复，且版本更新需要设置合理的版本号规则。建议主版本号+次版本号+修订号的结构，比如1.0.0。每次上传新版本必须递增版本号，如果和线上版本号相同，会被拒绝。另外，个人主体的审核周期通常比企业主体长一些，常见的等待时间是1到5个工作日，快的也有当天通过的，慢的话可能要到7天。审核期间不要频繁重复提交，每重复提交一次审核排队时长可能会重置，这个是我亲身试出来的教训。
7. 提审被驳回的典型原因和应对方案
我前后提审过三次，前两次都因为不同理由被退回来。这里把最常见的驳回原因和对应的解决办法整理出来，能让你少走弯路。
7.1 类目选择与实际内容不匹配
这是最常见的驳回理由。比如你在后台选了"工具-教育"类目，但游戏里有明显的关卡、计时器、积分系统，审核人员会认为这属于游戏内容但未选择游戏类目，直接驳回。我的处理办法是：在符合免版号路径的前提下，弱化明显的游戏元素。比如把"生命值"改成"能量条"，把"等级"改成"学习进度"，在UI和文案上尽量向工具属性靠拢。当然，这只适用于本身就是轻量互动内容的项目，如果你的产品本质就是个正统游戏，就不要硬选了，老老实实走小游戏类目。
7.2 用户隐私政策缺失或未声明
个人主体开发者很容易忽略这一项。小游戏如果调用用户头像昵称填写能力、获取位置等，必须在后台隐私保护指引中声明，并且代码里要有隐私授权弹窗。如果你什么都没做，审核会以"存在未经用户同意收集和使用个人信息的行为"为由驳回。解决办法：后台配置隐私保护指引，前端在首次启动时调用相关API时弹出一个自定义的隐私弹窗，用户点击同意后再继续游戏逻辑。微信提供了官方组件用于隐私授权，Unity侧通过适配插件的接口调用即可。
7.3 页面截图不符合规范
提审时需要上传最多5张页面截图，并在页面路径里填写这些截图对应的场景。很多开发者直接截PC调试窗口的画面，分辨率比例不对或内容看不清，会被驳回。正确做法是：用真机预览，在手机截屏获取标准尺寸的图片，图片里尽量展示完整的核心玩法界面、操作说明、功能菜单。不要传首屏空白页或加载进度条页面。
7.4 标题和描述涉及极限词或夸大宣传
比如标题里带"全网第一""最强""免费无限"等词汇，审核会以"标题含有禁止使用的词汇"驳回。我遇到过"免费无限"这个词被驳回的案例，后来把标题改成普普通通的名称就过了。个人开发者起名字时尽量中性，不要用营销号风格。
7.5 分享行为诱导
如果你的游戏里设计了"分享后获得奖励""分享到群才能解锁下一关"这类机制，审核基本必挂。微信对诱导分享的管控非常严格，哪怕是个人开发者的小游戏也一样。我的做法是：去掉所有强制分享的按钮，分享入口做成用户主动且非强制的。分享时调用微信的分享API后，在客户端也拿不到"是否分享成功"的回调，所以这种设计本身也不利于逻辑实现。
整个审核流程走通之后，在公众平台后台"版本管理"里可以看到审核状态。审核通过后点击"发布"，你的小游戏就正式上线了。发布时可以选择全量发布还是分阶段发布（灰度），个人主体也可以用灰度发布，先给10%的用户看到，观察几天数据没问题再全量放出。
8. 上线后要盯的三个隐藏问题：性能、数据和隐私合规
游戏上架不是结束，而是真正开始面对真实用户。分享几个我在线上遇到并解决过的问题，这些问题在开发阶段很难触发，但线上必现。
8.1 性能问题的线上复现和优化
线上最大的意外是：同一份代码在同一台手机上，有时流畅有时卡顿。关键在于WebGL的自动垃圾回收和Unity引擎的资源加载机制。我遇到的典型案例是进入某个场景时卡顿两秒，原因是场景内所有UI的图集在第一次渲染时才上传GPU，解决办法是把图集预先加载和预热。另外，小游戏在Android端的兼容性整体弱于iOS，低端Android机经常出现内存占用飙高、WebGL上下文丢失（表现为游戏突然变白屏）的问题。遇到这种情况，建议在代码里监听WebGL上下文事件并尝试重新初始化，实在不行提供"重新启动"按钮；内存占用方面，可以定时执行Resources.UnloadUnusedAssets并调用System.GC.Collect，但注意别在游戏帧中频繁调用，否则会造成卡顿。
8.2 数据统计与分析
微信公众平台自带基础数据统计，可以看访问人数、打开次数、分享次数等，但这些维度不足以指导游戏优化。我建议开发者自己接一个简单的数据分析SDK，或者至少在后端记录关键事件：启动、注册教程完成、首局游戏结束、留存回访等。个人开发者没有必要上一套复杂的BI系统，在后端数据库里建一张事件表，每次游戏上报事件时插入一条记录即可。有了事件数据，才能有针对性地优化关卡难度、调整UI布局。很多团队不做事件埋点，上线后只知道"有用户玩"，却不知道玩家卡在哪一关，这其实是最可惜的浪费。
8.3 隐私合规的持续维护
平台对隐私合规的要求是持续更新的。我第一次上线后没有任何问题，过了半年平台更新了隐私保护政策，要求所有获取用户头像昵称的小程序/小游戏必须使用新的头像昵称填写能力，旧的wx.getUserInfo接口被强制废弃。我收到平台站内信提醒，随后改用了新接口提交了更新。这个教训说明个人开发者也要持续关注平台公告，不要上架后就不管了。还有一个容易忽略的细节：隐私协议里声明了什么，代码里就必须只做什么。如果你在协议里声明"收集用户头像用于排行榜展示"，那么代码里就不能把头像数据上传到第三方统计平台，一旦被检测到属于超范围收集，轻则警告，重则下架。
上线后还应该规划版本迭代节奏。微信小游戏的版本更新不需要用户主动更新，用户打开时平台会自动加载新版本，这给开发者带来了非常好的迭代条件。但要注意，新版本发布前一定要在开发者工具里做一次回归测试，尤其是重点路径（启动、核心玩法、存档）和重点机型。个人开发者测试设备有限，建议至少覆盖：一台较低端的Android机（比如入门级红米）、一台主流Android旗舰、iPhone SE和主流iPhone。
另外再分享一个针对Unity小游戏的优化小技巧：如果你的游戏在启动时需要加载多个AssetBundle，把第一个场景（启动场景）设计成纯代码生成的轻量界面，不在这个场景里引用任何大资源，让用户先看到界面、再在后台异步加载后续资源。这种设计能极大提升启动感知速度。我第一次上线时启动场景挂了一张1024×1024的启动图和几十个UI预制体，冷启动耗时接近8秒，用户流失严重；后来把启动场景改成纯代码绘制的基础进图页面后，冷启动降到了2秒左右，留存率有明显回升。这件事给我最大的感触是：小游戏的体验优化，优先级最高的是启动速度和首帧渲染速度，这两项直接决定用户留存。
最后想说的是，个人开发者做微信小游戏，最大的优势不是低成本，而是短反馈：从代码到真机调试只需要几分钟，从提审到上线只需要几天，这个反馈速度是企业团队很难比的。善用这个优势，多做版本迭代，哪怕一开始只有几十个用户，也能逐渐打磨出真正受欢迎的产品形态。我目前有几个小游戏就是这个路径上线维护的，收益虽然不算高，但看着自己的产品在微信里被陌生人打开，这种成就感是其他项目给不了的。
