企业官网建设流程全解析

上周末整理硬盘，翻出一个2018年的Unity工程，压缩包名字叫“DefenderLike_Liuli”。解压那一刻我记起来了，这是当年照着保卫萝卜思路做的塔防Demo，一堆炮塔模型是拿Cube和圆柱拼的，敌人就是红色胶囊体，UI全是Unity 5.6时期的UGUI。当时只图能跑起来交作业，压根没考虑过跨平台。

这项目虽然粗糙，但核心玩法还算完整，有路径、炮塔、金币、波次，玩起来能上头。心血来潮想发给朋友玩，可总不能让人家先装一个Unity再导入工程吧。正好这段时间一直在用AI辅助开发，于是决定试试：让AI帮我把这个老古董搬进浏览器。两个小时后，游戏居然真的在Chrome里跑起来了，地图、炮塔、金币、波次全都还在。整个过程比想象中顺利，但中间踩了不少坑，所以写一篇出来，给那些手里有老旧Unity工程、又想快速放到浏览器上的朋友当参考。

1. 项目背景与迁移方案选型

1.1 2018年那坨“保卫萝卜”到底有什么

先交代一下项目底子。这套“保卫萝卜”Demo是Unity 5.6.3p1写的，核心代码量大概五千行以内，场景里放了一张手绘网格路面，敌人沿着路径点列表移动，炮塔在攻击范围内自动索敌并开火，敌人死亡掉金币，金币用来升级炮塔，打满指定波次就算过关。UI用的是旧版UGUI，屏幕左下角是金币、生命值，顶部有开始/暂停按钮，整体参考分辨率是960x640。

美术资源大部分是当时从资源商店免费包里翻出来的，还有一些土法拼的占位图。音效是网上找的音效素材剪的，名字早忘了。整个工程没有做版本控制，压缩包里那一整套Unity目录就是全部家底。正因为项目足够小、足够独立，两个小时迁移才算有一丝可能；如果是个大规模商业项目，这个流程要放大很多倍。

1.2 迁移方案对比：为什么最终选择Unity WebGL

在动手之前，我列过几个路线。

第一个是Unity官方WebGL发布。优点是C#代码几乎能原样保留，Unity场景、预制体、动画、粒子这些老资产可以直接复用；缺点是打包出来的包体大，初次加载慢，而且浏览器环境有些API限制。但对我们这种Demo来说，这个方案几乎是唯一选择。

第二个是用AI把游戏逻辑重写成纯HTML5 + JavaScript/TypeScript，比如用Phaser或者原生Canvas。这个方案听起来很“现代”，但Unity场景里的预制体、UI布局、粒子效果没法自动转换，重写一遍再调试，两个小时根本不够，更别说还得重新造轮子了。

第三个是让AI直接把Unity项目转换到其他引擎，比如Godot、Cocos。这些引擎虽然有Unity导入插件，但对脚本逻辑、UI绑定和动画状态机的处理非常有限，大概率只能导入一堆半残的材质和模型，然后继续手写。对于这种写满了MonoBehaviour的老工程，转换成本极高。

所以我最终选择了“Unity WebGL + AI辅助”的组合。用表格对比更直白：

1.3 AI在整个迁移里的真实身份

不少人以为AI能“一键把Unity转成网页”，它不是。我这次让AI干的三件事是：解析编译报错并给出改法、批量生成代码替换脚本、在我不熟悉Unity WebGL特性时给出API和配置建议。它没有真正“打开”Unity工程，也没有直接帮我拖拽场景里的任何一个预制体。

它更接近一个特别有耐心的结对编程搭档：我把报错贴给它，它给我候选修改；我把构建日志丢给它，它帮我定位问题。因为AI没有项目全貌，我必须在提问前把Unity版本、脚本片段、浏览器控制台报错这些东西一股脑喂给祂。听起来麻烦，但在遇到“IDBFS写入失败”这种以前根本不会碰到的报错时，它能帮我省掉几个小时的搜索时间。这也是我决定把这个过程写出来的原因——AI可以成为老项目迁移的翻译官，但你需要有基本的工程判断力来验收它的输出。

2. 老工程抢救：AI帮我把2018年的代码盘活了

2.1 从旧版本打开工程的“第一步坑”

Unity 5.6的工程直接用2021.3打开，第一波不是报错，而是警告和资源变更。Unity会提示升级YAML版本，然后因为脚本序列化方式变了，场景里丢了一堆组件，变成了“Missing Script”。我当时差点以为素材全坏了。

后来让AI写了一个Python脚本，扫描所有.unity场景和.prefab预制体，找出包含m_Script: {fileID: 0}的行。这个字段代表该组件引用了不存在的脚本，是Unity升级后最常见的“孤儿组件”信号。

import os, re pattern = re.compile(r'm_Script: \{fileID: 0') for root, dirs, files in os.walk('Assets'): for f in files: if f.endswith('.unity') or f.endswith('.prefab'): path = os.path.join(root, f) with open(path, encoding='utf-8', errors='ignore') as fh: for idx, line in enumerate(fh, 1): if pattern.search(line): print(f'{path}:{idx}')

把输出结果一条条对着看，删除或重新绑定脚本引用。这个操作很枯燥，但AI替我把“定位”这一步省了。第一次在旧项目上用脚本做体检，我才意识到：老的Unity工程就像一间堆了十年杂物的仓库，直接搬家之前，先得把里面已经报废的旧东西标记出来扔掉。

2.2 过时API清理：AI批量替换不如自己拍板

升级之后，编译错误主要集中在过时API。Unity在5.x到2021之间改了太多接口。我遇到的典型情况有这些：

AI先给我生成了一段文本替换脚本，把代码里出现的rigidbody.velocity、rigidbody.AddForce这类调用，正则替换成GetComponent<Rigidbody>().velocity、GetComponent<Rigidbody>().AddForce。但这里有一个坑：不能无脑全局替换，因为某个类里可能自己声明了rigidbody字段，或者有独立的变量名也叫“rigidbody”。如果替换错了，代码逻辑会变得非常奇怪。

所以我的做法是：先用Git提交一次旧版本，然后针对每一个编译错误逐个处理。AI给我diff级别的修改建议，我看一眼调用点合不合理，再点击应用。这个过程一点也不“智能”，但胜在安全。等编译通过后，再专门做一次全局搜索，把没被编译器发现但确实过时的API清理干净。

2.3 用AI快速建立项目的“逻辑地图”

第二个提升效率的骚操作是：把核心脚本贴给AI，让它梳理数据流。我当时的原话是：“请只描述这个项目的调用链，不要给我优化建议，也不要逐行解释。”结果是，AI很快给了我一幅逻辑地图：

• 敌人沿路径点列表移动，到达终点后扣生命值
• 炮塔在攻击范围内锁定敌人，按冷却时间发射子弹
• 子弹用协程移动到目标，命中后造成伤害
• 敌人死亡时通知GameManager增加金币
• UI从GameManager读取金币和生命值并刷新显示

有了这张地图，我一眼就能分辨哪些逻辑可能在WebGL上出问题：比如File.WriteAllBytes的存档接口、基于Unity协程的子弹移动、UGUI的按钮点击区域。这种“先用AI做信息提取，再人工做判断”的工作方式，比逐行读代码高效太多。千万不要让AI直接“优化代码”，让它先给你画地图，你再做决定。

3. 核心实操：Unity WebGL构建与浏览器端问题解决

3.1 切到WebGL平台，Player Settings一个都不能少

Unity WebGL模块一开始没装，需要先到Unity Hub添加。切换平台的路径是File > Build Settings，选择WebGL后点Switch Target。这时候Unity会提示需要调整一堆Player Settings，我的经验是别跳过，后面每一个都可能是坑。

重点设置如下：

• 分辨率：Resolution and Presentation里Canvas的参考分辨率设为960x640，和原UI设计保持一致。
• 压缩格式：Publishing Settings里的Compression Format，初次调试选Disabled。原因很简单，一旦开启压缩，静态服务器如果没配好Content-Encoding，Unity Loader很可能解压失败，页面直接白屏。先把功能跑通，再优化体积。
• Graphics API：保持WebGL 2.0，并勾选WebGL 1.0作为fallback，以便兼容老电脑和部分浏览器环境。
• 多线程：Unity默认开启WebGL多线程，但它依赖浏览器的SharedArrayBuffer，而SharedArrayBuffer要求服务器返回跨源隔离响应头。如果不想折腾服务器配置，就先在Player Settings里把多线程关掉。

这些设置直接影响后面浏览器的加载和运行体验。如果跳过，很可能在第一步就撞上白屏或内存异常。

3.2 编译报错怎么快速清掉：AI批处理思路

切到WebGL平台后，Unity重新编译，Console里弹出一批错误。我的处理流程是：把错误的完整文本复制给AI，让它分类并给出修改建议。

几个经典的例子：

// 旧代码 Application.LoadLevel(nextLevel); // AI建议改成 using UnityEngine.SceneManagement; SceneManager.LoadScene(nextLevel);

再比如：

// 旧代码 rigidbody.velocity = new Vector2(speed, 0); // AI建议改成 GetComponent<Rigidbody>().velocity = new Vector2(speed, 0);

但AI也不是万能的。当它给的代码引用了不存在的类时，我会把对应的using补上；当它建议“删除这段代码”时，我会多看一遍是否影响玩法。安全起见，每应用完一批修改就编译一次，编译通过后立刻Git提交。这样的节奏虽然慢，但每一步都是稳妥的。

3.3 构建产物与本地联调

WebGL构建完成后，会生成index.html、Build目录和TemplateData目录。记住：不能直接双击index.html在浏览器里打开，浏览器的安全策略会拦截本地文件请求，报跨域错误，页面一直停在加载界面。

正确的姿势是在本地起一个HTTP服务：

python3 -m http.server 8080

浏览器访问http://localhost:8080。如果是VS Code用户，也可以安装Live Server插件，一键启动。我当时让AI额外写了一个serve.py，用途是给/Build/下的文件设置正确的MIME类型，并支持Gzip返回，后来测试压缩格式时省了很多事。本地联调的核心思路：先把问题限制在Unity侧，不要一上来就部署到线上平台。

3.4 存档与IDBFS写入失败：那个让我差点放弃的坑

这是一开始最卡的环节。塔防游戏有金币和关卡进度，老代码里我用Application.persistentDataPath存了一个存档文件。在Windows上运行完全正常，但WebGL构建出来以后，点保存没有任何反应，控制台里一直刷“IDBFS sync failed”这类错误。

把报错丢给AI，我才理解：Unity WebGL运行时的文件系统不在本地磁盘，默认是一个内存文件系统。当你想写入persistentDataPath的时候，Unity需要把数据同步到浏览器的IndexedDB里。如果同步失败，写文件就失败。旧版本Unity在某些情况下不会自动挂载IDBFS，或者因为浏览器索引数据库被禁用、服务器跨源隔离设置不对，导致写入直接报错。

AI给了两个方向。第一个是用.jslib插件手动挂载IDBFS：

mergeInto(LibraryManager.library, { SyncFS: function () { FS.syncfs(false, function (err) {}); }, MountIDBFS: function () { FS.mkdir('/idbfs'); FS.mount(IDBFS, {}, '/idbfs'); FS.syncfs(true, function (err) {}); } });

然后通过C#的[DllImport("__Internal")]调用。但实测这个方案在IL2CPP下容易被裁剪，而且调试起来很麻烦，对一个小Demo来说投入产出比太低。

第二个方案简单粗暴：把存档全部换成PlayerPrefs。PlayerPrefs在WebGL平台会自动落到浏览器IndexedDB里，刷新页面、关闭标签页再回来都能保留。对我这个“金币+关卡+炮塔等级”的轻量存档来说，完全够用。

public static void SaveProgress(int level, int coins) { PlayerPrefs.SetInt("ProgressLevel", level); PlayerPrefs.SetInt("Coins", coins); PlayerPrefs.Save(); } public static (int, int) LoadProgress() { int level = PlayerPrefs.GetInt("ProgressLevel", 1); int coins = PlayerPrefs.GetInt("Coins", 200); return (level, coins); }

如果你以后在搜索框里输入“unity 发布 webgl 使用 idbfs 写入失败”，别急着造轮子，先想想自己存的到底是不是关键数据。能塞进PlayerPrefs的，先用PlayerPrefs，等真有必须持久化的大文件时，再回来看IDBFS也不迟。

提示：如果确实要持久化整个AssetBundle、SQLite数据库或者日志文件，再考虑IDBFS挂载方案；如果只是保存进度、金币和设置项，请优先用PlayerPrefs。它在WebGL平台会自动落到浏览器的IndexedDB里，刷新、关页面都不会丢，而且几乎不需要额外代码。等你的需求确实超过KV模型，再回来研究.jslib插件也不迟。

4. 浏览器适配、UI与性能调优

4.1 UI缩放与Canvas Scaler

搬到浏览器后，UI又不能直接照搬。960x640是4:3比例，而浏览器窗口可能是16:9、带鱼屏甚至手机竖屏，如果不管，UI会拉伸变形或者有一大截在屏幕外面。

解决办法是打开Canvas组件，挂上Canvas Scaler，把UI Scale Mode改成Scale With Screen Size，参考分辨率设为960x640，Match Width or Height设成0.5。这样Unity会在缩放时同时考虑宽度和高度，尽量保证UI比例不变，屏幕两侧多出来的区域用背景色或游戏地图来填充。

实际操作时，我一边在浏览器里拉窗口尺寸，一边看UI是否还对齐。如果有局部控件位置不对，就去微调它的锚点。WebGL和桌面窗口不一样的地方在于，浏览器本身还有缩放、开发者工具等干扰，所以最好直接以浏览器内容区为准，不要以Unity Game视图为准。

4.2 扩大按钮点击范围（Unity里的小技巧）

老项目里的塔升级按钮做得很小，大概36x36像素。在桌面Unity里用鼠标点还凑合，到了浏览器里一旦缩放窗口，点击就非常吃力，尤其是在触屏设备上。

Unity的Image组件有个特性：默认的alphaHitTestMinimumThreshold是0，也就是即使图片的Alpha是0，Raycast照常接收点击。如果按钮的图标本身四周有大量透明像素，或者按钮尺寸太小，最简单的方式是直接扩大按钮的RectTransform，然后让真正显示图标的Image缩小并放在子节点。

具体操作是：

1. 选中按钮，把RectTransform的Width和Height从36改成60。
2. 把按钮里的Image组件所在的子节点尺寸保持36不变，并关闭这个子节点的Raycast Target，防止它挡住父按钮点击。
3. 如果按钮背景是九宫格切片，把Image Type设置为Sliced，避免拉伸变形。

这样按钮的可点击区域从36变成了60，视觉上仍然是原来的图标大小。如果你要扩展点击区域的控件不是按钮而是一段Text，也可以给它加一个Image组件，把Color的Alpha调成0，默认情况下这个透明区域也能接收点击。

4.3 浏览器里白屏、闪退、内存占用怎么排查

迁移到浏览器之后，最容易遇到的现象是：标题栏都加载完了，页面一闪，然后白屏。我第一次测试时也遇到了，赶紧打开浏览器控制台看，发现是服务器返回的文件压缩格式和Unity Loader预期不一致，导致Loader解析失败。

所以Debug阶段，Player Settings里的Compression Format一定要选Disabled。等本地跑通后，再开启Brotli或Gzip压缩，并确保服务器静默返回正确的Content-Encoding。Chrome和Edge对压缩格式非常敏感，配错就直接白屏。

内存占用方面，Unity WebGL会把整个Wasm堆分配到浏览器进程里，任务管理器里看Edge或Chrome的内存占用会很高。如果项目本身不大，可以在Player Settings里限制WebGL Memory Size，或者在老版本Unity里给Loader传TOTAL_MEMORY参数。这个塔防项目打包后资源不到120MB，所以给Unity分配256MB内存绰绰有余，浏览器压力小很多。

还有一个容易踩的坑是多线程。Unity WebGL默认开启多线程，但它需要服务器设置Cross-Origin-Isolation响应头，才能使用SharedArrayBuffer。如果你用的是GitHub Pages这类没法自定义响应头的平台，游戏加载时大概率会弹错或者卡在白屏。解决办法是把多线程关掉，换来兼容和稳定。

5. 常见问题速查与AI协作心得

5.1 常见报错速查表

这张表基本覆盖了把一个老Unity项目迁到浏览器时最容易遇到的坎。每次遇到问题，先看控制台，再对照表里的原因去排查，比瞎猜省事很多。

5.2 跟AI配合的两小时工作流

如果复盘那两小时的节奏，大概是这样：

• 前20分钟：盘点工程结构，把脚本目录树和报错日志喂给AI，建立上下文。
• 中间40分钟：清理过时API和资源引用错误。每一条都让AI给diff，确认后再改。
• 再40分钟：构建WebGL并以本地服务器跑通，解决IDBFS和UI缩放。
• 最后20分钟：在Chrome和Edge里实测，调按钮热区、压缩格式。

想让AI更精准，提问时要给足够上下文。不要只发“WebGL构建失败”，而是发“Unity 2021.3，项目从5.6升级上来，报错文件是SurvivalController.cs第45行Application.LoadLevel过期”。AI给出的答案命中率会高很多。如果不知道具体问题，就把控制台完整原文复制进去，并说“帮我解释一下并给最小修改方案”。

5.3 给老项目搬家前的一句提醒

如果你的老项目里还有第三方插件，迁移前先确认插件是否支持WebGL。我当时有个音频插件在Windows上好好的，切到WebGL以后直接编译不过。AI能帮你查新API，但插件是否支持，只有实际构建才能验证。更稳的做法是把插件层暂时抽掉，用Unity自带组件替代，等跑通再考虑恢复。

还有一件事别偷懒：全程开着Git。每一次接受AI的批量替换前先commit一次，万一AI的正则写错，把某个字段替换错了，你能随时回滚。迁移老项目时，安全措施不是可选项，是必选项。

最后再分享一点小体会：迁移到浏览器不等于“完成”，性能、GPU兼容、存档策略这些都要在真实浏览器环境里轮一遍。但看到2018年的炮塔在Chrome里重新转起来，成就感还是很实在的。接下来我准备把存档改成云端的，顺便把当年那些凑合出来的音效资源也换掉，反正现在有AI，改起来也不费劲。