这个标题起的有点标题党，但确实就是我前两天干的事——把 2018 年用 Unity 写的一个类《保卫萝卜》塔防 Demo，从本地 Windows 播放器搬到了浏览器里能直接打开玩。全程没用游戏引擎手动重新编译，主要靠 AI 辅助改代码、调参数、排查 WebGL 构建问题，前后花了大概两个小时。整个过程没有想象的那么玄乎，但也不是 AI 一键搞定那么轻松，中间踩了几个非常典型的 Unity WebGL 坑，尤其是存档写入失败和资源内存优化，这两块几乎每个做 WebGL 移植的人都会碰到。这篇就完整记录一下我怎么做的、AI 在其中到底起了多大作用、以及哪些地方是它帮不了你必须自己动手的，给同样想把手头 Unity 项目搬上浏览器的朋友做个参考。
1. 为什么要费劲搬到浏览器：老项目的第二个归宿
先说背景。这个项目是我 2018 年练手写的，玩法就是很标准的塔防：地图上有路径，敌人从起点走到终点，玩家在路径两侧放炮塔，炮塔会自动攻击射程内的敌人，打死敌人给金币，用金币再升级炮塔。当时用的 Unity 版本应该是 2018.4 LTS，UI 还是最古老的 UGUI 那套写法，场景里放了好几个 Canvas，逻辑代码主要靠 C# 的协程和 Update 轮询。项目一直躺在硬盘里，最近翻出来想看看能不能整理成作品集里的在线试玩版本。
为什么非要搬到浏览器？两个原因。第一，发一个 Windows 玩家包给别人，对方要先下载几百 MB 的东西，还要担心被杀毒软件拦截，体验很劝退。做成 WebGL 版发个链接就能玩，微信里点开也能跑，这对作品集展示和分享给朋友来说方便太多了。第二，我当时并不确定 Unity WebGL 的坑到底有多大，正好想借这个项目搞清楚，以后要是做数字孪生、室内漫游这类偏展示型的项目，能不能直接走 WebGL 路线。
但 2018 年的项目直接切到 WebGL 平台构建，大概率是编不过的。老项目里用了一堆新版本 Unity 已经不怎么推荐的做法，比如在 Update 里频繁 Instantiate 生成敌人、直接用UnityEngine.UI的旧 API、场景里有 1024x1024 甚至更大尺寸的贴图忘了压缩。这些在本地播放器里跑没问题，但一旦上了 WebGL 这个资源敏感、API 受限的环境，就会变成灾难。所以第一步不是打开 Build Settings 切平台，而是先评估项目的现状。
我用了一个下午先把项目在 Unity 2018.4 里打开确认能正常跑，然后把整个项目文件夹复制了一份，用 Unity Hub 安装的 Unity 2021.3 LTS 打开了副本。这里有个很重要的经验：老项目迁移到新版本 Unity，千万不要直接在原项目上操作，一定要复制一份。因为新版本打开老项目会自动升级一些资源格式和脚本 API，本地又没法回滚，万一中间出了岔子，原项目也毁了。复制一份随便折腾，最后能成功就把新项目当成果，不能成功也不影响原始文件。
用 2021.3 打开之后，Unity 的升级报告里果然列了十几个警告，主要是两类：一类是部分脚本用到的 API 被标记为过时，一类是 UGUI 的某些属性访问方式变了。这个阶段 AI 帮了大忙。我直接把 Console 面板里的所有警告和报错逐条复制给 AI，让它给出针对性的修改建议。AI 很清楚 Unity 不同版本之间 API 的变化趋势，比如告诉我WWW类要换成UnityWebRequest，gameObject.GetComponent<Button>().onClick.AddListener这种写法在新版本里依然能用但推荐用UnityEventTools之类。但说实话，老项目体量不大，很多警告其实不修也能编过，我只是为了让构建更干净，才顺手处理了主要的那几个。
2. WebGL 构建前的关键检查：资源和 API 的兼容性补课
很多第一次做 Unity WebGL 的人有个误区，以为在 Build Settings 里切一下平台，点一下 Build 就能出来一个网页版游戏。实际上切到 WebGL 平台之后，Unity 会重新导入所有资源，这时候大量问题才开始浮出水面。2021.3 的 WebGL 后台用的是 IL2CPP，和之前在本地播放器里使用的 Mono 后台在代码兼容性上有不少差异，比如 AOT 环境下不支持反射的一些用法，泛型和委托的使用也更受限。如果你的项目里有用到System.Reflection做动态调用，或者代码里有很多 List 和 Dictionary 的序列化操作，这些地方要特别小心。
我这次项目最麻烦的其实不是代码，而是资源。2018 年做项目的时候，贴图基本都是从网上找的素材直接拖进去用，完全没有考虑过内存占用。切到 WebGL 平台后，Unity 默认会为 WebGL 启用资源压缩，但只是简单压缩，对超大尺寸的贴图并不会自动缩小。我的项目里光 UI 背景图就用了好几张 1920x1080 的 PNG，还有一些炮塔和敌人的精灵图集，加起来原始资源量将近 300 MB。如果照这个样子直接构建，生成的 WebGL 包会非常臃肿，浏览器加载要等半天，运行时的内存占用也会逼近浏览器对 wasm 的 2GB 上限，玩到后期敌人一多大概率直接卡死。
这块的处理步骤比较机械但很重要。我先把整个 Assets 目录下的所有贴图按内存占用排序，找到最大的几个文件，把它们的 Max Size（最大纹理尺寸）调低。UI 背景图虽然是 1920x1080，但实际显示区域可能就占屏幕一部分，降到 1024 或 512 完全够用；炮塔和敌人的精灵图集如果是像素风，本身就不需要 2048 的尺寸，降到 512 和 1024 组合就足够了。然后是纹理压缩格式，在 WebGL 平台上 Unity 支持 ASTC、ETC2 等格式，等等，实际上 WebGL 的压缩纹理支持要看目标浏览器和显卡，为了兼容性我直接用了默认的 Compressed 选项，但把 Use Crunch Compression 打开，这样构建出来的资源体积能再小一截。这个阶段切完平台之后的资源导入消耗了一次完整的资源管线重跑，我的笔记本风扇转了半个小时才消停。
处理完资源体量，还要检查有没有在 WebGL 平台下不能用的功能。我这个项目里其实没用到什么高级功能，没有自定义 Shader，没有 OnGUI，也没有文件读写，所以整体还算顺利。但有一个隐藏问题差点翻车——存档系统。当时我用的是非常原始的PlayerPrefs存金币数和关卡进度，这个 API 在本地播放器里是写入本地文件，但在 WebGL 下，PlayerPrefs会被自动映射到浏览器 IndexedDB，正常情况下没问题，可如果用户在浏览器设置里屏蔽了站点的存储权限，就会静默失败。这个后面专门说，因为这是所有 WebGL 游戏都会遇到的一个坑。
AI 在这个阶段做的事主要是帮我写了一个快速的资源检查工具，就是用编辑器脚本遍历所有贴图和音频资源，输出它们的尺寸、格式和预估内存占用，并自动标红超过我设定阈值的资源。AI 给的脚本思路很简单，核心就是几行AssetDatabase.FindAssets加TextureImporter类型判断，但省去了我手动在 Project 面板里一个个点的工夫。这类脚本属于编辑器扩展，网上到处都有现成的，但让 AI 针对我这个项目的目录结构和命名规则微调一下，比我自己从零写要快得多。
3. AI 辅助实际改代码：从 C# 到兼容 WebGL 的迁移细节
项目资源和 API 兼容性处理完，接下来就是真正的代码层面调整。这个项目不大，一共就十几脚本，但里面有好几个地方需要针对 WebGL 环境专门处理。
第一个改动点是敌人死亡时的特效生成。我原来的写法是在Update里用Instantiate动态创建特效对象，然后等特效播放完再用协程延迟销毁。这种写法在本地没问题，但 WebGL 下频繁的 Instantiate 和 Destroy 会导致堆内存暴涨，因为 wasm 的堆不像 Mono 那样会自动归还内存给操作系统，一旦峰值涨上去就不会降下来，玩久了整个页面会越来越卡，最终可能白屏或崩溃。这里最合适的方案是用对象池。我把所有敌人的生成、子弹的生成、特效的生成全部改成从预设好的对象池里取，用完再还回去。AI 帮我生成了一套通用的ObjectPool泛型类，还自动把所有调用点从Instantiate改成pool.Get()和pool.Release()，这个工作量如果手写，至少要一个上午，AI 大概十几分钟就完成了。
第二个改动点是协程和异步逻辑。2018 年我写协程用得很随意，WaitForSeconds到处都是。老项目在 WebGL 下协程本身没问题，但有个潜在的性能风险：如果协程持有大量临时变量或者循环中产生闭包分配，在低端设备上会产生频繁的 GC。AI 帮我审查了一遍所有协程，把几处可以在 Update 里用计时器解决的简单延时改成了非协程方式，剩下真正需要协程的地方，比如敌人波次控制，保留了原逻辑但优化了内部写法，避免每帧产生新的分配。说实话，这种优化对一个小项目来说可能感知不强，但既然上了 WebGL，内存就是第一优先级，多做一点不亏。
第三个改动点是场景加载方式。原项目只有一个主场景，所以没用到场景切换。但如果你的项目有多个场景，WebGL 下面不能像本地那样用SceneManager.LoadScene同步加载，因为所有场景都打包进了一个文件，加载会导致卡顿。我记得 Unity 官方推荐的是用SceneManager.LoadSceneAsync加异步加载条。但这次项目用不着，我就没让 AI 改这里的逻辑。
AI 改代码的过程并不是一条命令自动完成，而是一段一段来。我先把我认为有问题的脚本贴给它，它给出修改后的完整代码，我再手动在编辑器里替换。关键是我会把 Unity Console 里报的错直接复制给它，它通常能很快定位到具体行。比如有一次报了个InvalidOperationException: Operation is not valid due to the current state of the object，AI 看了一眼就判断是某个列表在遍历时被修改了，让我把 foreach 改成 for 循环倒序遍历。这个错误在本地播放器里居然从没出现过，因为 WebGL 下的字典迭代顺序和 Mono 下不一样，暴露了代码里潜藏的 bug。所以这里我的建议是，不要相信 AI 改的每一行，但要把 AI 当成一个能大幅缩短你定位问题时间的助手。它给出的代码你最好能读懂，或者至少能快速验证结果是否正确，不然后面出了问题会非常难排查。
4. 构建和浏览器里的实测：IDBFS 写入失败与内存优化的实战排查
所有代码改完之后，我切到 WebGL 平台，点下 Build。第一次构建总共花了大概二十分钟，其中 IL2CPP 编译占了大头。跑完之后浏览器打开，游戏能启动，主页能正常显示，点开始游戏，场景能载入，炮塔能放置，敌人能走路径，第一波打完金币数字能涨。当时我心想，就这？WebGL 也没网上说的那么吓人。然后就被打脸了——打到第三波，我想把金币存到 PlayerPrefs 里刷新一下页面测试存档功能，刷完之后，金币数清零了。
这里就是热搜词里那个非常典型的求问题：“unity 发布 webgl 使用 idbfs 写入失败”。Unity WebGL 的文件系统是虚拟的，PlayerPrefs 底层用的是 IndexedDB，但只在符合特定条件时才会写入成功。如果页面不是通过 http/https 协议打开的，比如直接用 file:// 协议打开本地 index.html，浏览器会限制 IndexedDB，导致写入失败。另一个更隐蔽的情况是，即使通过本地服务器打开，如果页面在隐私模式、iframe 嵌入、或浏览器的“阻止第三方存储”开启时，也可能写不进去。我这次是直接用 VS Code 的 Live Server 插件起的本地 http 服务，按理说没问题，但金币数量还是清零了。
排查了很久，最后发现根本不是存储权限的问题，而是 PlayerPrefs 写入时机的问题。我原来的代码是PlayerPrefs.SetInt("coin", coinCount);没有任何 Save 调用。在 Mono 环境下，SetInt 会立刻写入内存，应用退出时系统会自动保存，但在 WebGL 下，Unity 会在页面beforeunload事件里自动触发保存，可是我当时为了测试是直接点浏览器的刷新按钮，这个触发时机偶尔会丢失，导致 Coin 没有写入 IndexedDB。解决方法是调用完 SetInt 后立刻跟上PlayerPrefs.Save()，强制执行同步写入。这个问题很小，但搜一遍社区可以发现无数人遇到过。AI 也帮了这个忙，我给它看代码之后，它立刻指出缺少 Save 调用，还提醒我要在关键节点比如升级炮塔、游戏结束、切关卡时保存，不要每帧都调 Save，因为 Save 在 WebGL 下是异步写 IndexedDB，过于频繁会产生大量事务，反而影响性能。
IDBFS 是另一个让我踩坑的地方。Unity 的 WebGL 支持一种叫做 IDBFS 的挂载方式，可以把内存文件系统映射到 IndexedDB，用于持久化数据。如果你的项目里用到了File.ReadAllText或Directory.CreateDirectory这类操作，在本地能跑，但 WebGL 下如果文件系统没有挂载到 IndexedDB，目录数据就是临时内存，刷新页面就没了。我当时在项目里写了一个简单的日志功能，会把每次战斗的战斗记录写入本地文件，这个功能在播放器版本里没有暴露明显问题，但在 WebGL 下如果不管它，每次刷新都会导致文件丢失。因为我这次的目标只是做一个能在线玩的 Demo，不需要持久化战斗日志，所以我直接把日志功能停用了。但如果你做的是一个真正需要读外部配置表或保存自定义存档的游戏，就必须在 C# 代码里调用UnityEngine.WWW或UnityEngine.Networking.UnityWebRequest来加载外部文件，写入则要挂载 IDBFS，这需要你自己写 JavaScript 插件配合实现，Unity 官方文档里有示例，但工作量和复杂程度会明显上升。
然后是内存问题。WebGL 的内存可以简单理解为一个 2GB 的虚拟地址空间，其中一部分是堆内存，另一部分预留给了渲染和其他系统。游戏里如果同时存在的物体太多，内存会被顶到接近上限。我的塔防项目在后期第 20 波的时候，同时场上最多有 40 个敌人、50 个炮塔、几十发子弹和一堆特效，实测内存占用大概 1.2GB，虽然没有爆掉，但能感觉到明显的帧率波动。AI 给我的优化方案是去掉不必要的实时阴影和后期处理，限制最大帧率到 60，把敌人的 NavMeshAgent 换成纯坐标移动，因为塔防里敌人的路线是固定路径点，根本不需要寻路组件，这是最重的性能杀手。我按照它的建议删掉了所有寻路组件，直接在 Update 里往下一个路径点移动，性能立刻上去了，内存占用也降了两百多兆。这个改动如果让我自己找，可能还要花一个小时看 Profiler，但 AI 从代码结构就能推断出问题所在，这种维度确实比搜索引擎好使。
5. 发布和后续可玩的优化：实际上线需要处理的问题
构建和调试通过之后，游戏在浏览器里已经能正常玩了，但离真正发给别人玩还有几步路要走。首先是构建产物的部署。Unity WebGL 构建出来的文件通常包括一个 index.html、一个 Build 目录（里面是 wasm、js、data、framework 等文件）和一个 TemplateData 目录。你不能直接把整个文件夹发给别人让人打开 index.html，因为浏览器安全策略会阻止跨域加载。我当时把整个构建产物放到了自己的云服务器上，用 Nginx 静态托管，然后给了一个链接，手机和电脑都能正常访问。如果你没有服务器，可以用 GitHub Pages、Vercel 或 Netlify 这类静态托管平台，都是免费的，不用备案也能用，但是要在项目设置里把压缩格式选成 Brotli 或 Gzip 支持，否则网络传输体积会大不少。
部署完还要检查浏览器的兼容性。我实测了 Chrome、Edge 和手机上的微信内置浏览器，Chrome 和 Edge 表现最好，微信内置浏览器偶尔会遇到 WebGL 上下文创建失败的情况，尤其是旧的安卓机。这通常和手机 GPU 驱动对 WebGL2 支持不完整有关。解决办法是在 Unity 的 Player Settings 里把 Graphics API 设置为自动选择，让它优先用 WebGL2，如果创建 WebGL2 上下文失败就自动回退到 WebGL1。我没有对移动端做专门的 UI 适配，因为原来的 UI 就是为 PC 设计的，但朋友的手机上也跑起来了，只是按钮有点小，需要放大浏览器页面才能操作。如果你想做手机适配，得重新设计 UI 的 Canvas Scaler 模式和按钮尺寸，这块工作量会很大，不太适合只想展示的水平。
还有一个很容易被忽略的问题是加载体验。WebGL 构建出来的文件一般都在几十 MB 甚至上百 MB，用户打开链接后如果白屏等了十秒钟，基本就关掉了。Unity 自带的加载界面很简陋，默认只有一个进度条。我给项目写了个简单的加载遮罩，把进度条和启动画面都换成了自己的 Logo 和加载动画，这是通过修改 TemplateData 里的 index.html 实现的。AI 在这里帮了个小忙，帮我改了一版加载遮罩的 CSS 和 JS，让进度条可以读取 Unity 的初始化和下载进度。如果你想省事，也可以直接在游戏的第一个场景里做一个按任意键开始的画面，至少用户等的时候还有东西看，不会觉得页面死了。
最后说一下这个项目的后续扩展方向。因为 WebGL 版已经可以跑通，我接下来想给它加一个简单的排行榜和关卡编辑系统。排行榜需要一个后端，但我不想花时间维护服务器，所以可能会用微信云开发或者 LeanCloud 这类 BaaS 服务，C# 代码里用UnityWebRequest去请求接口。关卡编辑器就更有意思了，我想把地图的格子数据序列化成 JSON，美术上直接用代码生成格子地面，这样以后换地图就特别方便。这些功能如果从零开发需要不少时间，但有了 AI 辅助写基础的 HTTP 封装和数据解析代码，效率会高很多。
6. 总结这次移植的经验：AI 是效率引擎，但你要有基本盘
把整个移植过程压缩一下，实际耗时大概是：资源检查和处理 40 分钟，API 兼容性修改 30 分钟，对象池和代码优化 30 分钟，构建加调 IDBFS 和内存问题 40 分钟，部署和加载界面 20 分钟。加起来确实在两个小时左右，但要注意，我一开始就明确知道这个项目不需要做复杂适配，目标就是 PC 端浏览器能跑起来，所以砍掉了很多潜在的增强需求。如果你的项目里用到了复杂的 Shader、物理系统、网络通信、或者自定义的渲染管线，两个小时是绝对不够的，可能得按天来算。
这次让我印象最深的一点是，AI 不是帮你写代码的机器，而是帮你把大量重复性、琐碎但必需的工作压缩掉的工具。比如批量修改资源压缩格式、写对象池模板代码、排查内存泄漏可能点、生成编辑器检查脚本，这些活的共性就是：逻辑不复杂，但量大、重复、需要细心。AI 非常擅长这种类型的任务，因为它不会累，也不会因为改了第 100 个文件而忽略第 99 个文件。但对于那些需要理解项目整体架构、判断取舍和权衡的地方，比如要不要保留某个功能、资源压缩到多少才合适、要不要为移动端重新设计 UI，AI 目前给不了有价值的建议，这些还得靠你作为开发者自己的理解。所以如果你现在正打算把手头的老 Unity 项目搬上 WebGL，我的建议是：先把项目完整跑一遍，把构建错误和警告整理出来，然后带着具体的问题去问 AI，它给你的答案会非常精准。如果你只是扔给它一个大型项目和一句“帮我优化”，它大概率会给你一堆泛泛而谈的东西，根本没法直接落地。
最后再分享一个我自己的小习惯：在做这种迁移任务时，我会每完成一个阶段就在 Git 里打一个 tag。比如resource-compressed、webgl-compatible、object-pool-done、first-successful-build。这样做的好处是，因为 WebGL 的构建时间长、修改频繁，过程中很容易出现改了 A 处却把 B 处弄坏了的情况。有 Git tag 就能随时回到某个确定可用的版本，不至于一个晚上卡在某个奇怪的 bug 里出不来。这次迁移如果没有这个习惯，我估计要再多花半个小时在反复试错上。如果你也打算开始类似的工作，强烈建议你也这么干。
