企业官网建设流程全解析

上周清理网盘的时候，翻出了2018年那个Unity塔防工程的完整备份。解压、双击打开，等Unity重新编译完的那几分钟里，时间感一下子回来了——那是我第一次完整做出来的塔防游戏，玩法对标保卫萝卜，玩家在网格上摆炮塔，敌人沿着弯弯曲曲的路径冲过来，萝卜被咬一口就得赶紧修。当时做完还挺得意，给同学装了安装包，然后就没有然后了。这周我突然很想把它搬进浏览器，原因很朴素：一个链接能打开的东西，才有人愿意点。真正让我觉得这事儿能成的，是AI。这几年我用AI辅助写代码已经成了习惯，Unity发布WebGL也早就过了"坑多到没法用"的阶段，两个条件叠在一起，我预估一个下午能解决，结果从动手到浏览器里跑起来，实际花了不到两小时。这篇就把整个过程写出来，包括AI帮我干了什么、它干不了什么，以及WebGL这条路上那些藏在暗处的坑。

1. 这个2018年的塔防项目，究竟值不值得搬

1.1 项目底子：玩法、代码量和工程现状

先交代一下项目本身。这是一个标准的俯视角塔防，地图里有一条从入口到出口的弯曲路径，玩家在路径两边的格子建塔，塔分成三种：单体高伤、范围溅射、减速控制，打怪赚金币，再升级塔。波次系统是手写的一个WaveConfig列表，每一波生成什么怪、间隔多少秒都是配在ScriptableObject里的。关卡就一关，但是有20波，后期怪物血量指数往上跳。核心逻辑大概是三千多行C#，没有用任何第三方插件，存档用JsonUtility序列化后写进Application.persistentDataPath下的文件，音效从网上找的MP3，UI全是UGUI，字体用的是Unity默认的Arial动态字体。

这些信息在搬家的时候全变成了"隐患清单"。没有第三方插件是最大的运气，要是当年手贱装了某个收费插件又联系不上作者，光是授权和兼容性就够喝一壶。但另外几项基本都在WebGL的雷区里：文件读写、MP3音频、动态字体、固定分辨率。

1.2 浏览器端的吸引力：零安装、可分享、跨平台

说到底，为什么非要把一个老项目搬进浏览器？三个字：传播成本。桌面端的Unity游戏，要么发一个exe让人下载，要么打个zip包，但凡是发给非技术朋友，对方第一反应永远是"这什么东西，能不能直接在网页里玩"。学生时代最打击人的一句话就是："你这游戏挺好玩，但我电脑装不了。"浏览器端就完全没有这个问题，发一个URL出去，点击即玩，不需要安装任何运行时。Unity为用户提供了唯一的浏览器导出路径，那就是WebGL。而且它天然跨平台，Windows、macOS、Linux、Android、iOS的浏览器都能跑，手机能用Chrome打开，虽然操作手感差一点，但至少能看朋友玩。

1.3 为什么是现在：WebGL成熟度与AI工具的双重加持

2018年那会儿Unity 5.x和2018版已经有WebGL导出了，但体验相当一般。当时的痛点是：加载一个几十MB的data文件慢得能去泡杯咖啡，浏览器内存一紧张整个标签页直接崩溃，调试工具少得可怜，社区里遇到问题搜半天全是英文帖子还未必有答案。这几年浏览器对WebAssembly的支持早就成了标配，Unity从2019开始把WebGL归入官方重点维护目标，2021 LTS的WebGL已经可以作为正式产品发布了。与此同时，AI编程助手的代码扫描、批量替换、文档查询能力，把"翻手册找API"的时间压缩到了几乎为零。当一个技术路径足够成熟，加上一个能帮你干脏活的工具，两小时把老项目复活到浏览器，就不再是天方夜谭。

2. 上手前的摸底：五个最可能卡住WebGL的问题

2.1 版本升级：从2018.2到2021 LTS，我的选择与理由

我一开始也犹豫过要不要用当年的Unity 2018.2直接发布WebGL，毕竟"能不动就不动"是抢救老项目的铁律。但查了一圈发现，2018版本的WebGL后端虽然能跑，IL2CPP编译出来的wasm体积和优化都不如后面的LTS版本，而且一些重要的WebGL修复和内存管理改进都没有。所以我选了一条稳妥的路：用Unity 2021.3 LTS打开旧工程，让它自动做一次升级。

升级过程比我想象的平静。Unity弹了几条API过时警告，比如Application.GetStreamProgressForLevel这种早就被淘汰的接口，以及MonoBehaviour写法的提示，但核心玩法在编辑器里跑了一遍，逻辑正常。这里有一条重要经验：升级之后先别急着做WebGL，先在Editor里把整个游戏从头玩到尾，确认升级没有引入逻辑回归，再谈发布。否则你后面排查浏览器问题的时候，根本分不清是WebGL的锅还是升级的锅。

另外桌面端构建会生成GameAssembly.dll，这是IL2CPP把C#编译后得到的动态库，很多人好奇它是干什么用的。但在WebGL发布路径下没有DLL这个概念，IL2CPP产物会直接编译进.wasm文件，整个游戏就一个wasm加一个data文件，所以针对GameAssembly.dll的调试思路在WebGL下完全不适用。

2.2 资源体检：贴图、音频、字体的WebGL生死线

发布之前我把项目里的资源分类过了一遍，列了个表，凡是下面这几类资源都要特殊处理：

这里面音频和字体是我这次实际踩到的，后面细说。贴图倒是没出问题，因为我当年用的都是最朴素的PNG，没有开任何平台压缩。

2.3 代码体检：脚本里的"桌面病"

代码层面的问题比资源更隐蔽。我把整个Scripts目录丢给AI做了一轮"平台兼容性审查"，要求它按WebGL的约束找出所有违规点。这里先说明WebGL的两条铁律：单线程，没有同步文件系统。基于这两条，桌面项目里常见的"桌面病"基本可以分成五类：

• System.IO的文件类API，比如File.WriteAllText、Directory.CreateDirectory，在WebGL下不能直接使用，因为根本没有可写的本地磁盘，唯一的持久化通道是IndexedDB。
• 线程和锁的用法，比如Task.Run、new Thread、lock，WebGL是单线程模型，这些API要么不可用要么没有意义。
• 网络相关，比如System.Net.Sockets，在WebGL下只能走WebSocket，普通TCP客户端不可用。
• 没被平台宏包裹的编辑器依赖，比如脚本里直接用了UnityEditor命名空间，发布时编译直接报错。
• 平台相关的时间/文化问题，比如DateTime.Now.ToString()带地区的格式，在不同语言浏览器下会输出不同结果。

AI给出的清单里，最让我汗颜的是它翻出了一个我早就忘记的System.Net.Mail引用，那是我当年试图像服务器发邮件时留下的遗留代码，虽然没怎么调用，但在WebGL编译时会报错。这种静态扫描类任务，AI的速度和准确率确实远超人类肉眼翻文件。

2.4 场景与UI：看不到但会炸的细节

场景和UI层面的问题，编辑器里往往看不出来，但一上浏览器就现原形。我在2018年做的是固定分辨率设计，官方分辨率960x540，浏览器窗口比例一变化，UI和场景就拉伸变形。解决办法是给Canvas加上CanvasScaler，设置为Scale With Screen Size模式，参考分辨率保持960x540，这样各种比例下都能等比缩放。

还有个细节是UGUI的按钮点击范围。热词里有人问"Unity如何扩大按钮的点击范围"，在WebGL下这个问题会放大，因为浏览器端的鼠标精度可能不如桌面，尤其手机浏览器上手指头粗，小按钮特别难点。除了常规的调整RectTransform尺寸，还可以实现IPointerClickHandler配合alphaHitTestMinimumThreshold，让透明区域也能响应点击，或者直接给按钮挂一个透明的扩大层，这些方法在WebGL下同样适用。

至于UI事件系统，一定要确保场景里有EventSystem，并且Input Manager没有被禁用。如果用新Input System，要确认Project Settings里Active Input Handling选了Both或新Input System。

3. AI辅助改造的具体过程：三个来回搞定代码适配

3.1 第一回：让AI给整个项目来一次"平台兼容性审查"

我用的方式是对话式AI编程助手，把Scripts目录的文件列表和几个关键脚本片段喂给它，然后给了一个明确的任务约束："这是一个准备发布到WebGL的Unity 2018老项目，请按单线程、无文件系统、无普通Socket这三条约束，找出所有不合规的API调用，并给出替换方案。"

这里的关键是任务约束要清晰，否则AI只会泛泛而谈"建议检查文件系统"。有了约束之后，它输出了一份违规清单，每条都带文件名和行号。我照着清单逐一核对，发现大部分命中都是准确的，尤其是我自己都忘了的那些历史遗留代码。这个过程大概花了十五分钟，如果靠人眼去翻三千行代码，没有一小时下不来。

有一点要提醒：AI给出的行号偶尔会因为文件编码问题对不上，所以不能完全照着改，要自己跳过去确认一下上下文。不过作为"快速体检"已经足够高效了。

3.2 第二回：存档系统的移植，PlayerPrefs vs IDBFS

存档系统是这次改造里最核心的工程。原代码长这样：

string path = Application.persistentDataPath + "/save.json"; string json = JsonUtility.ToJson(saveData); File.WriteAllText(path, json);

这段代码在桌面端没问题，但到了WebGL下，Application.persistentDataPath指向的是一个由Unity维护的虚拟文件系统，底层通过IndexedDB做持久化，也就是常说的IDBFS。理论上可以继续用，但IDBFS在某些浏览器隐私模式和特殊策略下会写入失败，而且调试起来更麻烦。最省事的方案是直接换用PlayerPrefs：

PlayerPrefs.SetString("save_data", JsonUtility.ToJson(saveData)); PlayerPrefs.Save();

PlayerPrefs在WebGL下的底层同样是IndexedDB，但Unity做了更完善的封装和异常处理，对开发者更友好。不过它也不是万无一失的，我在后面第4节会详细讲IDBFS写入失败的真实场景。

换完存储API之后，我又让AI帮我写了一个独立的存档管理器，把序列化、压缩、写读、校验全部封装起来。存档Json里有一个版本号字段，这样将来游戏迭代数据结构变了，还能做旧存档升级。这种"老存档升级"的逻辑我坚持自己写，因为AI不知道我的存档字段含义，写出来的迁移代码我也不敢信。

3.3 第三回：音频、输入与加载逻辑的批量替换

音频改造是另一个大工程。WebGL默认不支持压缩音频格式，MP3和Vorbis在早期版本里播放不了，就算新版支持了，延迟和兼容性也远不如桌面。我的做法是把所有MP3一次性转成WAV，重新导入Unity，Import Settings里把Load Type改成Decompress On Load。代价是包体变大，但游戏里的音效本身就是短片段，总量不大，可以接受。

转完之后我发现移动端浏览器还有一个坑：自动播放策略。Chrome和Safari都要求页面在用户交互之后才能播放音频，否则AudioSource.Play()会被静默忽略。解决办法是在游戏开始前让玩家点一下"开始游戏"按钮，在点击事件里初始化AudioContext或触发一个无声的AudioSource，把音频通道"解锁"。这个逻辑我用AI快速生成了，但它生成的版本没有考虑WebGL下音频延迟问题，我自己补了一段"预加载+延迟补偿"的处理。

输入和加载逻辑相对简单。旧Input Manager在WebGL下对鼠标和触摸的支持还可以，UGUI的点击在触摸屏上也能用，只要EventSystem在场。加载方面，SceneManager.LoadSceneAsync在WebGL下的进度是假的，因为所有场景数据在构建时就已经全部下载完了，不像桌面端是流式加载。如果需要真实加载进度，就得用UnityWebRequest预下载AssetBundle再切换场景。我这次把所有关卡数据拆进了AssetBundle，首屏只加载主场景，然后按需下载关卡资源，进度条真实可见。

3.4 AI生成代码的边界：哪些我坚持人肉改

AI在这次改造里确实是主力，但有几类东西我坚持自己写，不交给它：

• 存档迁移和兼容性逻辑，涉及具体业务字段的，AI不知道"萝卜血量"在存档里叫什么，强行生成等于埋雷。
• 任何涉及协程嵌套和异步时序的逻辑，比如"先下载AssetBundle，再加载场景，失败重试"这种流程，AI生成的代码经常有边界问题，重试次数、超时处理都考虑不周。
• UI动效和数值调优，AI可以给一个Tween的写法参考，但具体缓动曲线、时长、间距这种手感层面的东西，只能自己一遍遍调。

换句话说，AI适合做"批量翻译"和"按清单扫描"，不适合做"设计决策"。它帮你省下的是翻文档、查API、Copy-Paste的时间，而不是做决定的时间。还有一个细节，AI生成的代码粘贴过来之后，一定要看一眼using语句和缩进，编译报错的时候别急着怪网，十有八九是少了一个命名空间。

4. 浏览器里跑起来之后，我陆续踩的七个坑

4.1 存档写入失败：IDBFS到底什么时候会炸

第一版Build出来，我在Chrome里玩得很开心，然后顺手在Safari隐私模式下测试，结果游戏能玩，存档功能直接废了。控制台里一行刺眼的报错，大意就是IDBFS写入失败，Storage的写入操作被拒绝。原因很简单：隐私模式下Safari对IndexedDB的支持是受限的，甚至完全禁用；Firefox的严格隐私模式也会做Storage Partitioning，导致原本的存储分区不可用。Chrome正常不代表所有浏览器正常，尤其是用户手动开启了无痕模式或者公司统一配置了浏览器策略的时候，IDBFS是第一个炸的。

我的解决办法分三层。第一层，所有PlayerPrefs写入都包try-catch，捕获异常后弹窗告诉玩家"当前浏览器环境无法存档，游戏将以内存模式运行"。第二层，存档内容做一次压缩，把Json里的空格、缩进全部去掉，配合字段名缩写，存档体积从几十KB压到几KB，降低配额耗尽的概率。第三层，控制Save频率，不要每个事件都Save，只在波次结束、金币变动大于阈值、退出游戏这三个节点写盘。

4.2 内存爆掉：把WebGL Memory Size从默认256MB调高

第一次完整测试，玩到第12波，页面突然无响应，Chrome提示"此页面已无响应"。打开DevTools看性能，发现wasm内存一路飙升到上限然后崩了。Unity WebGL默认的堆内存上限是256MB，这个数字对一个小型塔防理论上是够的，但我当年的代码有个坏习惯：子弹和敌人全是Instantiate和Destroy，没有做对象池，逻辑跑起来之后GC跟不上，内存碎片化严重，堆自然就爆了。

解决方案分两块。第一块是调参：Project Settings -> Player -> Publishing Settings里的WebGL Memory Size调到512MB，这能撑住大部分场景。但堆内存不是越大越好，内存过大会拖慢低端手机的启动速度，因为浏览器要预留一整块连续内存。第二块是治本：给子弹和敌人做对象池，循环利用GameObject，这一套AI帮我写了个泛型ObjectPool，接入之后内存曲线明显平稳多了。顺手还调用了Resources.UnloadUnusedAssets()，但注意这个操作在WebGL下很慢，不能频繁调用。

4.3 中文全部变方块：动态字体的锅

打开浏览器看到UI上的中文全是"□□□"的那一刻，我第一反应是编码问题，查了半天才发现根本不是。原因在字体：2018年项目用的是Unity UGUI默认的Dynamic Font，也就是运行时从操作系统加载系统字体。桌面Windows上有微软雅黑、宋体这些中文字体，所以显示正常。但WebGL运行在浏览器沙箱里，根本访问不到操作系统字体文件，所有依赖系统字体的文本全部变成方块。

解决办法是打包一份中文字体进项目。我选了思源黑体，下载TTF放进去，创建FontAsset，然后在UGUI组件和TextMeshPro字体设置里都换成它。注意一个细节：中文字体文件动辄好几MB，如果只是UI上几个固定词组，可以用字体子集化工具只保留用到的字，体积能压到几十KB。我因为UI文本不算多但也没到能子集化的程度，直接整包了，代价是加载多了一两秒，能接受。

4.4 阴影消失、粒子发黑：渲染兼容性排查

第三波怪走出来的时候，我发现塔的投影全部消失了。桌面版明明有阴影，WebGL里一片干净。排查结论是：WebGL对实时阴影的支持和性能都比较差，尤其是老项目的Shader在WebGL 1.0模式下，阴影相关的宏和采样器经常出问题。我的处理是把实时阴影关掉，改用假阴影——每个塔下面贴一张半透明的黑色圆形贴花，视觉上完全够用，性能还更好。

粒子发黑是另一个坑。我有个技能特效用的Additive材质，在WebGL下粒子全部变成黑色方块。查Shader代码发现里面用了一些老式的TexGen和HDR高精度依赖，WebGL不支持。解决办法是把所有自定义Shader的pragma target改成3.0，去掉不兼容的指令。这里我让AI做了一轮Shader代码审查，它删掉了两个用不到的浮点精度修饰符，效果立竿见影。

4.5 加载时间：从30秒到6秒的优化

最初版本直接发布，整个项目打成一个data文件，压缩前45MB，我本地服务器加载都要几十秒。后来做了三步优化：先把Compression Format从Disabled改成Brotli，这一步直接让传输体积从45MB降到18MB；然后勾选Player Settings里的Data Caching，让浏览器把文件缓存到本地，第二次打开几乎秒进；最后把首屏不需要的关卡数据拆进AssetBundle，进去游戏后再异步加载，首屏实际只加载主场景，总共大概8MB。三个操作叠加，从点击链接到进入主界面，冷加载大概6秒，热加载2秒以内。

要注意的是启用Brotli之后，你的Web服务器必须正确返回Content-Encoding: br响应头，否则浏览器解压不了会直接白屏。如果用GitHub Pages，它会自动处理对应的静态压缩。这点我在第6节还会提。

4.6 浏览器兼容性：Chrome都行，不代表所有浏览器都行

我的测试顺序是：Chrome桌面 -> Edge桌面 -> Firefox桌面 -> Chrome Android -> Safari iOS。每一个都有幺蛾子。Chrome桌面最稳，几乎没遇到问题。Edge因为内核也是Chromium，基本沿袭Chrome表现，但内存占用高的时候更容易被系统杀掉。Firefox在默认隐私模式下的IndexedDB分区策略会导致存档逻辑走到异常分支，代码里要做好提示。Safari iOS是重灾区，一方面音频必须严格在用户点击后初始化，另一方面内存限制苛刻，512MB的堆内存可能在低内存机型上直接闪退，所以iOS端我临时把内存限制降回256MB并关闭了部分特效。

另外如果你遇到"谷歌浏览器打不开网页"或者"chrome打开网址后闪一下就变空白"这类问题，先检查是不是浏览器扩展拦截了wasm的加载，或者chrome://gpu里硬件加速被禁用了。WebGL非常依赖GPU加速，没硬件加速一进游戏就白屏。

4.7 开发期最容易忽略的：控制台报错不可怕，可怕的是什么都不报

WebGL崩溃和桌面崩溃完全是两个世界。桌面崩溃会弹错误弹窗，有堆栈信息可以定位。浏览器里wasm一崩，页面直接白屏，控制台可能连个红色报错都没有。所以我在所有关键流程里埋了Debug.Log，从"开始加载"到"创建玩家存档"，每步一个标记，崩溃之后刷新页面看日志输出到哪一步，就能快速锁定范围。开发期一定要开Development Build，配合Unity Profiler远程分析内存，虽然在WebGL下Profiler功能有限，但总比两眼一抹黑强。

5. 两个小时的时间账本：AI到底省了多少事

5.1 时间分配复盘

说起来是两小时，其实拆开看，每个阶段花的时间差异很大：

能看到真正的瓶颈不在代码改造，而是在浏览器里的"验证-发现问题-再验证"循环。这个循环AI帮不上忙，它只能在你把报错信息丢给它的时候给一个猜测，但最终判断还是要靠DevTools和真机测试。

5.2 AI做得好、AI做得差、AI根本做不了

把这次经验收敛一下，我对AI的能力边界有了更清晰的认知。

AI做得好的是：批量API替换，像File.WriteAllText到PlayerPrefs的规则性转换，准确率极高；生成try-catch包装和防御性代码；写AssetBundle加载工具；扫描过时API引用。

AI做得差的是：UI布局数值的猜测，它给的间距、大小基本都要亲自调；复杂异步时序，协程嵌套和失败重试逻辑它写的代码总有边界漏洞；还有Shader调试，它只能给通用建议，遇到具体渲染问题还是靠自己。

AI根本做不了的是：产品决策，比如"这个功能要不要砍掉"；存档兼容性设计，因为它不知道业务字段；以及"如何在用户数据丢失时用最温和的文案提示"这种细节，这需要真实玩家经验积累。

5.3 为什么说两个小时是真实体验，而不是噱头

能两小时跑通，前提是项目本身小且干净：三千行C#、没有第三方插件、单一场景、没视频、没复杂Shader。这个前提决定了AI的"扫描-替换"模式能完全发挥。如果项目用了网络同步库、接入SDK、或者有一堆自定义编辑器工具链，两小时绝对不够。所以这个时间门槛的意义不在于"什么项目都能两小时搞定"，而在于它把"复活老项目"的边际成本降到了足够低，低到你愿意给每一个积灰的demo一次重生机会。

6. 给想复活的你：一份可以直接抄的发布检查单

6.1 发布参数推荐

以下是这次调参之后的最终配置，可以直接参考：

6.2 浏览器端测试清单

发布之前，我在每个目标浏览器上都跑了一遍同样的测试路径，列成清单就不会漏：

• 首屏加载是否正常，进度条是否跟随真实下载进度
• 点击"开始游戏"后音频是否解锁，背景音乐是否播放
• 第一波敌人是否正常生成，塔的攻击是否生效
• 玩到第5波后手动存档，刷新页面读档
• 切后台再切回来，游戏是否暂停、恢复后是否有音频异常
• 连续玩20分钟，观察内存是否稳定
• 隐私模式/无痕模式下存档功能是否给出友好提示
• 低端手机或老设备，首屏能否在10秒内进入

6.3 部署分享方式的选择

Unity WebGL构建出来是一堆静态文件，不能直接双击打开，file://协议下浏览器会因为跨域问题禁止加载.data文件，控制台会报Cross-Origin错误。必须起一个静态服务器。我的选择有三个梯队：最快的是用itch.io，把WebGL构建打包上传就能生成一个游戏页面，还附带浏览器兼容性处理，朋友点链接直接玩；如果想要自定义域名和固定地址，用GitHub Pages，免费加HTTPS，把构建产物推到仓库的gh-pages分支就行；如果面向国内朋友，希望访问速度稳定，可以放到对象存储加CDN，开启静态网站托管。

我自己是先在itch.io做了内部验证，之后部署到GitHub Pages长期挂着。整个部署过程大概十分钟，比当年打包exe发网盘然后再写使用说明要轻松太多。

最后说点私心体会。刚开始我纯粹是想体验一下让AI替我做脏活的感觉，但真正把2018年的存档文件拖进2025年的浏览器时，那个塔防游戏的"萝卜被咬一口"动画居然和当年一模一样。我忽然意识到，这种成本极低的"复活"会变成一种习惯：以后每一个写着玩的项目，我都会默认它是能被搬到网上的。WebGL从当年的"坑王"变成了今天的"默认选项"，AI从"辅助"变成了"搭子"，我唯一要做的就是别让技术选型拦住"把它做完"的冲动。如果你手头也有一个吃灰的老工程，给它两小时，它值得。