开头就不另起标题了，咖啡还没来得及凉，项目已经从Unity工程变成浏览器里能直接跑的一关塔防。我说的就是这个事：2018年写的一个Unity版“保卫萝卜”Demo，三个月前还躺在硬盘里连工程文件都快忘了，这次周末抽了两个小时，把核心流程（选塔、铺塔、出怪、打怪、收金币）完整搬到了WebGL上，顺手把存档、全屏、移动端适配也收拾干净了。
整个过程我没手写超过五十行新代码，大部分改动用的是AI辅助——先让它读脚本、分析报错、给我补WebGL兼容层的胶水代码，我再对着运行效果做取舍。今天把这套流程完整复盘出来，不吹效率，重点说清楚：哪些步骤AI是真能省时间的，哪些步骤你交给AI就是给自己挖坑，以及Unity 2018这种老工程迁移到WebGL时躲不开的几道坎到底怎么迈过去。如果你手头也有一个几年前的Unity小游戏想搬到浏览器里复用，这篇文章可以直接当操作流程参考。
1. 动手前先盘家底：2018年的Unity项目要搬什么
1.1 先搞清楚这个项目是用什么版本、哪些库写的
别一上来就切WebGL平台点构建，第一件事是把工程在Unity里打开，看一眼版本。我那个项目当初用的是Unity 2018.4.36f1，这个版本恰好是2018系列最后一个LTS，API相对稳定，但和如今的Unity 6在渲染管线、包管理器、序列化格式上差别不小。如果你的项目比这还老，比如2017、2016，那第一步不是迁WebGL，而是先考虑是否值得升级到现代版本。我的建议是：如果项目不复杂，保留老版本直接发布WebGL反而省事；如果用了很多第三方插件，升级成本远比迁移高，那就要掂量一下了。
看完版本之后，第二步是盘脚本与依赖。打开Project窗口，把Assets目录过一遍，重点找三类东西：
- 脚本引用了System.IO、System.Net、System.Threading等桌面API，这些在WebGL下基本都不支持或需要特殊处理；
- 用到了MonoBehaviour生命周期之外的东西，比如多线程、Socket通信、反射，WebGL环境是单线程沙箱，限制很多；
- 第三方插件，比如A*寻路、DOTween、NGUI或旧版UI插件，有些在WebGL下开箱即用，有些需要改设置。
我这个项目里最典型的问题是存档代码用了File.WriteAllText和Directory.CreateDirectory，桌面Windows上跑得飞起，但WebGL的沙箱系统压根不给你直接访问文件系统，后面折腾IDBFS的时候我会细讲。
另外一个容易被忽略的点：Unity 2018之后，WebGL构建默认使用的是IL2CPP后端，你那些用C#写的脚本会先编译成C++，再交叉编译成WebAssembly，和编辑器里用Mono跑是两套完全不同的运行时。所以编辑器里没报错不代表WebGL构建能过，老项目尤其如此。
1.2 WebGL和桌面构建的底层差异
很多人以为WebGL就是把Unity游戏“导出”成网页版，点一下Build就完事。真不是这样。从技术底层看，Unity WebGL把游戏打包成了一个带Unity引擎运行时的WebAssembly模块，外加一个HTML加载器和一堆资源文件。游戏逻辑通过IL2CPP被转换成C++再编译成wasm，所以之前C#里那些反射、动态代码生成、P/Invoke操作会变得非常脆弱，甚至直接崩掉。
同一套代码放到WebGL里，最大的差异在四个方面：一是IO。桌面端可以读写任意路径，WebGL只能靠PlayerPrefs或IndexedDB；二是网络。如果你用WWW或UnityWebRequest加载远程资源，WebGL必须遵守浏览器同源策略，跨域得配CORS头；三是多线程。WebGL早期版本不支持托管线程，现在虽然可以通过Web Worker模拟，但Unity的很多API在WebGL下依然默认主线程执行，你在Update里开个Thread做寻路，桌面没问题，WebGL直接给你异常；四是内存。Unity WebGL把所有运行时内存限制在一段连续缓冲区里，默认上限通常是2GB，但实际因浏览器、设备而异，分配失败就直接白屏崩溃。
这也就解释了为什么很多老项目第一次构建出来能打开菜单，但一进游戏加载关卡就嘎嘣弹错或者慢得离谱。资源加载方式、内存占用、IO策略，这些都是桌面平台不敏感但在WebGL下会被无限放大的问题。
1.3 迁移难度评估的三个关键信号
在动手改代码之前，我建议你花二十分钟做一次“难度体检”，只盯三个信号就能判断这个项目两小时能不能迁完：
第一个信号是读写本地文件的频率。如果游戏只在开局存一次档、读一次配置，那问题不大，换成PlayerPrefs就行；如果是那种每回合自动写日志、离线收益要频繁写盘的设计，迁移成本会几何级上升。
第二个信号是依赖第三方SDK的程度。你的项目里有没有用微信SDK、实时语音、原生支付之类的插件？这些在WebGL下统统不可用，除非自己再实现一套HTTP对接方案，工作量不是两小时能搞定的。
第三个信号是资源体量和纹理格式。几百MB的AssetBundle，几千张大尺寸纹理，这种项目就算AI再能改代码，加载时间和内存也扛不住。塔防游戏好就好在资源量小、逻辑围绕预制体和脚本展开，天然适合WebGL。
我当时评估后觉得可行，主动砍掉的功能是：动态加载的远程关卡包、本地截图分享功能、还有基于System.Drawing的缩略图生成（这个在WebGL下更是天方夜谭）。砍完核心流程干净了很多，这也是两小时能做完的前提。迁移WebGL不是复制，是做减法加适配。
2. AI在这场移植里到底能干什么：别把大模型当神，当实习生用
2.1 让AI先“读一遍”整个项目的正确姿势
最早我也犯过傻，把整个Assets文件夹拖进AI输入框，让它“帮我移植”。结果平台直接拒绝，就算能接受，几千行脚本混在一起也没法用。后面摸索出来的正确姿势是：先手动做一次结构梳理，再分模块丢给AI。
具体操作是，我先在本地打开工程，按照功能目录列一个清单，比如“Scripts/Audio/、Scripts/UI/、Scripts/Tower/、Scripts/Enemy/”，然后挑出核心脚本，按依赖顺序发给AI。发给AI时不要只粘贴代码，要给它上下文，我写的是类似下面这样的提示：
“这是一个Unity 2018.4的塔防游戏项目。Scripts/Tower/Turret.cs控制炮塔的锁定目标、旋转和发射，子弹由Bullet.cs负责移动和伤害。现在要把项目迁移到WebGL，请重点检查以下代码在Unity WebGL平台下可持续运行吗？有没有非兼容API？需要替换的话，给出最小改动方案。”
AI在这种带明确上下文的提问下，给的回答准确率高很多。它会直接指出Application.dataPath不能用于写入持久化数据、WWW已经被淘汰换成UnityWebRequest，这些虽然我都知道，但省下的搜索时间是真的。
还有一点体验很好：AI能做“批量静态替换”。比如一个工程里几十处用了File.WriteAllText存储存档，我让AI写一个带方法签名一致的FileSafe类，内部自动判断平台，WebGL下走PlayerPrefs，桌面下走原文件逻辑。这个类AI几十秒就生成了，我自己写少说也要十分钟，还得调试。AI适合干这种体力活，不适合干判断题。
2.2 AI能改代码，但哪些事千万别指望它
AI帮你改C#脚本、生成配置、解释编译报错，这些都很靠谱。但有几件事你千万别交给AI，否则会被带到坑里：
第一，它看不见你的资源导入设置。比如你的Sprite图集、动画状态机、预制体绑定关系，AI在纯代码层面是完全看不出来的。它给你分析“模型不在场景中”，其实只是某个预制体的Mesh引用丢了，这个问题AI永远发现不了，只有打开Unity场景看着Inspector才能定位。
第二，它不知道WebGL构建目录下的服务器配置。很多问题其实不在代码，而在于你托管构建产物的服务器没配.unityweb文件的MIME类型，或者没有gzip压缩。AI给你的代码修复方案纯属多余，你得自己去检查IIS、Nginx或某个静态托管平台的MIME映射关系。
第三，它缺乏“浏览器黑盒”的感知能力。WebGL白屏、页面无响应、内存溢出这些，往往和C#代码沾不上边，可能是浏览器版本、显卡驱动、WebGL Context丢失等原因。AI只能干瞪眼，你必须手动打开DevTools看Console和控制台网络请求。
所以我的原则是：AI处理“文本层面的问题”，我处理“运行现场的问题”。凡是能在代码里搜索、替换、比较的，丢给AI；凡是改完代码还要开浏览器验证逻辑的，自己来。
2.3 一套能复用的AI提示词模板
给AI下需求，也有固定套路。我用的模板基本是三段式：
- 项目背景一句话。比如“Unity 2018 WebGL项目，塔防游戏”；
- 当前目标和报错信息。比如“发布后打开页面空白，Console报Unable to load file from file://协议”；
- 约束条件。比如“保持现有场景结构不变，最小改动，不要重写整个系统”。
举个例子，我处理存档问题时是这样提问的：
“Unity 2018 WebGL项目，游戏中用System.IO.File.WriteAllText把存档写到Application.persistentDataPath下。发布WebGL后运行时提示无权限写入，希望改成在WebGL下使用PlayerPrefs来存储存档，但保留在Windows编辑器下继续用文件存储的能力。请生成一个跨平台存档工具类，并给出调用替换说明。”
AI不到一分钟就生成了一个带#if UNITY_WEBGL和#elif UNITY_EDITOR条件编译的工具类，我粘贴进工程改了几个方法名，存档就通了。如果你连这个提示词都不知道怎么写，效果就会差很多，AI不知道前因后果，就会给你一版天花乱坠但其实不满足约束的代码。
3. 两个小时的实操流水账：从本地工程到浏览器可玩
3.1 第30分钟：构建前清理与平台切换
我切到Build Settings，点Platform列表里的WebGL，然后等Unity弹出一个“Switch Platform”提示。这一步会把当前平台从Windows/Mac切到WebGL，需要重新导入所有资源，时间一般3到10分钟。老项目资源多，这一步慢是正常的。
平台切换完成后，先别急着Build。我先做了三件事：
第一，关闭不必要的编辑器模块。Project Settings里的Player Settings，把Scripting Runtime Version设为.NET 4.x Equivalent（Unity 2018里可选），Api Compatibility Level如果项目没有特殊需求就选.NET Standard 2.0，兼容性更稳。
第二，设置压缩格式。WebGL发布时有很多压缩选项，我选了Brotli，需要在托管服务器上配置对应的Content-Encoding，否则浏览器解不开。如果服务器配置不方便，可以用Disabled或者Gzip，但Build文件会大不少。
第三，检查Code Stripping。我起初勾了Managed Stripping Level为Aggressive，结果部分反射代码被打包时给剔除了，运行时报MissingMethodException。后面改成Medium才稳定，这个建议后面再调，前期别激进。
做完这些，我第一次Build用的是最低画质、关闭阴影、关闭抗锯齿。不要一上来就高画质，先把管道跑通，后面再逐项开回来。
3.2 第60分钟：第一版WebGL构建和最典型的三个编译错误
第一次构建大概花了四分钟，构建出来的是一个包含index.html、Build\xxx.data.unityweb、xxx.wasm.unityweb、xxx.framework.js的目录。我启动本地静态服务器试跑，几乎立刻看到三个错误，这算是Unity 2018项目转WebGL的标准三连：
第一个是Protocol Error或404。这是因为本地服务器没有给.unityweb后缀的文件设置正确的MIME类型，Nginx默认当成application/octet-stream返回，Unity加载器不认识。解决方式是在Nginx配置里加一行：application/octet-stream unityweb;，并顺带开启gzip。如果你用的是python -m http.server，很多版本会自动处理，但以后放到任何新服务器都别忘了这一茬。
第二个是WebGL 1.0不支持某Shader特性。我这个塔防的敌人用了半透明材质，标准Shader在WebGL 1.0下有些Pass不兼容，表现为敌人变成紫色或者崩溃。解决办法是改成移动端Shader变体，要么升级项目的手写Shader，要么直接在Quality Settings里关掉实时阴影和HDR。这个时代Unity WebGL虽然也支持WebGL 2.0，但2018版本默认特性集偏保守，在浏览器里就别追求桌面级效果了。
第三个是AudioSource播放无声或循环错乱。WebGL的音频系统不是完全实时流式，有些格式（比如Vorbis之外的WAV）在不同浏览器表现不一致。Unity 2018发布WebGL时建议所有音频用MP3或OGG，并关闭预加载以外的流式播放选项，否则可能发生播放延迟甚至不出声。我把背景音乐转成OGG，音效转成MP3，重新导入后恢复。
3.3 第90分钟：IDBFS存档失败、布局错乱的现场处理
第一版构建能跑起来之后，我点“开始游戏”，塔防第一波怪能出、塔能攻击，但退出游戏再进，存档没了。Unity编辑器下存档正常的代码到了WebGL里注销了，控制台报错是类似写入IndexedDB失败或者权限不足。
这就回到1.1里说的File.WriteAllText问题。WebGL运行时并没有传统文件系统，Unity将FileAPI映射到内存文件系统，只要页面一刷新，数据全部归零。要想持久化，你需要把文件系统挂载到IndexedDB上，或者干脆用PlayerPrefs这种引擎级封装。我对这个项目采取的是后者——存档体量也就几十KB，用PlayerPrefs存JSON字符串完全够用。AI帮我生成的条件编译工具类在这个环节发挥了全部价值。
layout错乱的现场是另一种风格：桌面分辨率下UI正常，切到手机窄屏后，左上角的金币标签和右上角的波次标签叠在一起。原因很直白，2018年的UI用了绝对坐标，没有做自适应布局。这部分AI没法看场景，我手动改Canvas Scaler的模式为Scale With Screen Size，再把关键UI节点的锚点从固定角落改成拉伸对齐，花了一些时间。
3.4 第120分钟：性能优化与收尾
流程通了以后，剩下的时间全部用来做性能优化。塔防游戏最怕的是怪一多就掉帧。我做了四件事：
第一是对象池化子弹和敌人。2018年源码里敌人死亡会Instantiate一遍爆炸特效，再多造出几十个敌人时新建GameObject的开销会被放大。我导了一个简单对象池类，把子弹、敌人的生成和回收统一接管。AI帮我改写了调用点，这一步大约二十分钟。
第二是关掉不需要的光照和阴影。WebGL下实时阴影是最耗性能的Feature之一，我把Quality Settings的Shadows全关，光影全用不透明贴图和顶点色模拟，帧率立刻提升一截。塔防这种俯视视角游戏，其实根本不需要动态阴影。
第三是图集化UI与Sprite。把散落的小图标打成图集，减少DrawCall，同时在不需要交互的Image上关闭Raycast Target，减少事件检测开销。
第四是设置WebGL内存上限。Unity 2018在Player Settings里可以直接设置WebGL Memory Size，我给这个项目设了256MB。太大很容易让低端设备崩溃，设置得当可以提前规避“内存增长到极限后页面白屏”的问题。
最终版本在Chrome和Edge里都能流程稳定，SteamDeck的浏览器模式我也顺手测了，除了加载慢一点，游戏内帧率稳定在55到60之间。
4. 浏览器里跑塔防的三道坎：存档、性能、交互细节
4.1 存档不是PlayerPrefs那么简单（IDBFS系列问题）
很多新手以为用了PlayerPrefs就万事大吉，其实在WebGL下PlayerPrefs底层仍然走的是IndexedDB。正常情况下，Unity会封装好读写，你调用PlayerPrefs.SetString和PlayerPrefs.Save之后，数据会被异步写进浏览器的IndexedDB。但有几个场景特别容易踩坑：
第一个是浏览器的隐私模式。隐私模式下IndexedDB可能是可写但隔离的，一旦关闭隐私窗口数据就清空，游客会觉得“存档我明明保存了，为什么第二天没了”，这个没法从代码层面完全规避，顶多在UI里加一个“当前为无痕模式，关闭浏览器后存档丢失”的提示。
第二个是跨域隔离与第三方Cookie策略。如果Unity跑到iframe里，一些浏览器默认禁用第三方存储，PlayerPrefs写入会静默失败。这时你要么让接入方设置allow="storage-access"之类的策略，要么提示用户必须在顶层窗口打开游戏。
第三个是玩家主动清浏览器数据。这个谁也拦不住。如果你的塔防游戏有付费道具或账号体系，就不要把唯一存档放在本地浏览器，必须走后端同步。我这次只是Demo，所以本地存档就够了，但如果是正式项目，至少要把存档字符串做成可导出、可导入的文本，让玩家自己备份，能少很多售后问题。
4.2 WebGL性能优化：从对象池到DrawCall
如果说桌面游戏的性能瓶颈往往在GPU，那WebGL游戏先卡死的往往是CPU和内存，因为主线程要同时承担游戏逻辑和浏览器事件处理。塔防场景下，怪多、子弹多、UI刷新频繁，最容易形成三个瓶颈：GC分配、DrawCall、内存峰值。
GC分配的优化方式是减少每帧的临时对象分配。比如不要在Update里用字符串拼接，不要频繁创建List，需要用到的容器提前复用。2018年的代码里有一个每帧统计金币加成的string.Format，修改之后用StringBuilder缓存，帧率在低端手机上提升了肉眼可见。
DrawCall的优化方式前面提过图集和静态合批，这里补充一句：要时刻关注Frame Debugger。Unity的Window > Analysis > Frame Debugger可以看到每一帧的DrawCall是怎么提交的，哪些资源没法合批一目了然。我检查后发现自己场景里最大的合批破坏者竟然是血条UI上的多个不同字体Texture，统一字体和Graphic后再渲染一遍，批次数从一百多降到了五十左右。
内存峰值的问题则是老工程最深的坑。如果你的项目有一些不必要的场景预加载资源，请把它们从Resources文件夹移除，改成AssetBundle或Addressables按需加载。WebGL构建的文件虽小，但运行时展开到内存可能膨胀好几倍。尤其塔防后面会有整波敌人预制体、多关卡的地图数据，一次性全加载完，中低端设备直接白屏。
4.3 那些看起来很小却要命的交互细节
界面能跑、性能也稳定，不代表用户会觉得“好用”。WebGL项目最容易被吐槽的往往是这些边角：
第一是鼠标滚轮缩放和右键菜单。默认情况下Unity WebGL会把鼠标事件捕获到Canvas上，但浏览器仍然可能弹出右键菜单。我在启动时加了一个oncontextmenu事件拦截，同时给滚轮缩放设了上下限，防止玩家把摄像机拉到地图外面导致穿过背景。
第二是按钮的点击范围。如果你在代码里用OnGUI或者EventSystem，UI元素的alpha为0的可点击区域经常被误伤。我之前在Unity里做了一个隐藏的“全屏下一波”按钮，结果按钮的透明区域盖住了半屏，AI是看不出这种物理体量的，全靠手动在Scene里查射线检测。建议遇到交互异常时，打开Scene窗口，临时显示全部UI事件区域，先看看有没有透明遮罩挡路。
第三是自动聚焦与键盘输入。WebGL游戏如果嵌在页面里，有时第一次点击后按钮才响应，这是因为Canvas还没获得键盘焦点。解决办法是页面加载完成后，通过外部JS调用Unity的focus()方法，或者把Unity实例的canvas.tabIndex设为0。我自己把这个逻辑写进了HTML加载完成后的一段脚本里，从根上解决了“点第一次没反应”的问题。
5. 常见问题速查表：遇到直接抄作业
| 现象 | 根本原因 | 解决思路 |
|---|---|---|
| 构建产物用file://打开白屏，Console报跨域或加载失败 | 浏览器禁止本地文件跨域读取WebAssembly | 用本地HTTP服务器托管目录访问，比如python -m http.server 8080 |
.unityweb文件404或加载中止 | 服务器没配置对应的MIME或压缩头 | Nginx加application/octet-stream unityweb;，并开启gzip/brotli |
| 游戏运行正常但退出后存档丢失 | 使用了内存文件系统或PlayerPrefs被清 | WebGL下不要用File.WriteAllText，改用PlayerPrefs，若数据量大用IndexedDB封装 |
| 进入战斗后帧率暴跌 | 实例化频繁、无对象池、DrawCall过多 | 引入对象池，图集化，关阴影，用Frame Debugger查合批 |
| 高内存占用导致页面崩溃 | TOTAL_MEMORY设置过大或资源预加载过多 | Player Settings里调低WebGL Memory Size，关掉不需要的场景预加载 |
| 模型显示为紫色/材质丢失 | Shader不兼容WebGL | 换移动端Shader变体，或减少高级渲染特性 |
| 鼠标点击第一次没反应 | Canvas缺少键盘/鼠标焦点 | 在HTML加载后调用实例focus，设置tabIndex |
| 无法播放音频或延迟明显 | 音频压缩格式不兼容 | 将音频转成OGG/MP3，避免WAV直出 |
| 浏览器窗口缩放后UI错乱 | 没有设置Canvas Scaler | Canvas Scaler切为Scale With Screen Size，锚点拉好 |
提示缺少gameassembly.dll或类似运行时错误 | WebGL没有DLL，加载器未解析成功 | 确认构建产物完整，不要修改文件名，检查服务器是否支持压缩编码 |
这张表可以说是Unity 2018老项目搬WebGL时问题密度最高的十个现场。实际过程中，还有更细碎的问题，比如Shader编译耗时导致首帧卡顿、白屏期间没有loading状态、Resource加载过多阻塞主线程，这些也不是代码层面能一次性解决的。我的经验是：先保证主流程三分钟能跑通，再把体验细节按影响面排序逐个磨。
6. 一些按项目性质区分的补充建议
如果你做的不是塔防，而是卡牌、模拟经营、休闲三消，这套流程同样适用。差别只在于资源管理的重心和UI交互的复杂度。
卡牌游戏的核心资源是图鉴数据和卡牌图片，迁移WebGL时重点检查动态加载和卡牌图集，建议把卡牌数据从ScriptableObject改成JSON外部加载，方便后续做热更和换皮。模拟经营类的存档通常比塔防大得多，动不动几百KB上MB的玩家数据，用PlayerPrefs存JSON就不是好主意了，这时候应该自己在IndexedDB里建表，或者对接后端云存档。三消类主要看粒子特效和动画性能，WebGL下的Animator在多对象同步播放时依然很吃力，尽量换成GPU粒子或者序列帧动画。
另一个方向是把WebGL当作测试脚手架。有些人问，为什么不直接用Unity编辑器做测试，非要发布WebGL？我的看法是：WebGL构建能暴露很多桌面端注意不到的架构问题——IO依赖、跨域、资源体积、弱鸡性能设备上的表现，这些都是正式发给玩家前必须验的。哪怕你最后目标是Steam或主机，早做一次WebGL版也能提前扫出一大批潜在炸弹。
我在实际操作中最大的体会是：AI这次帮了大忙，但它只解决了我“知道要改什么”之后的速度问题，不能替代我判断“为什么要这么改”。比如File.WriteAllText要换成PlayerPrefs，如果我不懂WebGL沙箱，AI给一百个版本我也接不住；又比如内存设置256MB，这个数值不是AI告诉我的，而是反复构建、打开任务管理器观察浏览器内存占用后拍板的。两小时迁移成功，靠的不是AI神奇，而是2018年写代码时就重逻辑、轻依赖的好习惯，加上这一次愿意砍功能、认怂适配。这也是我给所有想把手头老游戏搬上浏览器的人最核心的建议：控制依赖、做减法、先跑通再优化。
