做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项目里遇到的典型问题几乎都可以归到这几类症状直接原因常见阶段页面打开后白屏控制台报内存越界WebGL内存设置太小或某个资源加载暴涨打开中/运行时UI里的中文全部显示成方块或问号字体没有随包打包或使用的字体不包含中文字形首次加载UI后字体重影、发虚、边缘模糊动态字体在WebGL里被替换或者TextMeshPro图集分辨率不足界面显示时本地双击index.html正常部署服务器后加载极慢服务端没有正确返回Content-Encoding压缩头部署后使用AssetBundle/WebRequest加载时报跨域错误CDN或API服务缺少CORS响应头接口请求时构建包几个GB浏览器加载到天荒地老未裁剪引擎代码、纹理未压缩、场景资源过多构建后这些坑单独拿出来都不难解决但当你同时面对五六个问题时就很容易陷入“解决一个又冒出一个”的循环。所以下面几节按主题拆开讲每部分都会给出可复用的参数和步骤。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转向TextMeshProTMP。TMP会把字体生成为一张包含字形信息的图集Font Atlas构建时随场景一起打包不依赖运行时系统字体天然适配WebGL的离线渲染模式。具体的打包流程我整理成五步准备一个中文字体文件推荐思源黑体Source Han Sans或阿里巴巴普惠体文件格式用.ttf或.otf。注意字体文件越完整可能生成的图集越大后续要做子集优化。在Project窗口导入字体文件右键选择“Create TextMeshPro Font Asset”。如果菜单里没有可以先创建TMP Settings资源并指定默认字体列表。选中新生成的Font Asset在Inspector里把Atlas Resolution调到2048或4096Sampling Point Size设置好保证字形在小字号下也不发虚。关键的一步设置Character Set。TMP默认的“Character Set”可能只包含ASCII或Basic Latin中文全没进去。需要改成“Unicode Range (Hex)”手动填入你要支持的Unicode范围比如中文字符区段4E00-9FA5或者直接使用“Characters from File”加载一个文本文件把项目UI涉及到的中文都放进去。把所有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里如果开了DynamicUnity会把它当成动态字体处理运行时仍可能尝试从系统加载字形。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设成2048Character 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里没有包含那些可能出现的生僻字我们为输入框单独使用了系统回退方案并限制只能输入中文和数字。如果你也要做类似功能建议提前把需要的字符集范围扩大而不是等用户输入了再说。这次实战还发现一个容易忽略的问题工程里如果用了老版本的AddressablesWebGL构建时会产生额外的aa文件夹里面包含很多未压缩或已经打包的资源。如果把它部署上去会让整个构建包变得凌乱还容易加载到旧版本。后来我们把Addressables升级到较新版本并用Build for WebGL专用配置重新构建了一次资源加载才算干净。6. 完整速查表错误现象、根因与解法为了让你在紧急排障时能直接抄答案我把这段时间处理过的WebGL发布问题整理成一张速查表。它不算万能但覆盖了90%的日常场景。错误现象根因解法白屏Console报“memory access out of bounds”WebGL内存设置不足以容纳当前资源峰值调高WebGL Memory Size压纹理并关闭Mipmap白屏构建包在本地打开正常服务器上加载失败服务器未正确返回压缩头/MIMENginx开启gzip_static/brotli_static配置wasm MIMEUI中文显示方块/问号字体资源未打包或字体不含中文导入中文字体改用TMP静态字体并设置字符集中文显示正常但发虚TMP Atlas分辨率不足或字号太小时采样点不够提高Atlas Resolution调整Sampling Point Size动态输入的字符显示不出来静态Font Asset未包含目标字形扩大字符集范围或限制输入字符种类加载到100%后卡住Unity Loader没拿到WASM的响应头检查服务器是否正确返回application/wasm页面在Chrome能跑Firefox崩溃浏览器对WebGL版本或编码支持差异升级Unity版本检查Build时WebGL支持2.0/3.0WebGL请求外部接口报CORS目标服务未开启CORS在API/CDN服务器上添加Access-Control-Allow-Origin头构建包体积过大贴图未压缩、未裁剪引擎代码开启Strip Engine Code压缩纹理使用AssetBundle我在实际发布中还有一个体会不要等到开发完了再想WebGL兼容。项目一开始就确定目标平台是WebGL纹理、字体、加载方式都按WebGL的标准来设计后面发布会轻松非常多。反过来如果项目已经做完了再回头改那才是真的“项目时间不够避坑指南来凑”。最后再分享一个排查小技巧每次构建后把生成的Build文件夹以Zip形式保留一份记录构建当时的Unity版本、代码分支、Player Settings截图。这样一旦线上出问题你能快速回滚到上一次可用的包而不是在服务器上反复上传覆盖试错。发布WebGL本身不难难的是它把所有平台差异一次性摊在你面前。把这些坑挨个填平之后再遇到类似问题你也能一眼看穿。 
长河君 · 2026/9/19 3:18:06 · 阅读 1.2k Unity WebGL发布避坑指南：内存设置、字体打包与服务器配置详解
做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项目里遇到的典型问题几乎都可以归到这几类症状直接原因常见阶段页面打开后白屏控制台报内存越界WebGL内存设置太小或某个资源加载暴涨打开中/运行时UI里的中文全部显示成方块或问号字体没有随包打包或使用的字体不包含中文字形首次加载UI后字体重影、发虚、边缘模糊动态字体在WebGL里被替换或者TextMeshPro图集分辨率不足界面显示时本地双击index.html正常部署服务器后加载极慢服务端没有正确返回Content-Encoding压缩头部署后使用AssetBundle/WebRequest加载时报跨域错误CDN或API服务缺少CORS响应头接口请求时构建包几个GB浏览器加载到天荒地老未裁剪引擎代码、纹理未压缩、场景资源过多构建后这些坑单独拿出来都不难解决但当你同时面对五六个问题时就很容易陷入“解决一个又冒出一个”的循环。所以下面几节按主题拆开讲每部分都会给出可复用的参数和步骤。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转向TextMeshProTMP。TMP会把字体生成为一张包含字形信息的图集Font Atlas构建时随场景一起打包不依赖运行时系统字体天然适配WebGL的离线渲染模式。具体的打包流程我整理成五步准备一个中文字体文件推荐思源黑体Source Han Sans或阿里巴巴普惠体文件格式用.ttf或.otf。注意字体文件越完整可能生成的图集越大后续要做子集优化。在Project窗口导入字体文件右键选择“Create TextMeshPro Font Asset”。如果菜单里没有可以先创建TMP Settings资源并指定默认字体列表。选中新生成的Font Asset在Inspector里把Atlas Resolution调到2048或4096Sampling Point Size设置好保证字形在小字号下也不发虚。关键的一步设置Character Set。TMP默认的“Character Set”可能只包含ASCII或Basic Latin中文全没进去。需要改成“Unicode Range (Hex)”手动填入你要支持的Unicode范围比如中文字符区段4E00-9FA5或者直接使用“Characters from File”加载一个文本文件把项目UI涉及到的中文都放进去。把所有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里如果开了DynamicUnity会把它当成动态字体处理运行时仍可能尝试从系统加载字形。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设成2048Character 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里没有包含那些可能出现的生僻字我们为输入框单独使用了系统回退方案并限制只能输入中文和数字。如果你也要做类似功能建议提前把需要的字符集范围扩大而不是等用户输入了再说。这次实战还发现一个容易忽略的问题工程里如果用了老版本的AddressablesWebGL构建时会产生额外的aa文件夹里面包含很多未压缩或已经打包的资源。如果把它部署上去会让整个构建包变得凌乱还容易加载到旧版本。后来我们把Addressables升级到较新版本并用Build for WebGL专用配置重新构建了一次资源加载才算干净。6. 完整速查表错误现象、根因与解法为了让你在紧急排障时能直接抄答案我把这段时间处理过的WebGL发布问题整理成一张速查表。它不算万能但覆盖了90%的日常场景。错误现象根因解法白屏Console报“memory access out of bounds”WebGL内存设置不足以容纳当前资源峰值调高WebGL Memory Size压纹理并关闭Mipmap白屏构建包在本地打开正常服务器上加载失败服务器未正确返回压缩头/MIMENginx开启gzip_static/brotli_static配置wasm MIMEUI中文显示方块/问号字体资源未打包或字体不含中文导入中文字体改用TMP静态字体并设置字符集中文显示正常但发虚TMP Atlas分辨率不足或字号太小时采样点不够提高Atlas Resolution调整Sampling Point Size动态输入的字符显示不出来静态Font Asset未包含目标字形扩大字符集范围或限制输入字符种类加载到100%后卡住Unity Loader没拿到WASM的响应头检查服务器是否正确返回application/wasm页面在Chrome能跑Firefox崩溃浏览器对WebGL版本或编码支持差异升级Unity版本检查Build时WebGL支持2.0/3.0WebGL请求外部接口报CORS目标服务未开启CORS在API/CDN服务器上添加Access-Control-Allow-Origin头构建包体积过大贴图未压缩、未裁剪引擎代码开启Strip Engine Code压缩纹理使用AssetBundle我在实际发布中还有一个体会不要等到开发完了再想WebGL兼容。项目一开始就确定目标平台是WebGL纹理、字体、加载方式都按WebGL的标准来设计后面发布会轻松非常多。反过来如果项目已经做完了再回头改那才是真的“项目时间不够避坑指南来凑”。最后再分享一个排查小技巧每次构建后把生成的Build文件夹以Zip形式保留一份记录构建当时的Unity版本、代码分支、Player Settings截图。这样一旦线上出问题你能快速回滚到上一次可用的包而不是在服务器上反复上传覆盖试错。发布WebGL本身不难难的是它把所有平台差异一次性摊在你面前。把这些坑挨个填平之后再遇到类似问题你也能一眼看穿。