2018年我毕业设计做的是个Unity版的塔防小游戏玩法参考保卫萝卜美术资源网上扒的代码全是当时刚学C#时写出来的野路子。最近翻出来想给朋友演示一下结果发现电脑上装的Unity版本和当年那个2018版本差了好几个大版本项目一打开全是报错。本来想放弃了后来试了试让AI帮我迁移到WebGL前后花了两个小时还真跑起来了而且直接在浏览器里就能玩。整个过程踩了不少坑也有些AI生成代码后需要人工兜底的地方今天就完整记录下来。1. 迁移前的现状评估为什么这活儿非干不可先说说这个项目的具体情况。2018年那个版本用的是Unity 2018.4.7f1项目结构特别原始所有脚本挂在GameObject上没有用任何框架存档用的PlayerPrefs场景切换用的SceneManagerUI用的旧版UGUI。游戏核心逻辑分三块敌人寻路、炮塔攻击、资源管理大概三十来个脚本总计五六千行代码。这游戏在桌面端跑是一点问题没有但放到WebGL上有几个绕不开的坎。首先是插件依赖项目里用了一个Forge Networking的多人联网库这在浏览器环境下根本没法跑。其次是文件读取原来用了System.IO命名空间读写本地存档WebGL里这套API完全不存在。再有就是资源加载资源全在StreamingAssets里浏览器环境下路径全都变了。我开始的时候想过直接手动迁移但估算了一下工作量光是把那些System.IO相关的代码改成PlayerPrefs就得花不少时间再加上WebGL构建工具链的配置、内存管理、资源压缩这些事没有一两天搞不完。所以决定换个思路让AI先做一次整体迁移我负责审核代码和解决AI搞不定的部分最后再统一做浏览器端测试。在动手之前有几个前置条件得确认清楚。一是Unity版本需要升级到2021 LTS或者2022 LTS因为新版本的WebGL支持更好尤其是对WebAssembly的优化和内存分配策略都成熟得多。二是项目里所有第三方插件要么删掉要么找到WebGL兼容的替代方案。三是美术资源需要做一次体积审查因为WebGL对初始加载包大小很敏感用户不会愿意等一个500MB的游戏加载完毕。做完这三个评估我心里基本有数了开始正式动手。2. 用AI做迁移的整体路径从清理项目到跑通首包这个环节是整个迁移的核心也是花时间最多的地方。我给的提示词框架大概是这样的先把项目背景和Unity版本信息告诉AI再把每个出错的脚本逐个贴给它要求它给出两个版本——保持原逻辑的升级版和WebGL适配版。这么做的好处是AI能对照原逻辑帮你核对有没有改错你自己也清楚改动范围。第一步是清理项目。我让AI识别出项目里依赖System.IO、System.Net.Sockets这些在WebGL环境下不可用的命名空间的代码统一列成清单。这一步其实挺关键的因为很多问题不是报错才发现的而是代码能编译但一运行就静默失败排查起来费时费力。AI给出的清单里跟文件操作相关的有存档系统、日志系统、加载关卡配置的解析器总共六处。第二步是处理存档系统。原来的实现是先把数据序列化成JSON然后通过File.WriteAllText写入Application.persistentDataPath目录下。AI改成了两种方案让我选一种是直接塞进PlayerPrefs简单粗暴但字符串长度高了他不稳定另一种是用IndexedDB存Unity WebGL提供了IDBFS这个文件系统挂载方案可以模拟出真实文件系统的读写效果。我选了后者因为考虑到存档里除了游戏进度还有一些用户自定义的关卡编辑数据长度不确定PlayerPrefs不靠谱。第三步是处理输入系统。我那个项目用的是旧版的Input Manager鼠标移动、点击、键盘快捷键全走的一套。AI在迁移的时候提醒我WebGL下旧版Input Manager虽然能用但部分键位映射在不同浏览器下行为不太一致建议统一升级到新的Input System。这一步其实是额外的重构工作我一开始觉得没必要但实测后发现旧版Input在Chrome下是正常的到了Firefox里鼠标坐标偶尔会偏移几个像素这个bug不好定位升到新Input System之后问题直接消失了。第四步是处理场景切换。原来用的SceneManager.LoadSceneWebGL下能用但会有一个明显的加载白屏期。AI建议改成场景内物件全部动态加载把游戏的核心玩法部分拆成独立prefab通过Addressables按需加载。这个改造量偏大我权衡了一下游戏本来就只有三个场景主菜单、关卡选择、游戏主场景切换频率不高就直接保留SceneManager了没做过度设计。第五步是构建参数配置。这个必须手动调AI帮不上太多忙。我填的参数大概是这样目标平台WebGL压缩格式Brotli开启增量构建缓存关闭异常处理减少包体开启Stripping Level设为Low避免把反射相关的代码剪掉。这几项里最关键的是Brotli压缩它能把包体积压掉接近一半但代价是IIS服务器得配好Brotli响应头不然下载效率反而更差。全部改完之后跑了一次构建第一次构建很顺利没有任何报错。包体大小从桌面的180MB压缩到了65MB首次加载时间在千兆局域网环境下大概十秒出头。但真正在浏览器里跑起来之后问题才开始冒头。3. 踩坑实录WebGL模式下那些让人抓狂的兼容性问题3.1 IDBFS写入失败引发的存档问题这个坑说实话是意料之中的。跑通首包之后我先点了一把游戏能正常移动炮塔、打怪但一退出重进所有进度全没了。打开浏览器控制台一看IDBFS的写入报错挂了一串。排查的思路是这样的先去Unity的官方文档里翻IDBFS的推荐用法。官方说得很清楚需要主动调用两个接口——FS.mount挂在IndexedDB上以及FS.syncfs做数据同步。光调用File.WriteAllText是不够的因为那只是写入了Unity内部的内存文件系统浏览器根本不知道你要把数据持久化到本地。AI在迁移的时候其实已经生成了挂载和同步的代码但同步的时机写错了。它放在Application.OnApplicationQuit里这个生命周期方法在WebGL环境下调用时机极其不可靠浏览器标签页一关就直接跳过数据根本没来得及落盘。修法是把同步时机改成每次写档完成之后立即执行同时在页面visibilitychange事件里也绑一次同步作为兜底。我让AI改完这块之后反复测了几遍开游戏、退出、刷新页面、关标签页数据都能正常恢复这个问题才算彻底解决。还有一个细节值得说IndexedDB的容量上限取决于浏览器实现Chrome一般给的是磁盘可用空间的60%看起来很多但如果游戏运行时间长了存档越写越大还是得做好旧存档的清理策略。我在存档JSON里加了一个版本号和日期字段每次写入新档之前先删除超过七天的旧档文件这样不至于让本地存储无限膨胀。3.2 中文字体和动态字体的两个大坑2018年的项目里我用了两个中文字体一个是UI用的默认字体一个是数字显示的像素风格字体。WebGL构建之后中文字体直接不显示了界面上全是方块和问号。原因是这类字体文件用的是动态字体模式——Unity会根据实际使用到的字符动态生成图集好处是包体小坏处是如果字符没有被提前加载在浏览器环境下就会因为资源加载顺序问题导致字体渲染失败。桌面上无所谓因为系统级字体能兜底浏览器里没有对应的系统字体就只能显示方框。解法有两个方向。一是把动态字体换成静态字体在字体导入设置里把字符集从Dynamic改成Unicode这样所有字符都会打进图集里缺点是包体增大如果游戏文本量大图集会非常占内存。二是自己维护一个字符集文件只把你用到的几百个常用字丢进去这样包体增量可接受还保证了显示效果。我用的后者因为游戏本质上就是个塔防UI文本翻来覆去其实就那几十个词。数字字体那个坑更隐蔽。像素字体是TTF格式导入Unity后默认采样率是100这个在桌面端看着没问题。但WebGL的字体光栅化机制和桌面不太一样渲染出来笔画会偏细数字变得模糊。后来在字体导入设置里把采样率调到200才解决。3.3 文件路径大小写和URL编码的地狱项目里加载关卡配置用的路径是StreamingAssets/levels/level1.jsonWindows上文件系统大小写不敏感写成LEVEL1.JSON也能读出来。但WebGL本质上是跑在浏览器里的静态资源走的是HTTP请求服务器在Linux上大小写敏感404一度是常态。我排查这个问题的时候花了很长时间因为本地跑Unity编辑器一切正常构建出来也能加载但一部署到服务器就报路径错误。后来在Network面板里看到实际请求的URL跟文件名对不上全给转成了大写才知道是代码里某处字符串处理给路径做了大写转换。这种问题的排查链路其实可以通用化先在本地架一个HTTP服务器然后把Network面板打开逐一核对请求的URL和实际文件的相对路径是否一致。能用绝对URL的尽量用绝对URL别用拼字符串的方式来组合路径尤其是文件名来自用户输入或者配置表的时候大小写坑防不胜防。3.4 Object.Instantiate的异步陷阱这个坑是AI代码里最让我头疼的一个。AI为了优化性能把一部分敌人的生成逻辑改成了异步——每次生成一个敌人先await一下防止同帧生成太多导致卡顿。这个设计本身没问题但AI直接用了一个简单的await Task.Delay()来实现这放在桌面上没问题但WebGL的浏览器环境下Unity的异步操作和浏览器事件循环之间的时序关系有时候会错乱。症状是敌人明明已经走到终点炮塔却没有反应过一秒又突然开始攻击整个游戏节奏忽快忽慢。我把AI生成的异步逻辑全看了一遍发现这种无脑加延迟的地方不止一处。修法是统一改成协程加WaitForSeconds让Unity自己控制帧率节奏而不是交给浏览器的定时器去调度。这里说一个经验在WebGL模式下尽量别依赖系统层面的异步APIUnity自己的协程和UniTask是对接引擎帧循环的时序上可靠得多。AI在生成代码的时候容易忽略这个运行环境的差异所以人工审核这一步绝对不能省。3.5 内存管理和纹理压缩的平衡WebGL和桌面端的最大不同是内存上限桌面动不动16GB、32GB浏览器里单个Tab能干到的内存在2GB左右已经算多了。老项目的纹理加载策略是懒加载缓存但缓存的清理时机写得很粗糙——准确说根本没清理过。玩到后面资源全都堆积在内存里浏览器直接崩溃白屏。AI帮我把所有纹理的加载入口都打了个标记然后加了一个引用计数系统强引用和弱引用的关系理清之后不用了就马上释放。这个改动本身不复杂但要改的地方很碎AI在处理这种机械性重构的时候效率确实比我手撸高得多。纹理压缩格式选了ASTC这是移动端和WebGL通用性最好的格式支持透明通道压缩比也可控。如果浏览器不支持ASTC会回退到ETC2或者RGBA32但Chrome和Edge现在都原生支持ASTCFirefox也跟上了基本不用担心兼容性。性能测试的时候我盯着任务管理器看整体内存占用稳定在1.2GB左右算是在安全线以内。4. 性能调优和浏览器差异适配从能跑到流畅的最后一公里搬进浏览器只是第一步真正让人满意的流畅体验还需要调整几个关键参数。先说帧率。我的游戏逻辑里每一帧都要扫描一遍场上所有敌人和炮塔的交互这个O(n²)操作在敌人数量达到七十个以上的时候每帧耗时直接翻倍。AI给了一个优化思路把敌人按照网格分区炮塔只检测自己所在网格和相邻网格的敌人这样一个炮塔每帧要检查的目标数量从全场几十个降到了个位数。这个优化做完帧率在Chrome里从45fps拉到了59fps接近垂直同步的满帧。然后是画质分级。WebGL玩家用的设备千奇百怪不能默认高画质。我在启动画面加了一个简易画质选择页低中高三档分别对应不同的渲染分辨率和后处理开关。低画质关掉抗锯齿和环境光遮蔽分辨率降到75%中画质保持抗锯齿关掉环境光遮蔽高画质全开。实测下来核显笔记本选低画质能稳30fps独显主机直接拉满高画质能到60fps。浏览器差异这块最典型的问题出在Firefox和Safari上。Firefox对WebAssembly的编译优化策略和Chrome不一样首包加载完成后代码模块的实例化时间多了一倍左右导致黑屏时间更长。这个不是代码能解决的问题只能在加载页面做个假的进度条动画让用户不至于以为页面卡死了。Safari的坑更多——对IndexedDB的支持不一致偶发性的音频延迟以及mbtr压缩字体在某些版本下不渲染这个问题目前无解我直接把Safari从推荐浏览器里划掉了弹窗提示建议用Chrome或Edge访问。音频这块也值得一提。老项目里的音频文件是MP3格式WebGL可以播放但多个音频同时播放的时候延迟非常明显点一次炮塔攻击音效往往要慢个一百多毫秒才响。换成WAV格式后延迟问题解决了代价是体积翻了好几倍。后来AI帮我做了个音频压缩方案短音效攻击、升级、UI点击切成WAV存内存播放长背景音乐保留MP3做流式加载两边的好处都占了。5. 最终的验证结果和几个可以复用的经验部署完之后我做了完整的回归测试。游戏本体的核心玩法——敌人寻路、炮塔攻击、建造升级、金币资源——全部正常中文字体显示无方块存档刷新页面和关闭浏览器后都能恢复帧率在Chrome和Edge稳定在55fps以上Firefox稍低但也过了45fps这条体验线。整个迁移过程从开始到能玩用了大约一个半小时的AI生成和修改加上半个多小时的性能调优正好两个小时出头。AI在这个过程中帮我省掉的机械劳动时间估计有三个小时以上如果不是项目结构太老这个时间还能再压缩。有几个经验想直接分享给有类似需求的同学。第一千万别让AI一次性改完所有脚本分模块推进、每个模块单独跑通再合入出了问题好定位。第二WebGL构建好之后一定要到实际浏览器里测别在Unity编辑器里测完就以为没问题两个环境的差异比你想象的大得多。第三把浏览器控制台当成你的队友大部分问题都会在那里暴雷看到红色报错别慌按前缀分类去查语法报错、加载失败、运行时异常三类问题的解法完全不同。第四存档逻辑这块方案越简单越不容易出问题如果你只是存个游戏进度PlayerPrefs其实完全够了我之所以用IDBFS是为了自定义关卡编辑器功能复杂才需要那个方案。我个人的体会是AI在WebGL迁移这个场景下最大的价值不是替你做决定而是把你脑子里已经想清楚但懒得动手实现的事情快速落地。真正的决策还是得你自己来用什么方案存数据、要不要升级输入系统、字体怎么压缩、内存怎么管理这些关键分岔路AI给不了标准答案全靠你对项目本身的理解和取舍。反过来一旦这些决策定了AI的执行力确实比我手写代码快得多尤其是那种这个模块有三十处System.IO的调用统一帮你改成IDBFS挂载的重复活儿人干起来容易漏AI干起来又快又齐。如果后续有时间我想把AI辅助迁移的过程再优化一下把那套提示词框架做成一个半自动化的清单流程这样以后再遇到老项目想搬上浏览器至少不用从零开始摸索了。也希望这篇记录能给正在做Unity老项目翻新的朋友带来一些参考。