Unity转抖音小游戏全流程实战：适配、打包、提审避坑指南

做Unity转抖音小游戏的这几个月，我最大的感受是：引擎侧已经相当成熟了，但真正卡住人的不是引擎，而是“容器适配+平台规则”这两道隐形门槛。如果你以为Unity项目做完，切个WebGL平台就能上架抖音小游戏，那大概率会在打包、适配和提审环节反复打转。这篇文章就一次性讲清楚Unity抖音小游戏从零到版本上线的全过程，包括环境搭建、项目适配、WebGL打包、开发者工具调试、提审材料准备，以及我实际踩过的坑和排查方法。不管你是刚准备入局的新手，还是做过微信小游戏想平移过来的老手，这份流程都值得存一份慢慢对照。

1. 项目设计思路拆解：先搞清楚小游戏和App游戏的区别

做之前总有人觉得，Unity就是写一遍到处跑，改个平台设置就能上线。这是最大的误解。抖音小游戏不是一个独立的原生平台，它跑在抖音App的容器里，本质上更接近“WebGL渲染+小程序外壳”的组合。你在Unity里写的C#逻辑没问题，但加载、存储、输入、UI渲染、资源策略都要按容器的规则来，不能用做App游戏那套思维硬套。

1.1 抖音小游戏到底是个什么东西

小游戏最直观的特点就是即点即玩，用户不用下载安装，在抖音里点开链接或者扫码就能进游戏。这个体验决定了它的技术形态：Unity项目不能直接以原生包形式发布，而是要先导出成WebGL产物，再通过字节官方提供的适配层，转换成抖音小游戏容器能识别的目录结构。

这个差异会影响很多架构决策。例如App游戏可以把几个GB的资源放本地，小游戏对包体有严格限制，主包资源必须精简，大量美术资源、音频、场景数据都要放到网络端，依靠首包加载和分包策略来动态获取。我在实际项目里见过有人把几十MB的AB包都塞进主包，结果是审核阶段就卡顿、白屏，上线后首屏加载慢得离谱。

另一个和App游戏完全不同的是流量入口。抖音小游戏的主要曝光渠道是短视频挂载、直播挂载、分享卡片、搜索和推荐，用户随时随地点开就能玩。因此玩法设计要更碎片化，首局能在30秒内进入核心体验，进度保存要快速可靠，分享引导要自然。这个思路如果立项阶段不确认清楚，后面上线了再改，等于重做。

1.2 为什么用Unity，什么情况下不该用

如果团队本身就是Unity技术栈，那用Unity做抖音小游戏是顺理成章的，3D渲染、粒子特效、物理模拟这些能力在小游戏容器里都能通过WebGL跑起来，字节官方的Unity适配插件也一直在更新。相比用Laya、Cocos或者字节原生小游戏方案从零搭一套技术栈，Unity的平迁成本最低，开发效率最高，尤其适合有3D表现需求、战斗表现需求、模型骨骼动画需求的项目。

但Unity不是万能的。如果你的游戏是超轻量级2D休闲玩法，比如答题、文字解密、IAA广告变现型小游戏，用Laya或Cocos打包出来的包体更小、加载更快，容器兼容问题也更少。Unity项目在WebGL容器里再怎么优化，基础运行库的体量和启动开销还是摆在那里的。

另外一个判断标准是玩法复杂度。如果游戏依赖实时多人对战、长连接通信、高精度音频、原生设备能力（比如蓝牙、NFC），那抖音小游戏容器目前支持和限制都比较多，很可能不适合放在这个平台首发。我做项目前的判断方式是：先看一眼玩法在浏览器里能不能跑得流畅，因为小游戏环境的性能上限基本等同于一个中端手机上的WebView，甚至更低。

2. 从零到一：环境搭建与最小工程

环境搭建是劝退新手的第一关。Unity安装、适配插件导入、开发者工具注册，每一步都有小坑。我建议严格按照顺序来做，不要跳步，也不要用太新的抢先版Unity，稳定压倒一切。

2.1 工具链清单与版本搭配

先列一份我实际用下来比较稳定的工具组合：

Unity安装这个环节就有人卡住。Unity Hub下载安装包慢、在Hub里装Editor版本半天没反应，这些都是老问题。我现在的习惯是直接去Unity官网的存档页面，用浏览器或者下载工具把对应版本的Editor安装包拉下来，再回到Hub里手动指定路径安装。这样能看到真实下载速度，也方便断点续传。装完之后记得在Hub里登录自己的Unity账号，否则打开工程激活许可证那一步会卡住。

字节的适配插件要认准官方来源，导入方式类似普通Unity包，一般是直接解压后把文件夹拖进项目的Assets目录，或者通过自定义包的安装入口导入。导入后Unity菜单栏会多出字节相关的构建菜单，这才是插件生效的标志。如果导入后菜单栏没有变化，多半是Unity版本和插件不兼容，或者插件要求的WebGL模块没装全。

2.2 账号注册与AppID申请

进入抖音开放平台后，先注册账号，然后做实名认证。个人主体和企业主体能做的事情差别很大：企业主体可以申请更多类目、接入虚拟支付、使用更多广告能力，个人主体基本只能做IAA广告变现和一些普通玩法类目，而且审核要求也略有不同。如果项目准备长期运营并且有商业化计划，建议一开始就用企业主体注册，后面补认证会耽误不少时间。

创建小游戏应用的过程不复杂，按引导填游戏名称、类型、简介，提交后就能拿到AppID。这个AppID相当于小游戏在平台上的身份证，Unity打包、开发者工具导入、提审上传都要用到。填名称和简介的时候想清楚，包名、游戏名、简介里的关键词会影响审核人员的第一印象，也影响后续搜索的匹配效果，别随便填。

还要留意域名配置。如果游戏里要请求网络接口，抖音开放平台要求配置合法域名，否则真机环境里请求会被拦截，开发工具模拟器里却一切正常。很多人在模拟器里测试通过就直接提审，结果审核人员真机一测，游戏里的排行榜加载失败，直接被拒。这个坑属于“上线前最后一刻才发现”的高频问题，提前配好。

2.3 5分钟跑通最小Demo

拿到AppID、装好工具链后，不要急着在自己正式项目上改造，先跑通一个最小Demo，验证整条链路是通的。新建一个Unity项目，把适配插件导入，场景里放一个Button，写一个点击后切换场景或者弹窗的脚本，然后按插件文档说明执行构建。

构建完成后，打开抖音开发者工具，选择“导入小游戏项目”，目录指向构建产物所在文件夹，填上AppID，模拟器里应该能直接看到你的Unity画面。这一步能跑通，说明Unity版本、插件、开发者工具版本三者之间没有不可调和的矛盾，后续正式项目也只是在这个基础上叠加内容而已。

在这个最小Demo里，我还建议放一个最基础的首屏加载进度条。小游戏加载Unity的WebGL运行时需要时间，如果用户点进来后画面长时间静止，他根本不知道游戏在加载，很容易直接退出。用插件提供的能力或者Unity自己的异步加载逻辑，做一个百分比进度条，哪怕很简陋，也能显著提升首屏留存。技术层面就是一个Slider组件，更新它的value。

using UnityEngine; using UnityEngine.UI; public class LoadingBar : MonoBehaviour { public Slider slider; private void Start() { StartCoroutine(LoadRoutine()); } private System.Collections.IEnumerator LoadRoutine() { for (float progress = 0f; progress < 1f; progress += Time.deltaTime * 0.5f) { slider.value = progress; yield return null; } slider.value = 1f; } }

3. Unity侧的关键适配：屏幕、UI与交互

小游戏跑在五花八门的手机上，屏幕比例、刘海屏、挖孔屏、底部手势条，任何一个都能让你的UI错位。这部分我会拆成分辨率安全区、点击热区、渲染遮挡、输入系统四个点讲，都是真机测试里最容易暴露问题的地方。

3.1 分辨率与安全区适配

Unity默认的Game视图分辨率很容易让人产生“只要设置成iPhone X的分辨率就行”的错觉。抖音小游戏容器的屏幕尺寸完全不固定，用户手机是什么比例，容器就是什么比例，你必须在运行时动态适配。

最稳妥的做法是Canvas Scaler设置为Scale With Screen Size，参考分辨率按你的UI设计稿来，比如常见的720x1280（竖屏）或1334x750（横屏），匹配模式用Shrink（收缩）或者Expand（扩展），这样不同比例下UI整体不会拉伸变形。具体选Shrink还是Expand，取决于你UI的关键元素集中在中间还是四边，需要拿真机一帧一帧看效果。

更麻烦的是安全区。刘海屏手机的顶部状态栏区域、底部横条区域，可能遮挡按钮也可能被按钮背景盖住。Unity里可以用Screen.safeArea拿到安全区矩形，但小游戏容器里要注意：字节适配插件一般会通过JS把真实安全区传到Unity层，如果你发现Screen.safeArea始终返回全屏矩形，就要去查一下插件的版本和接口。

我常用的适配脚本长这样，挂在Canvas根节点上，动态调整RectTransform的偏移：

using UnityEngine; [RequireComponent(typeof(RectTransform))] public class SafeAreaFitter : MonoBehaviour { private RectTransform rectTransform; private Rect lastSafeArea = Rect.zero; private void Awake() { rectTransform = GetComponent<RectTransform>(); Refresh(); } private void Update() { if (Screen.safeArea != lastSafeArea) { Refresh(); } } private void Refresh() { lastSafeArea = Screen.safeArea; float topOffset = Screen.height - lastSafeArea.yMax; float bottomOffset = lastSafeArea.yMin; rectTransform.offsetMax = new Vector2(rectTransform.offsetMax.x, -topOffset); rectTransform.offsetMin = new Vector2(rectTransform.offsetMin.x, bottomOffset); } }

这个脚本不是万能的，如果你的UI有多层嵌套，还需要配合锚点设置。但至少它能把最外层的安全区问题兜住，不会出现“按钮跑到状态栏下面”这种低级事故。

3.2 按钮热区这么调，手指不吐槽

手机上玩游戏，手指触点比鼠标粗糙得多。很多Unity项目的按钮视觉上画得挺大，但实际可点击范围很小，用户连点几下没反应，直接就滑走了。有一个热词特别能说明问题：“unity 如何扩大按钮的点击范围”。优化点击热区是移动端UI绕不开的事。

第一个方案是最容易理解的：视觉元素和点击热区分离。你在UI上放一个透明的Image作为按钮的热区，把RectTransform调整到你要的可点击范围，真正的按钮背景、文字放在它的子物体上，视觉上做小一点或者居中。这样做的好处是灵活，热区多大完全由你控制。

第二个方案是用Image.alphaHitTestMinimumThreshold，让图片的透明区域不参与点击检测。这是处理“按钮图片周围一圈透明区域把点击吞掉”的利器。比如你有一张圆形的按钮图，图片是正方形，四周透明。默认情况下，点击正方形角落也会被判定为点在按钮上，旁边另一个按钮就在角落区域放不下了。设置alphaHitTestMinimumThreshold后，透明像素不再被当作按钮区域，点击会穿透过去。

using UnityEngine; using UnityEngine.UI; public class AlphaHitTestButton : MonoBehaviour { private void Start() { var image = GetComponent<Image>(); image.alphaHitTestMinimumThreshold = 0.1f; } }

这里要注意，开启这个属性要求Texture的Read/Write Enable打开，而且图片本身的压缩格式会影响边缘表现的精度。实际调的时候，阈值不要直接拉到0.5，从0.1开始试，否则半透明边缘也会变得很难点中。

关于热区尺寸，我个人经验是：竖屏游戏里，核心按钮的热区尽量不小于60x60像素（以720x1280设计稿为参考），如果是需要频繁点击的移动摇杆或者跳跃键，最好做到80x80以上。人的手指在屏幕上是有接触面积的，热区做小了再流畅的交互也白搭。

3.3 阴影和UI遮挡：渲染层面的两个高频坑

“unity阴影问题”和“unity world ui 无遮挡”这两个高频词，开放者们应该都有共鸣。先讲阴影。WebGL容器里的实时阴影是一个非常奢侈的功能，开启实时阴影后，真机上帧率会明显下降，发热也会很严重。尤其是URP管线，阴影相关的Shader变体如果不做精简，构建出来的包体会变大，运行时Draw Call也会增多。

我的建议是：小游戏项目里尽量用烘焙阴影，静态场景的光照贴图和阴影贴图在构建时烘焙好，运行时不再实时计算；动态角色需要的阴影，用一张圆形Soft Shadow贴图放在角色脚底，或者用一个朝向地面的低分辨率投影相机动画，这样性能和表现都能兼顾。如果产品非要实时阴影，那就限制阴影距离、只保留主光源的实时阴影、阴影分辨率调到1024以下，并且做性能压测，顿卡掉帧明显就别硬撑了。

UI遮挡问题同样高频。Unity的UI有两种常用渲染模式：Screen Space - Overlay和Screen Space - Camera。Overlay模式是把UI画在屏幕最上层，不参与深度计算，所以永远不会被3D模型挡住，这也是它“无遮挡”的原因。World Space模式则是把UI当作3D空间里的物体，可以和模型产生遮挡关系，适合做血条、漂浮文字、互动图标这类需要贴在模型旁边的UI。

如果你的界面元素本来应该在最顶层，结果被3D物体盖住了，先检查Canvas的Render Mode是不是被改成了World Space或Screen Space - Camera。另一个容易踩的问题是多个Canvas之间存在渲染顺序竞争，在同一个Screen Space - Overlay下面，Sorting Order越大的越靠前。排查时先看RenderMode，再看SortingOrder，大部分遮挡问题都出在这两个地方。

3.4 输入系统：别让点击和触控在真机上失灵

字节小游戏容器对Unity新版Input System（输入系统）的兼容性，说实话没有旧版Input Manager那么稳定。我遇到过一次很奇怪的问题：在开发者工具模拟器里点击一切正常，用真机预览时UI按钮能高亮但是点击事件不触发，进度条拖动也卡顿。最后排查下来，跟Input System的Active Input Handling设置有关。

如果你不是非要用新输入系统的新功能，我建议在抖音小游戏项目里直接用兼容性最好的配置：在Player Settings的Active Input Handling里选择“Both”，让新旧输入系统同时生效，EventSystem用旧的Standalone Input Module。这样最保守，能减少很多莫名其妙的输入问题。

还有一种情况是触控和鼠标事件混杂。Unity WebGL在容器里通常会把触摸模拟成鼠标事件，如果你的代码里同时监听OnMouseDown和一些自定义Touch事件，会导致一次点击触发两次逻辑。我的经验是游戏逻辑统一走UI的Button点击或者Raycast检测，不要在核心玩法里直接监听Input.touches去判断“是否按下”，除非是做摇杆手势这种必须自己处理触摸坐标的场景。

摇杆和滑动操作要特别注意坐标转换。Unity的输入坐标和屏幕像素坐标在小游戏不同机型上会有差异，社区里有人反映触摸坐标偏移半个屏幕，多半是Canvas的 Screen Space模式和坐标转换没有统一导致的。做手势交互时，建议把Input.GetTouch的参数做一次“屏幕坐标转Canvas局部坐标”的换算，不要让不同系统层次的数据混用。

4. 构建与调试：从WebGL到抖音容器

构建阶段是把Unity工程送去适配层的最后一环，很多问题都在这个阶段集中爆发。构建配错了，后面全部白搭；构建配好了，后面调试效率直接翻倍。

4.1 WebGL导出参数怎么调

先在Build Settings里切平台到WebGL，然后打开Player Settings逐项检查。最容易出错的是Compression Format（压缩格式）。抖音小游戏容器对Brotli和Gzip都有一定支持，但不同版本兼容性有差异，我的建议是先用Gzip，如果包体实在太大再试Brotli。Brotli压缩率更高，但是解压耗时也更长，中端手机上可能比Gzip多几百毫秒，别只看包体大小。

Code Optimization和Strip Engine Code（代码剥离）这个选项能显著减小包体，但它会裁剪掉Unity引擎里“看起来没被引用”的代码。如果你的项目用了反射、序列化、代码里通过字符串创建类型这些特性，剥离器很可能把需要的类型也裁掉了，运行时会直接报MissingMethodException或者TypeLoadException。我见过一个项目发布模式白屏，开发模式一切正常，最后就是Strip Engine Code把JsonUtility反射用的类裁了。这种情况要在Assets目录下创建link.xml文件，显式声明哪些程序集和类型需要保留。

<linker> <assembly fullname="Assembly-CSharp" preserve="all" /> <assembly fullname="Unity.TextMeshPro" preserve="all" /> </linker>

有热词提到“unity gameassembly.dll的作用”，这里顺带解释一下。WebGL构建产物里存在gameassembly.dll对应的二进制数据是Mono和IL2CPP运行时相关的内容，在WebGL平台上它会被编译进WebAssembly，供C#逻辑在浏览器里执行。很多人在构建产物里搜到类似名字的文件，以为可以像桌面端SDK一样直接替换动态库，这是行不通的。WebGL平台的C#代码已经编译成wasm了，不能做动态库式热修，代码层面的保护只能靠混淆和混淆插件。

代码混淆这个事，我建议有商业化项目需求的重视起来。Unity C#编译到WebGL后，类名和方法名虽然经过一定处理，但用工具还是能还原出大量逻辑。市面上也有专门的Unity WebGL混淆方案，但接入成本不低，而且偶尔会和IL2CPP冲突。我的做法是：核心算法逻辑放到服务端，客户端只保留表现层和交互流程，这样即使客户端被逆向，也拿不到真正的业务核心。

4.2 PlayerPrefs的坑：IDBFS写入失败

“unity 发布 webgl 使用 idbfs 写入失败”这个热词背后，是WebGL环境下本地存储的一个经典问题。Unity在WebGL运行时用IDBFS（IndexedDB文件系统）来模拟本地文件写入，PlayerPrefs这类数据最终会落到浏览器的IndexedDB里。

页面环境对IndexedDB比较敏感：浏览器隐私模式、存储空间已满、用户禁用了站点数据、容器环境没有正确初始化文件系统，任何一条都会让你在调用PlayerPrefs.Save时看到“idbfs写入失败”之类的报错。开发者工具里一切正常，换到真机预览就报错，原因大概率就在这里。

处理方案分两级。第一级，清理和使用兜底：在写PlayerPrefs前检查存储是否可用，如果不可用就把要保存的数据退化成内存存储，至少保证本次游戏进程内数据不丢。第二级，绕开Unity的存储层，直接用平台存储接口。字节小游戏在适配层一般会提供Bridge能力，对应到小程序侧的tt.setStorageSync/tt.getStorageSync，这些接口是容器层面的，比IDBFS稳定得多。我在项目里封装了一层IMiniGameStorage，写入时优先走平台接口，失败时才回退到PlayerPrefs。

using UnityEngine; public static class MiniGameStorage { public static void SetString(string key, string value) { #if UNITY_WEBGL && !UNITY_EDITOR // 通过适配插件提供的Bridge写入平台存储 if (PlatformBridge.CanUsePlatformStorage) { PlatformBridge.SetStorage(key, value); return; } #endif PlayerPrefs.SetString(key, value); PlayerPrefs.Save(); } public static string GetString(string key, string defaultValue = "") { #if UNITY_WEBGL && !UNITY_EDITOR if (PlatformBridge.CanUsePlatformStorage) { string result = PlatformBridge.GetStorage(key); return string.IsNullOrEmpty(result) ? defaultValue : result; } #endif return PlayerPrefs.GetString(key, defaultValue); } }

实际踩下来的体验是，PlayerPrefs在WebGL上写入频繁的时候还会出现写入竞态，连续多次Save偶尔会丢数据。保存进度的场景，我建议做“关键节点+冗余保存”，不要只存一份数据，写入后读回来验证一下，发现异常就用备用存档。

4.3 抖音开发者工具里的调试流

构建产物导入抖音开发者工具后，我有几个固定的调试步骤。先在模拟器里跑一遍功能流程，确认UI、交互、加载都没问题；然后扫码真机预览，重点测性能、输入、存储、网络这四类问题；最后再回到开发工具里开Network面板，检查所有资源请求的状态码和耗时。

开发者工具里有一个很容易被忽略的作用是“编译模式切换”。开发阶段用开发模式，能看到更多调试日志；上传提审前切到正式模式，模拟用户拿到的是压缩后的包。有些问题只会在正式模式暴露，比如代码剥离导致的功能缺失、压缩资源加载失败，所以提审前一定要在正式模式下完整回归一遍。

“抖音小游戏链接”也是这里容易搞混的概念。开发者工具生成的是开发预览的临时二维码，有效期比较短，用来自己调试；体验版二维码是给协作者、审核前小范围测试用的，有效期相对长；正式上线后才会有稳定的小游戏链接和推广二维码。你分享给别人的时候，先确认对方拿到的是哪个阶段的链接，避免别人扫码后提示已过期。

模拟器和真机表现的差异我强调很多次：字体渲染、阴影效果、输入延迟、触觉反馈、网络速度，这些通通有差异。调试的时候养成“模拟器确认逻辑，真机确认体验”的习惯，能少走很多弯路。

5. 上架审核完整流程

上架审核是整个项目的临门一脚。很多项目技术上没问题，却在素材、版号、隐私政策这些非技术环节被反复打回，耽误好几周时间。流程走顺一次，后面版本迭代就轻车熟路了。

5.1 版本状态流转与提审操作

抖音小游戏的版本状态一般有开发版、体验版、审核版、线上版。开发版只有你自己扫码能看，适合日常调试；体验版可以通过二维码分享给团队成员和测试人员，还可以配置体验成员名单；提交审核后进入审核版状态；审核通过后点发布，才成为线上版。

提审操作在开放平台找到对应小游戏应用，进入版本管理页面，选择要提审的版本。填版本号的时候要跟你在代码里设置的版本一致，否则很容易混淆。版本说明尽量写得详细清楚：这版本新增了什么功能、修复了什么bug、有没有需要审核人员特别注意的测试路径。审核人员也是人，说明写得清晰，审核效率会高很多，被打回的概率也会下降。

审核周期我遇到的情况是1到3个工作日，节假日和平台大促期间可能延长。如果提审后发现版本致命bug，需要尽快撤回并修改，不要想着“也许能过”，审核一旦打到问题，不仅浪费时间，还可能影响账号的信用评估。

5.2 提审素材清单与填写建议

提审素材是很多团队准备最仓促的部分。我列一张清单，照着整理基本不会漏：

截图这块我踩过坑。有一次直接用开发者工具的模拟器截图提交，画面里带着调试窗口的边框和数据栏，审核人员一眼看出来，以“素材与实机不符”为由驳回。后来我学乖了，每次提审都用真机截图，并且把游戏的赞助商、测试账号这类敏感信息遮挡干净。

简介和类目选择要匹配。抖音小游戏对类目有白名单限制，某些类目需要额外资质，比如涉及文化、出版、教育的内容。如果你拿不准，提前去开放平台的类目说明里查清楚，比提交后再被打回节省时间。

5.3 常见拒审原因和处理姿势

我整理过自己和其他开发者的拒审记录，高频原因大概这几种：

被拒之后先不要慌，把驳回理由截图存下来，回到本地逐步复现。大部分功能性拒审都能通过“正式模式真机测试”复现出来，因为审核人员用的就是真机和正式包。处理完重新提审时，在版本说明里简单写一句“已修复xx问题”，审核人员看到你理解了他们退回的原因，流程会顺畅很多。

还有一条很重要：被拒的原因如果涉及内容违规，比如某个按钮文案、分享语被判定为诱导或者敏感，不要尝试换个说法再提一遍，平台会重点复查历史违规项。老老实实把功能删掉或者改成合规的交互，才是长久之计。

6. 常见问题排查实录

最后的章节用来集中记录我过程中遇到的高频问题和排查思路，基本都可以直接当成速查表来用。

6.1 高频问题速查表

这个表的每一条，我基本都在这类项目里遇到过至少一次。最容易被忽略的是最后一条：游戏逻辑里大量对象的Update每帧都在做无用计算，即使画面不动，CPU也一直在空转。移动端对功耗特别敏感，能在不渲染时不渲染，能在不计算时不计算，带来的体验提升比单纯调画质更明显。

6.2 三个印象最深的排查案例

第一个案例，按钮点不到但视觉反馈有高亮。项目里一个圆形按钮，Image本身是正方形图，透明区域占了一半。用户点按钮边缘时UI高亮了，但点击逻辑没有触发，因为透明区域没有被Button识别成可点击区域。排查时发现这张图片的alphaHitTestMinimumThreshold被设置成了0.1，但边缘半透明像素低于这个阈值。把阈值降到0.01，问题解决。注意这个问题在模拟器和真机表现还不完全一样，因为压缩后的透明边缘精度不同。

第二个案例，发布包在审核设备上白屏，本地反复测试没问题。最后查下来是Strip Engine Code把Newtonsoft.Json的一个运行时生成类型裁掉了，导致存档反序列化出错，启动流程直接崩溃。修法就是在link.xml里把Newtonsoft.Json以及项目里用到反射的库都保留。那次之后，我在所有WebGL项目的link.xml里都默认加上反射库保留规则，宁可包体大几MB，也不冒白屏风险。

第三个案例，加载进度条卡在99%，然后就没有然后了。排查发现进度条逻辑自己循环到99%后等待场景加载完成，但场景里的某个AB包资源因为CDN地址配置错误加载失败，场景永远没切换完成。进度条本身反而成了误导。从那以后我的进度条逻辑改成“真实进度+超时兜底”，CDN资源加载失败就主动报错重试，不把用户晾在99%的界面上干等。

最后再分享两个小技巧

做了几次抖音小游戏版本迭代之后，我养成了两个习惯。第一个，开发者工具的缓存清理要当成肌肉记忆。每次改完代码发现模拟器表现没变，不要怀疑自己改错了，先清一次缓存再跑，比反复看代码更快定位问题。第二个，每次提审前都把“正式模式+真机预览+隐私政策检查+素材核对”这四步流程走一遍，形成一份固定的QA清单，虽然简单，但能挡住90%的低级拒审。

做Unity抖音小游戏这个方向，说到底就是两件事：技术上适应WebGL容器，规则上适应平台玩法。很多坑都是通用的，希望这份实战记录能帮你少走几趟弯路。