企业官网建设流程全解析

做Unity开发这么多年，每次有项目需要发布到WebGL，我心里都会先绷紧一根弦。不是WebGL不行，而是从桌面端切到浏览器环境，坑实在太多：内存动不动就溢出、中文变方块、构建包加载慢、部署到服务器后跨域报错。这些问题单个看都不算大，但凑到一起就足够让人加班到深夜。这篇文章就是我自己踩坑多次之后整理出来的Unity WebGL发布避坑指南，重点讲内存设置、字体打包，以及服务器和构建配置里那些容易被忽略的细节。无论你是准备把Demo发给客户看，还是正经做一版产品上线，这里都有一份可以直接抄作业的经验清单。

1. 为什么Unity WebGL发布总在“最后一公里”翻车

1.1 浏览器不是桌面：先理解WebGL的运行时模型

很多同事习惯用编辑器和桌面构建的思路去套WebGL，结果一发布就崩。原因很简单：WebGL项目其实是在浏览器这个“沙箱”里跑一个经Emscripten编译出来的WebAssembly模块，它没有桌面端那种完整的系统级能力，也没有原生的文件系统。Unity的Mono/IL2CPP运行时会被编译成WASM，最终在一个类似JavaScript的内存堆里执行。这个内存堆的大小在构建时就被设置成固定值，运行时不能像桌面进程那样随便向系统申请扩展空间。

换句话说，你在Player Settings里看到的“WebGL Memory Size”，决定了WebAssembly模块能用的内存上限。场景、纹理、Mesh、音频、Font Asset、Shader中间数据，全部要装进这个容量里。一旦某个资源瞬间超过上限，浏览器就直接把页面杀掉，用户看到的就是白屏或者“Aw, Snap!”一类崩溃提示。这个问题在编辑器里几乎不可能复现，因为编辑器走的是原生内存管理，资源再大也能硬扛。所以要习惯在发布前专门针对WebGL的内存特性做一次体检，并且把这些参数当成发布流程的一部分来对待。

1.2 常见翻车场景速览

我整理了自己和团队在多个WebGL项目里遇到的典型问题，几乎都可以归到这几类：

这些坑单独拿出来都不难解决，但当你同时面对五六个问题时，就很容易陷入“解决一个又冒出一个”的循环。所以下面几节按主题拆开讲，每部分都会给出可复用的参数和步骤。

2. 内存设置：该调的参数一个都不能漏

2.1 内存大小怎么定：从默认值到合理基线

Unity在Player Settings里的发布设置项中，与WebGL内存直接相关的主要是WebGL Memory Size，单位是MB。默认值在很多版本里是32MB，也有部分版本会根据模板显示为16MB甚至更低。这个值对简单Demo可能够用，但只要场景贴图多一点、UI界面复杂一点，32MB几乎必挂。

我个人的基线是：纯展示型页面至少给128MB，包含较多3D模型和纹理的项目从256MB起步，如果场景里有多套UI、粒子特效、视频纹理，直接上384MB或512MB。注意这里说的不是越大越好，内存设得越大，浏览器给页面分配的内存和预处理时间也越多，加载等待会变长。而且WebGL端不像桌面端有虚拟内存，页面占用太高容易在低端手机上被系统强制回收。

实际操作时，我会先把内存设置成256MB，用真实设备和浏览器跑一遍主要流程，打开Performance面板看页面内存曲线。如果峰值稳定在200MB以下，就调回160MB试试；如果峰值紧贴着上限，再加64MB留出安全余量。这个过程有点像调热水器温度，目的是找到一个“跑得动又不浪费”的点。

2.2 纹理与资源加载才是内存大户

很多人会忽略一点：内存设置只是给了一个“水池”，真正让水池溢出的是水面下那些体积巨大的资源。在所有资源类型里，纹理是WebGL内存占用的大头。一张2048x2048的RGBA纹理，在GPU上大约占16MB内存；如果这张纹理开满mipmap链，内存还能再涨三分之一。一个场景里来10张大图，内存就已经被吃掉近200MB。如果用编辑器打开这个场景，桌面端毫不在意，但发布到WebGL就会非常难受。

所以发布前必须做资源体检。我会在Asset检查器里统一查看“Max Size”和“Format”，把UI图集控制在1024或2048以内，把3D模型的漫反射贴图压到2048以下并尽量使用ASTC或ETC2压缩格式。对于不需要mipmap的UI和2D Sprite，一定要关闭Generate Mip Maps，只给3D材质保留mipmap。还有一个很容易忽略的地方是AssetBundle和Addressables。不要把所有资源一开始就全部加载进内存，而是按场景和界面分组，用Resources.UnloadUnusedAssets和AssetBundle.Unload(true)及时释放。

另外，WebGL不支持编辑器里的实时GPU内存统计，发布后我看的是浏览器DevTools的Memory面板。但它的数据是WASM堆内存，不区分存了多少纹理。如果想看Unity自己怎么分配内存，可以在构建时勾选Development Build并开启Autoconnected Profiler，发布后用Profiler连接浏览器采集内存快照。这个流程比较繁琐，我之前写过一个小工具：在工程里定期输出Profiler.GetTotalAllocatedMemoryLong和Profiler.GetTotalReservedMemoryLong，在浏览器Console里也能直接看内存曲线，排查定位要快得多。

2.3 内存溢出排查三板斧

如果你已经被“内存越界”或“内存耗尽”虐过，建议按下面这套顺序排查。

第一板斧：看浏览器Console报错。WebGL内存崩溃最常见的报错是“RuntimeError: memory access out of bounds”或“Allocation failed - JavaScript heap out of memory”。前者大概率是Unity的WASM堆不够，后者多半是浏览器JS堆被Unity的Loader或过多DOM操作吃满。这两种问题解决路径不同，先看报错能少走弯路。

第二板斧：给场景资源做减法。打开Profiler，按内存排序找出占比最高的资源。我通常先看Texture，再看Mesh和AudioClip。如果一个场景里有一堆低模面和大量重复材质，优先做贴图压缩和材质合批。WebGL对DrawCall没有那么敏感，但资源体积是硬指标。

第三板斧：调整Unity内存设置并重新构建。调整WebGL Memory Size后，记得要重新构建，而不是只刷新页面。因为这个值是在构建阶段写进WASM模块的。曾有同事改完设置忘了构建，然后在编辑器里骂了半天“为什么还是崩”，非常现实。

注意：WebGL不支持运行时动态扩容，部分较新版本在Player Settings里能看到Memory Growth相关的开关，但老版本和很多模板默认不支持。如果你的版本有，可以试验性打开；没有的话，稳妥做法就是给内存上限留足余量。

3. 字体打包：中文不显示、字体发虚的真相

3.1 动态字体在WebGL里为什么不可靠

中文显示成方块，是WebGL发布翻车率排名前二的问题。根本原因是Unity的UI Text组件默认使用动态字体，而动态字体在桌面端运行时是从操作系统字体库里“现取现用”的。但浏览器里的WASM环境没有系统字体枚举能力，也没法随便读取本机字体文件。所以Unity在WebGL端只能使用构建时嵌入到AssetBundle或场景中的字体资源，动态字体路径几乎不可用。

很多人导入了中文字体，也把Text组件的字体资源换成了中文字体，可发布后还是方块。这时候要检查两点：一是这个字体文件本身是否真的包含中文字形，有些免费英文字体文件名带“Chinese”但实际只有拉丁字符；二是是否把字体资源放进了构建包。在Player Settings的Build Profile里查看“Only pack listed fonts”这类选项，如果开了，就要手动把字体加进列表，否则运行时找不到。

另一个坑是：即使字体文件打包了，Unity在构建WebGL时仍会按运行场景中用到的字符做裁剪。如果用户输入一段你场景里没出现过的新文字，WebGL端是无法像桌面端那样临时生成新字形贴图的。结果就是有些字显示正常，有些字突然消失或变成方块。对于需要支持任意中文输入的功能，动态字体基本不靠谱，必须换方案。

3.2 TextMeshPro静态字体打包的完整流程

如果你正在做一个面向真实用户的WebGL项目，我的建议是直接把文本显示方案从Unity Text转向TextMeshPro（TMP）。TMP会把字体生成为一张包含字形信息的图集（Font Atlas），构建时随场景一起打包，不依赖运行时系统字体，天然适配WebGL的离线渲染模式。

具体的打包流程我整理成五步：

1. 准备一个中文字体文件，推荐思源黑体（Source Han Sans）或阿里巴巴普惠体，文件格式用.ttf或.otf。注意字体文件越完整，可能生成的图集越大，后续要做子集优化。
2. 在Project窗口导入字体文件，右键选择“Create > TextMeshPro > Font Asset”。如果菜单里没有，可以先创建TMP Settings资源并指定默认字体列表。
3. 选中新生成的Font Asset，在Inspector里把Atlas Resolution调到2048或4096，Sampling Point Size设置好，保证字形在小字号下也不发虚。
4. 关键的一步：设置Character Set。TMP默认的“Character Set”可能只包含ASCII或Basic Latin，中文全没进去。需要改成“Unicode Range (Hex)”，手动填入你要支持的Unicode范围，比如中文字符区段4E00-9FA5，或者直接使用“Characters from File”加载一个文本文件，把项目UI涉及到的中文都放进去。
5. 把所有UI文本组件从Text替换成TextMeshProUGUI，并重新指定Font Asset。然后构建，检查中文显示。

实际项目中，我并不把所有中文都打进去，而是先“文本收集”。用脚本扫描当前场景和预制体里所有UI文本里的中文，生成一个去重后的字符集文件。再把这个文件导入TMP生成Font Asset。这样图集会控制在合理范围，显示效果和加载速度都能兼顾。

3.3 字体体积、子集化与加载性能的取舍

字体问题不只是“显示出来就行”，体积和加载性能同样关键。一张2048x2048的TMP Font Atlas纹理，加载进内存后大概占用16MB，已经接近一张普通UI大图了。如果你的项目包含多套字体，每套都生成一份高分辨率图集，内存叠加起来非常惊人。所以字体方案上我习惯遵循一条原则：一套主字体打天下，最多再加一套粗体或数字字体。

很多团队会用到子集化工具把TTF直接从几百个字符裁成项目需要的那几百个字符。这样TTF文件变小，TMP生成图集时也只包含目标字形，加载体积和内存都能明显下降。子集化工具不唯一，你可以在字体工具或在线服务里按字符集导出子集字体，再做TMP Font Asset。

还有一个小细节：TMP Font Asset里如果开了Dynamic，Unity会把它当成动态字体处理，运行时仍可能尝试从系统加载字形。WebGL端我强烈建议关闭动态选项，强制使用静态图集。这样即使有新增字符无法显示，也好过整个字体莫名其妙丢失。

渲染发虚的问题，多半出在Atlas Resolution不够。我之前有一个初始化项目，TMP的Atlas Resolution用的默认1024，结果中文字号一大，边缘就糊成一片。调到4096之后，清晰度立刻改善，当然内存也涨了。建议先在编辑器里用多个字号预览，再决定Atlas大小。

4. 发布配置与服务器端的那些坑

4.1 压缩算法、Gzip/Brotli与服务器指向

Unity WebGL构建时会在Publishing Settings里提供Compression Format选项，Disable、Brotli、Gzip三选一。这个设置和服务器配置是联动的。以Brotli为例，构建完成后生成的文件不仅包括index.html、Build.data、Build.framework.js、Build.wasm，还会为它们生成对应的.br后缀压缩文件。

如果你把构建文件夹整个传到Nginx或IIS，但服务端没有正确返回压缩头，浏览器会直接下载.br结尾的原始文件，然后Unity的Loader不会自动解压，页面就卡在加载阶段。正确做法是在服务端配置让浏览器和Unity Loader能识别压缩内容。Nginx可以在server块下添加：

location /build/ { brotli_static on; gzip_static on; }

如果你的Web服务器不支持Brotli模块，那就用gzip_static，因为Unity生成的.gz和.br都是预压缩好的。还有一个容易踩的坑是：使用CDN托管构建文件时，别忘了在CDN控制台里给.br和.gz文件添加Content-Encoding响应头。很多CDN默认不认识brotli，会把它当成普通二进制文件返回，结果就是加载失败或白屏。

建议：项目初期就确定压缩格式。如果目标用户多为现代浏览器，选Brotli；如果服务器和CDN兼容性受限，选Gzip。两种格式都不要在构建时选Disable，除非你是在排查压缩相关bug，否则部署包体积会大得离谱。

4.2 CORS跨域问题

WebGL项目部署上线后，最常见的一个运行时报错就是“Cross-Origin Request Blocked”。原因很简单：浏览器的同源策略限制了页面里的WASM或Fetch请求只能访问同源资源。你在本地双击index.html测试时，没有跨域限制，所以一切正常；一旦部署到服务器，再请求外部CDN、API接口、AssetBundle或音频视频资源，就会触发跨域检查。

如果是只部署在静态页面上，同源的资源不会出事；但用对象存储或CDN时，就需要在资源服务器上开启CORS。以对象存储为例，响应头至少要包含：

Access-Control-Allow-Origin: *

如果项目还要携带Cookie或自定义Header，还要加上：

Access-Control-Allow-Credentials: true Access-Control-Allow-Headers: Content-Type, Authorization

这里有个经验：不要滥用*，尤其是接微信小游戏或涉及用户数据的项目，最好把允许的域名显式列出来，避免其他站点“借用”你的WASM资源。

另一个跨域坑是WASM本身。WebAssembly模块对跨域的要求比普通JS更严格，就算服务端允许*，浏览器也可能因为MIME类型不正确拒绝执行。检查服务端是否正确返回了Content-Type: application/wasm。以前我在Nginx上遇到过，Nginx默认没配置.wasm的MIME类型，导致WebAssembly文件加载被当成未知类型拦截，页面白屏了很久。

4.3 首屏加载、进度条与构建瘦身

Unity WebGL的加载体验，往往决定用户留不留得下来。默认构建出来的加载页是个白底加Unity Logo，很多项目上线时连个进度条都没有，用户点了链接还以为页面坏了。自定义Loader不复杂，Unity生成的index.html里有现成的progress回调，注册它来更新自己的页面元素就好。我在模板里用了自定义进度条和“首次加载较慢，请耐心等待”的提示，用户等待焦虑会小很多。

但真正要解决的是加载时间，而不是进度条变好看。构建瘦身可以分三层做：第一层，在Player Settings里开启Strip Engine Code，让IL2CPP裁剪掉未使用的引擎代码，同时把Managed Stripping Level调到Medium或High。注意调高后有风险，因为某些反射用法会被误裁，发布前必须过一遍主要流程。第二层，用Addressables或AssetBundle管理资源，首屏只加载必备场景，其他资源按需加载。第三层，压纹理、压音频。能开Vorbis的音频就开，能压缩纹理就压缩，别把巨大的原始资源一股脑塞进首屏。

内存、字体、服务器都配置好之后，我还会做一次“零缓存完全加载”测试，用浏览器的无痕窗口打开页面，按F12清空缓存，记录从点击到画面可交互的耗时。如果这个时间超过用户忍耐度，再回头看哪个资源最大，继续砍。

5. 实战：一次完整的WebGL发布配置记录

5.1 项目情况与目标

之前接过一个VR选房展示类的项目，需要把Unity场景发布成WebGL嵌入到已有网站里。场景内容是一套精装户型，包含大概40个家具模型、5张高清全景图、一套UI菜单和一个漫游摄像机。最初开发时直接在PC端跑，画面流畅，但第一次尝试WebGL发布就崩了：页面加载到90%后直接报内存越界，切到UI界面后中文全部显示为问号。

项目目标其实很明确：用户端不需要安装任何插件，打开浏览器就能看户型，加载时间控制在20秒以内，内存峰值控制在300MB以内。在这个前提下，我们开始改配置。

5.2 关键配置与操作步骤

内存设置方面，我们先把WebGL Memory Size从默认的32MB直接调到了256MB，然后在编辑器里用Profiler模拟场景加载，统计出“地板、墙面的贴图”占了大头。于是把所有墙面材质把2048贴图压到1024，并关闭了不需要的mipmap；家具模型贴图则用CRunched压缩，构建时再解压到目标格式。这样场景在编辑器里看起来还是会用内存，但因为压低了纹理尺寸，发布后在浏览器端的占用下降了近一半。

字体方案上，我们没有继续用Unity Text，而是把项目的UI Text全部替换成了TextMeshProUGUI。字体文件选了思源黑体的Regular子集，用脚本把场景里所有UI文案的中文字符收集出来，手动生成字符集文件后导入TMP。Atlas Resolution设成2048，Character Set用的是Characters from File，加载好字符集后生成Font Asset。这个Asset最终只有一张2048图集，内存占用可控，中文显示也很锐利。

服务器配置我们用的是Nginx。构建时Compression Format选了Brotli，并在Nginx里启用了brotli_static on;。WASM文件单独加了一条MIME映射：

application/wasm wasm;

同时给静态资源设置了Cache-Control缓存策略，让重复访问的用户直接走浏览器缓存，不用二次下载大文件。CORS这块因为资源和页面都在同一套Nginx下，暂时没有特殊处理；但API调用在另一个域名下，所以我们在API服务里加了允许站点域的CORS头。

5.3 部署后验证与实测数据

配置完成后，我们做了三组验证：电脑Chrome无痕模式、电脑Firefox、手机Chrome。电脑端从点击加载到进入户型页面，耗时在12到16秒之间，主要是Brotli压缩后的WASM和纹理数据占了大部分。内存峰值从最初测试时的崩溃状态降到了220MB左右，稳定运行在256MB的配置范围内。手机端加载时间会慢一些，首次加载接近25秒，但内存峰值反而更低，说明纹理压缩对移动端更友好。

中文显示方面，所有UI菜单、户型名称和提示文案均正常显示，没有出现方块或模糊。后来我们又加了一个输入用户姓名的功能，因为静态Font Asset里没有包含那些可能出现的生僻字，我们为输入框单独使用了系统回退方案，并限制只能输入中文和数字。如果你也要做类似功能，建议提前把需要的字符集范围扩大，而不是等用户输入了再说。

这次实战还发现一个容易忽略的问题：工程里如果用了老版本的Addressables，WebGL构建时会产生额外的aa文件夹，里面包含很多未压缩或已经打包的资源。如果把它部署上去，会让整个构建包变得凌乱，还容易加载到旧版本。后来我们把Addressables升级到较新版本，并用Build for WebGL专用配置重新构建了一次，资源加载才算干净。

6. 完整速查表：错误现象、根因与解法

为了让你在紧急排障时能直接抄答案，我把这段时间处理过的WebGL发布问题整理成一张速查表。它不算万能，但覆盖了90%的日常场景。

我在实际发布中还有一个体会：不要等到开发完了再想WebGL兼容。项目一开始就确定目标平台是WebGL，纹理、字体、加载方式都按WebGL的标准来设计，后面发布会轻松非常多。反过来，如果项目已经做完了再回头改，那才是真的“项目时间不够，避坑指南来凑”。

最后再分享一个排查小技巧：每次构建后，把生成的Build文件夹以Zip形式保留一份，记录构建当时的Unity版本、代码分支、Player Settings截图。这样一旦线上出问题，你能快速回滚到上一次可用的包，而不是在服务器上反复上传覆盖试错。发布WebGL本身不难，难的是它把所有平台差异一次性摊在你面前。把这些坑挨个填平之后，再遇到类似问题你也能一眼看穿。