Unity WebGL模型导出GLB文件：三种实战方案与jslib插件实现

1. 项目概述：当Unity WebGL遇上模型导出

如果你做过Unity WebGL项目，肯定遇到过这个头疼的问题：用户想在网页里把3D模型保存到自己的电脑上，你却束手无策。这不像在PC或移动端，直接调用System.IO.File.WriteAllBytes就能搞定。WebGL运行在浏览器的沙箱环境里，出于安全考虑，它被严格限制了对本地文件系统的直接访问。用户下载一个文件，通常只能依赖浏览器提供的下载对话框。

但需求是实实在在的。无论是让用户下载他们自定义的角色模型、保存场景编辑的成果，还是导出用于3D打印的资产，将模型数据从WebGL应用导出到本地都是一个刚需。GLB格式，作为glTF的二进制版本，因其将几何、材质、纹理甚至动画打包进单个文件的特性，成为了Web端3D模型交换的事实标准。它结构紧凑，解析高效，被Three.js、Babylon.js等主流引擎广泛支持，自然也是从Unity WebGL导出的理想选择。

今天，我们就来彻底解决这个问题。我将分享三种经过实战检验的、将Unity WebGL中的模型导出为GLB文件到本地的实用方法，并附上可直接复用的完整jslib插件代码。这三种方法各有侧重，从最基础的浏览器自动下载，到应对大文件的“分而治之”，再到追求极致用户体验的“无感”保存，覆盖了不同场景下的需求。无论你是Unity开发者刚刚涉足WebGL，还是正在为某个棘手的导出功能寻找方案，这篇文章都能给你清晰的路径和可落地的代码。

2. 核心思路与方案选型：为什么是这三种方法？

在WebGL中实现文件导出，本质上是如何将C#脚本中的二进制数据“递”给浏览器，并触发下载流程。Unity通过Plugins目录下的.jslib（JavaScript Library）文件，为我们提供了调用原生JavaScript能力的桥梁。我们的所有方案都将围绕这个核心展开。

方案选型并非拍脑袋决定，而是基于文件大小、浏览器兼容性、用户体验和实现复杂度四个维度的综合考量。盲目选择一种方法，可能会在遇到大文件时导致浏览器卡死，或者在iOS Safari上完全失效。

方案一：Blob URL + 锚点下载这是最经典、兼容性最广的方法。其原理是，在JavaScript中，我们可以用二进制数据创建一个Blob对象，然后通过URL.createObjectURL为其生成一个临时的URL。这个URL可以直接赋值给一个隐藏的<a>标签的href属性，并设置其download属性为文件名。最后，程序触发这个链接的点击事件，浏览器就会弹出下载对话框。这种方法几乎适用于所有现代浏览器，实现简单直观，是处理中小型文件（建议小于100MB）的首选。它的缺点是会弹出标准的下载对话框，并且对于超大文件，创建巨大的Blob对象可能会消耗大量内存。

方案二：文件流式写入（File System Access API）这是面向未来的现代方法，尤其适合处理大型模型文件。传统的Blob方式需要将整个文件内容一次性加载到内存中，而File System Access API允许我们以“流”的方式，像在本地磁盘上一样，分块将数据写入用户选择的文件。这极大地降低了大文件导出时的内存峰值压力，避免了浏览器标签页崩溃的风险。此外，它提供了更精细的控制，允许用户选择保存位置，甚至在未来访问同一文件。然而，它的主要限制在于浏览器兼容性，目前主要在基于Chromium的浏览器（如Chrome、Edge）中得到较好支持，Firefox和Safari的支持尚不完整或需标记启用。

方案三：Base64数据URL与图片伪装下载这是一种有趣的“曲线救国”方法，其核心目的是绕过某些极端环境下的限制（例如一些非常严格的内部网页容器，或需要兼容极老版本的场景）。它将二进制GLB数据通过btoa编码成Base64字符串，然后将其作为data:URL的一部分。更有技巧性的一步是，我们可以不直接触发文件下载，而是将这个Data URL赋值给一个<img>标签的src，再通过右键“图片另存为”的方式，让用户手动保存一个文件。当然，我们也可以通过JavaScript创建一个链接来触发下载，但Data URL有长度限制。这种方法兼容性极高，但效率最低（Base64编码会使数据体积膨胀约33%），且交互方式不够友好，通常仅作为前两种方法失效时的备选方案或特定场景下的技巧。

选择哪种方法？我的建议是：优先实现方案一，因为它覆盖了最广泛的用户；对于明确需要处理超大模型（如精细的建筑BIM模型、高精度扫描资产）的项目，同时实现方案二作为增强体验；将方案三的代码作为备用工具函数，以备不时之需。

3. 核心工具解析：jslib插件的工作原理与编写

.jslib文件是Unity WebGL与JavaScript世界通信的关键。它不是一个普通的脚本，而是一个遵循特定格式的接口声明文件。Unity在编译WebGL时，会将这些声明与实际的JavaScript实现（通常内联或通过mergeInto指令注入）进行绑定，从而在C#中可以通过[DllImport(“__Internal”)]来调用这些“外部”函数。

一个典型的jslib文件结构如下：

mergeInto(LibraryManager.library, { // 声明一个供C#调用的函数 YourPluginFunction: function (dataPtr, dataLength, filenamePtr) { // 函数实现... }, });

• mergeInto(LibraryManager.library, {...}): 这是固定语法，用于将我们定义的函数注入到Unity的运行时库中。
• YourPluginFunction: 这是函数名，在C#中需要通过完全相同的名称来调用。
• 参数：函数参数通常用于从C#传递数据。Unity WebGL中的C#与JavaScript不直接共享内存。因此，我们通常传递一个指向C#托管堆中数据数组的指针(dataPtr)和数据的长度(dataLength)，以及一个指向文件名字符串的指针(filenamePtr)。在JavaScript端，我们需要使用Unity提供的辅助函数来“解码”这些指针。

关键JavaScript辅助函数：

• Pointer_stringify(ptr): 将C#传递过来的字符串指针(System.IntPtr)转换为JavaScript字符串。这是我们获取文件名等文本信息的必备工具。
• HEAPU8: 这是一个Uint8Array视图，直接映射到Unity WebGL应用的线性内存（堆）。通过HEAPU8.buffer可以获取底层的ArrayBuffer。结合指针偏移量(dataPtr)和长度(dataLength)，我们可以用HEAPU8.slice(dataPtr, dataPtr + dataLength)来提取出C#传递过来的二进制数据块，而无需拷贝整个内存，效率极高。

从C#到JS的数据传递流程：

1. C#端：准备一个字节数组byte[] data，其中包含了编码好的GLB文件数据。
2. C#端：通过[DllImport(“__Internal”)]声明外部函数，例如SaveFile(IntPtr data, int dataLength, string filename)。
3. 调用时：C#需要将字节数组“固定”在内存中（使用GCHandle），获取其指针，然后调用JavaScript函数。这是因为WebGL中C#运行在编译为WebAssembly的Mono/IL2CPP运行时中，其内存与JavaScript内存是隔离的。传递指针是跨越这道边界传递大量数据的标准方式。
4. JS端：SaveFile函数接收到指针和长度后，使用HEAPU8.slice从Unity的堆内存中“取出”对应的二进制数据，生成一个JavaScript端的Uint8Array。
5. JS端：利用这个Uint8Array，执行我们之前选定的方案（创建Blob、调用File System API等），最终触发浏览器下载。

注意：内存管理与GCHandle这是一个至关重要的细节，也是新手最容易踩坑的地方。在C#中，垃圾回收器（GC）可能会移动内存中的对象。如果你获取了一个字节数组的指针，然后GC在调用JavaScript函数前移动了这个数组，指针就失效了，会导致读取到错误数据甚至崩溃。因此，必须使用GCHandle.Alloc(data, GCHandleType.Pinned)来“固定”字节数组，确保其在调用期间不会被GC移动。调用完毕后，务必调用GCHandle.Free()来释放固定，避免内存泄漏。

理解了这些，我们就能写出健壮、高效的jslib代码了。接下来，我们将进入三种方法的具体实现环节。

4. 方法一实现：Blob URL与锚点触发下载（兼容性之王）

这是最推荐首先实现的方法，稳定、可靠，能满足绝大多数情况。我们将创建一个完整的FileSaver.jslib插件。

第一步：创建jslib插件在你的Unity项目Assets文件夹下，创建Plugins/WebGL目录（如果不存在就新建），然后在该目录下创建一个名为FileSaver.jslib的文本文件，并输入以下完整代码：

mergeInto(LibraryManager.library, { // 方法一：使用Blob和Object URL进行下载 SaveFileAsBlob: function (dataPtr, dataLength, filenamePtr) { // 1. 从Unity内存中获取二进制数据和文件名 var dataArray = new Uint8Array(HEAPU8.buffer, dataPtr, dataLength); var filename = Pointer_stringify(filenamePtr); // 2. 创建Blob对象 var blob = new Blob([dataArray], { type: 'application/octet-stream' }); // 3. 创建Object URL var url = URL.createObjectURL(blob); // 4. 创建隐藏的<a>标签并触发点击 var a = document.createElement('a'); a.style.display = 'none'; a.href = url; a.download = filename; // 设置下载的文件名 document.body.appendChild(a); // 必须添加到DOM中，某些浏览器需要 a.click(); // 5. 清理：移除链接和释放Object URL setTimeout(function () { document.body.removeChild(a); URL.revokeObjectURL(url); // 释放内存 }, 100); }, });

代码逐行解析与注意事项：

1. var dataArray = new Uint8Array(HEAPU8.buffer, dataPtr, dataLength);：这是核心操作。它并没有复制数据，而是直接在Unity的堆内存HEAPU8.buffer上，从偏移量dataPtr开始，创建了一个长度为dataLength的Uint8Array视图。这非常高效。
2. var blob = new Blob([dataArray], { type: 'application/octet-stream' });：将Uint8Array包装成Blob。‘application/octet-stream’是通用的二进制流类型，适合GLB文件。你也可以指定为‘model/gltf-binary’，但通用类型兼容性更好。
3. URL.createObjectURL(blob)：为Blob生成一个本地URL（形如blob:https://yourdomain.com/xxx-xxx）。这个URL只在当前页面会话中有效。
4. a.click()：通过编程方式触发链接点击，弹出浏览器下载对话框。download属性告诉浏览器下载文件而非导航到URL。
5. 清理工作至关重要：生成Object URL会占用内存，必须在使用后通过URL.revokeObjectURL(url)释放。我们将清理放在setTimeout中，确保下载对话框已弹出后再执行。同时，从DOM中移除创建的<a>标签也是一个好习惯。

第二步：编写C#调用脚本在Unity中创建一个C#脚本，例如GLBExporter.cs。

using System; using System.IO; using System.Runtime.InteropServices; using UnityEngine; public class GLBExporter : MonoBehaviour { // 导入jslib中定义的函数 [DllImport("__Internal")] private static extern void SaveFileAsBlob(IntPtr data, int dataLength, string filename); /// <summary> /// 将字节数组保存为文件（WebGL平台） /// </summary> /// <param name="data">GLB文件数据</param> /// <param name="filename">建议的文件名，如"model.glb"</param> public void ExportGLBData(byte[] data, string filename) { if (!Application.isEditor && Application.platform == RuntimePlatform.WebGLPlayer) { // WebGL平台：使用jslib ExportForWebGL(data, filename); } else { // 其他平台（如PC、Mac）：使用System.IO直接保存，方便测试 Debug.LogWarning("非WebGL平台，使用本地文件系统保存。保存路径: " + Application.persistentDataPath); try { File.WriteAllBytes(Path.Combine(Application.persistentDataPath, filename), data); Debug.Log("文件保存成功: " + filename); } catch (Exception e) { Debug.LogError("文件保存失败: " + e.Message); } } } /// <summary> /// WebGL平台专用的导出逻辑 /// </summary> private void ExportForWebGL(byte[] data, string filename) { // 关键步骤：固定字节数组，防止GC移动内存 GCHandle dataHandle = GCHandle.Alloc(data, GCHandleType.Pinned); try { IntPtr dataPtr = dataHandle.AddrOfPinnedObject(); SaveFileAsBlob(dataPtr, data.Length, filename); } finally { // 确保无论如何都会释放GCHandle if (dataHandle.IsAllocated) dataHandle.Free(); } } // 示例方法：假设你已经有一个GameObject，将其转换为GLB字节数据 public void ExportCurrentModel(GameObject targetGameObject, string filename) { // 注意：Unity本身不提供直接的GLB导出API，这里需要借助第三方库。 // 例如，可以使用UnityGLTF（https://github.com/KhronosGroup/UnityGLTF） // 以下为伪代码，展示调用流程 /* byte[] glbData = ConvertGameObjectToGLB(targetGameObject); // 调用第三方库的转换函数 if (glbData != null && glbData.Length > 0) { ExportGLBData(glbData, filename); } else { Debug.LogError("GLB数据转换失败。"); } */ Debug.Log("请集成如UnityGLTF等库来实现GameObject到GLB的转换。"); } }

C#脚本关键点解析：

1. [DllImport(“__Internal”)]: 这行代码告诉Unity，SaveFileAsBlob函数实现在外部（即我们的.jslib文件）中。
2. GCHandle的使用：这是安全传递数据到WebGL环境的黄金法则。GCHandle.Alloc(data, GCHandleType.Pinned)锁定了字节数组在内存中的位置，AddrOfPinnedObject()获取其起始地址（指针）。在try-finally块中确保即使发生异常，GCHandle也能被释放，避免内存泄漏。
3. 平台判断：通过Application.platform区分WebGL和其他平台，为不同平台提供相应的实现，方便在编辑器中进行逻辑测试（直接写入Application.persistentDataPath）。

第三步：测试与使用

1. 将GLBExporter脚本挂载到场景中某个GameObject上。
2. 在需要导出的地方（如UI按钮点击事件），获取GLB字节数据并调用exporter.ExportGLBData(glbBytes, “my_model.glb”)。
3. 构建WebGL项目并部署到服务器或用本地服务器（如http-server）运行。
4. 点击导出按钮，浏览器应弹出下载对话框。

实操心得：文件名与中文问题在WebGL下载中，如果文件名包含中文，在某些浏览器上可能会出现乱码。一个更稳健的做法是，在C#端对文件名进行URL编码，在JavaScript端再解码。例如，C#传递Uri.EscapeDataString(filename)，JS端使用decodeURIComponent(filename)。此外，确保文件名包含正确的扩展名.glb，这能帮助浏览器和操作系统正确识别文件类型。

5. 方法二实现：文件流式写入API（大文件救星）

对于动辄数百MB甚至上GB的精细模型，方法一可能会让浏览器标签页因内存耗尽而崩溃。File System Access API的流式写入能力是解决此问题的利器。我们在同一个FileSaver.jslib文件中添加新函数。

更新FileSaver.jslib：

mergeInto(LibraryManager.library, { // ... 保留之前的SaveFileAsBlob函数 ... // 方法二：使用File System Access API进行流式保存（处理大文件） SaveFileWithStream: function (dataPtr, dataLength, filenamePtr) { var filename = Pointer_stringify(filenamePtr); // 检查浏览器是否支持该API if (!('showSaveFilePicker' in window)) { console.error('当前浏览器不支持File System Access API。将回退到Blob方法。'); // 可以在这里调用SaveFileAsBlob作为降级方案 // 为了示例清晰，这里仅打印错误。实际应用中应实现优雅降级。 return; } // 由于API调用是异步的，我们需要返回一个Promise，并通过Unity的SendMessage通知C#结果 // 这里我们简化处理，直接在主线程中尝试（注意：showSaveFilePicker必须在用户手势触发下调用） (async () => { try { // 1. 让用户选择保存位置 const fileHandle = await window.showSaveFilePicker({ suggestedName: filename, types: [{ description: 'GLB Model File', accept: { 'model/gltf-binary': ['.glb'] }, }], }); // 2. 创建可写流 const writableStream = await fileHandle.createWritable(); // 3. 从Unity内存获取数据并写入流 // 注意：对于超大文件，这里可以分块读取HEAPU8并写入，避免一次性占用过多内存。 // 本例假设数据量在可控范围内，一次性写入。 var dataArray = new Uint8Array(HEAPU8.buffer, dataPtr, dataLength); await writableStream.write(dataArray); // 4. 关闭流，完成写入 await writableStream.close(); console.log('文件已通过流式API保存。'); // 可以在这里通过UnityEngine.Debug.Log转发消息到Unity控制台 // unityInstance.SendMessage('GameObjectName', 'MethodName', 'Success'); } catch (err) { // 用户取消了选择器，或其他错误 if (err.name !== 'AbortError') { console.error('文件保存失败:', err); } } })(); }, });

流式API的优势与注意事项：

1. 异步操作：showSaveFilePicker和文件写入都是异步的，因此我们的函数主体被包裹在一个立即执行的异步函数(async () => { ... })()中。这意味着函数调用会立即返回，不会阻塞Unity主线程。
2. 用户手势：showSaveFilePicker必须由用户交互（如点击）直接触发，否则浏览器会拒绝并抛出安全错误。确保你的导出按钮直接调用这个函数。
3. 内存友好：即使我们示例中一次性写入了数据，该API的本质支持流式处理。对于超大规模数据，你可以在循环中分片读取HEAPU8（例如每次读取1MB），并调用writableStream.write(chunk)，从而将内存占用控制在很小范围内。
4. 回退方案：务必检查API支持情况(if (!('showSaveFilePicker' in window)))。在不支持的浏览器上，必须优雅地降级到方法一（Blob）。在实际代码中，你应该在C#端或JS端实现这个判断逻辑。

对应的C#调用代码：在GLBExporter.cs中增加一个新的导出方法。

[DllImport("__Internal")] private static extern void SaveFileWithStream(IntPtr data, int dataLength, string filename); public void ExportGLBDataStreaming(byte[] data, string filename) { if (!Application.isEditor && Application.platform == RuntimePlatform.WebGLPlayer) { GCHandle dataHandle = GCHandle.Alloc(data, GCHandleType.Pinned); try { IntPtr dataPtr = dataHandle.AddrOfPinnedObject(); SaveFileWithStream(dataPtr, data.Length, filename); // 注意：这是一个异步调用，C#这里无法直接获取成功/失败状态。 // 需要通过JS回调（如使用unityInstance.SendMessage）来通知Unity。 } finally { if (dataHandle.IsAllocated) dataHandle.Free(); } } else { // 非WebGL平台，降级为普通文件写入 ExportGLBData(data, filename); } }

重要提示：异步回调方法二的JavaScript部分是异步的，保存成功或失败的信息无法直接通过函数返回值告诉C#。为了实现状态反馈，你需要在.jslib函数成功或捕获错误时，使用unityInstance.SendMessage('GameObjectName', 'MethodName', 'message')来调用C#脚本中的一个方法，从而在Unity中弹出UI提示或进行日志记录。这是提升用户体验的关键一步。

6. 方法三实现：Base64 Data URL与备用方案

这种方法通常不作为首选，但在某些“奇葩”环境下可能是唯一的出路。我们将它实现为一个工具函数，添加到jslib中。

继续更新FileSaver.jslib：

mergeInto(LibraryManager.library, { // ... 保留之前的SaveFileAsBlob和SaveFileWithStream函数 ... // 方法三：生成Data URL（通常用于备用或特殊场景，如需要内联显示非常小的文件） GetFileAsDataURL: function (dataPtr, dataLength, mimeTypePtr) { var dataArray = new Uint8Array(HEAPU8.buffer, dataPtr, dataLength); var mimeType = Pointer_stringify(mimeTypePtr) || 'application/octet-stream'; // 将二进制数据转换为Base64字符串 var binaryString = ''; for (var i = 0; i < dataArray.length; i++) { binaryString += String.fromCharCode(dataArray[i]); } var base64Data = btoa(binaryString); // 构建Data URL var dataUrl = 'data:' + mimeType + ';base64,' + base64Data; // 返回Data URL字符串的长度和指针？在WebGL的简单绑定中，直接返回字符串比较复杂。 // 更常见的做法是：1) 通过SendMessage传回Unity。2) 或直接用于前端操作（如赋值给img.src）。 // 这里我们演示如何通过一个全局变量或直接控制台输出，实际应用需根据情况调整。 console.log('Data URL generated (first 100 chars):', dataUrl.substring(0, 100) + '...'); // 假设我们通过一个全局函数将其设置到页面的某个元素上，供用户手动右键保存 if (typeof window.setGeneratedDataURL === 'function') { window.setGeneratedDataURL(dataUrl); } // 注意：此函数不直接触发下载。Data URL有长度限制（因浏览器而异），不适合大文件。 }, // 一个基于Data URL触发下载的变体（同样有大小限制） SaveFileAsDataURL: function (dataPtr, dataLength, filenamePtr) { var dataArray = new Uint8Array(HEAPU8.buffer, dataPtr, dataLength); var filename = Pointer_stringify(filenamePtr); var binaryString = ''; var chunkSize = 0x8000; // 32KB chunks，避免循环拼接超大字符串时卡死 for (var i = 0; i < dataArray.length; i += chunkSize) { var chunk = dataArray.subarray(i, i + chunkSize); binaryString += String.fromCharCode.apply(null, chunk); } var base64Data = btoa(binaryString); var dataUrl = 'data:application/octet-stream;base64,' + base64Data; var a = document.createElement('a'); a.style.display = 'none'; a.href = dataUrl; a.download = filename; document.body.appendChild(a); a.click(); setTimeout(function() { document.body.removeChild(a); }, 100); } });

Base64方案的局限性与技巧：

1. 体积膨胀与性能：Base64编码会使数据体积增加约33%。对于几MB的模型尚可接受，超过10MB就可能遇到性能问题和浏览器URL长度限制。
2. 字符串转换：将Uint8Array转换为Base64字符串是一个相对耗时的CPU密集型操作，对于大文件会阻塞主线程，导致页面暂时无响应。上述代码使用了分块处理(chunkSize)来稍微缓解，但根本问题仍在。
3. 使用场景：GetFileAsDataURL更适合生成一个用于预览的、非常小的模型数据URL（例如，嵌入到<img>标签，但GLB不是图片，此例仅为说明）。SaveFileAsDataURL则尝试直接触发下载，但其可靠性低于Blob方案。
4. 终极备胎：只有当Blob和File System API都不可用时，才考虑此方案。一种可能的用法是，先尝试方法一，如果失败（例如在某些旧版Edge或特定嵌入式浏览器中），捕获错误并回退到方法三。

7. 实战集成：从Unity场景到GLB字节流

到目前为止，我们解决了“如何把字节数组从WebGL送到用户硬盘”的问题。但前提是，你得先有这个字节数组——即GLB格式的模型数据。Unity原生并不支持导出GLB，因此我们需要借助第三方库。这里以目前最主流、由Khronos Group（glTF标准制定者）维护的UnityGLTF库为例，简述集成和导出流程。

步骤一：获取UnityGLTF

1. 访问 UnityGLTF的GitHub仓库 。
2. 按照其README说明，通常可以通过Unity的Package Manager添加Git URL，或下载源码放入项目的Assets文件夹。

步骤二：编写GLB导出逻辑创建一个新的C#脚本GLBRuntimeExporter.cs，负责调用UnityGLTF的接口。

using UnityEngine; using UnityGLTF; // 引入UnityGLTF命名空间 using System.IO; using System; public class GLBRuntimeExporter : MonoBehaviour { public GLBExporter blobExporter; // 挂载了前面编写的GLBExporter脚本的物体 /// <summary> /// 将指定GameObject及其子物体导出为GLB字节数据 /// </summary> public byte[] ExportGameObjectToGLB(GameObject rootGameObject) { if (rootGameObject == null) { Debug.LogError("导出的根物体不能为空。"); return null; } byte[] glbData = null; try { // 1. 创建GLTF导出器实例 // 注意：UnityGLTF的具体API可能随版本变化，请查阅其最新文档 var exportOptions = new ExportOptions(); // 配置导出选项，如是否导出动画、纹理格式等 exportOptions.TexturePathRetriever = null; // 运行时导出，通常不依赖外部纹理路径 var exporter = new GLTFExporter(new[] { rootGameObject.transform }, exportOptions); // 2. 将场景数据保存到GLTF对象（内存中） var gltf = exporter.SaveGLTF(); // 3. 将GLTF对象序列化为GLB格式的字节数组 // 这里假设GLTFExporter或相关工具类有一个SaveGLBToByteArray方法 // 实际可能需要使用GLTF.ExportGLB(gltf)或其他静态方法 // 以下为示例伪代码，具体方法名请参考UnityGLTF源码 // glbData = GLTF.ExportGLB(gltf); // 由于UnityGLTF的运行时导出API可能封装得不够直接，另一种常见做法是： // 使用其`GLTFSceneExporter`类，并重写其文件写入方法，将数据写入内存流。 Debug.LogWarning("请根据使用的UnityGLTF版本，查找正确的运行时GLB字节数组导出方法。"); // 示例思路：继承GLTFSceneExporter，重写WriteToDisk等方法，将数据导入MemoryStream。 } catch (Exception e) { Debug.LogError($"导出GLB过程中发生错误: {e.Message}\n{e.StackTrace}"); return null; } return glbData; } /// <summary> /// 一键导出按钮调用的方法 /// </summary> public void ExportSelectedModel() { // 假设你要导出当前选中的物体 GameObject modelToExport = Selection.activeGameObject; // 或在Inspector中拖拽赋值 if (modelToExport == null) { Debug.LogWarning("请先选择一个GameObject进行导出。"); return; } byte[] glbBytes = ExportGameObjectToGLB(modelToExport); if (glbBytes != null && glbBytes.Length > 0) { string filename = $"{modelToExport.name}_{DateTime.Now:yyyyMMddHHmmss}.glb"; // 调用我们之前写好的WebGL导出器 if (blobExporter != null) { blobExporter.ExportGLBData(glbBytes, filename); } else { Debug.LogError("未指定GLBExporter实例。"); } } else { Debug.LogError("GLB数据生成失败。"); } } }

关键难点与注意事项：

• 运行时导出：UnityGLTF库的设计可能更侧重于编辑器下的导出功能。在运行时（WebGL构建后）将场景动态转换为GLB字节流，可能需要你深入研究其源码，找到或自行实现将GLTFRoot对象写入MemoryStream而非物理文件的方法。这可能涉及修改或扩展库的代码。
• 纹理处理：如果模型包含自定义材质和纹理，你需要确保这些纹理在运行时是可访问的，并且导出器能正确地将它们打包进GLB文件（通常是Base64编码嵌入或作为二进制缓冲视图）。这比导出纯几何体要复杂得多。
• 性能考量：复杂的模型导出是CPU密集型操作，在WebGL的单线程环境中可能导致帧率下降。考虑在后台线程（Web Worker）中进行导出，但这在Unity WebGL中实现起来较为复杂。一个更简单的方法是显示一个“正在导出...”的加载提示，管理好用户的预期。

8. 常见问题、排查技巧与优化实录

在实际开发和测试中，你几乎一定会遇到下面这些问题。这里是我踩过坑后总结的排查清单和解决方案。

问题1：点击导出按钮，没有任何反应，浏览器控制台也没有错误。

• 排查：首先检查C#代码中的GCHandle是否被正确释放？如果GCHandle在函数执行完毕前就被释放了，JS端读取的内存区域可能无效。确保在try-finally块中释放。
• 排查：检查构建后的HTML页面中，是否确实包含了你的.jslib文件。查看浏览器开发者工具的“Sources”标签，在“Build”目录下寻找你的.jslib文件内容是否被正确合并。
• 排查：在jslib函数的开头加一句console.log(‘JS function called!’)，看是否被触发。如果没有，说明C#到JS的绑定可能失败了，检查函数名是否完全一致，包括大小写。

问题2：文件可以下载，但下载下来的GLB文件损坏，无法用查看器打开。

• 排查：这是最常见的问题。首先，确认你生成的GLB字节数据本身是正确的。在非WebGL平台（如编辑器下）用File.WriteAllBytes保存这个字节数组，然后用专业的GLB查看器（如Windows 3D查看器、VSCode的glTF Tools插件）打开测试。如果这里就损坏了，问题出在GLB生成环节（UnityGLTF的使用）。
• 排查：如果桌面端正常，WebGL端损坏，问题很可能出在数据传递过程。检查jslib中从HEAPU8提取数据的代码。确保dataPtr和dataLength是正确的。一个有用的调试方法是，在JS端将接收到的dataArray的前几个字节和长度打印到控制台，与C#端发送前的字节数组进行对比。
• 排查：Blob的MIME类型。虽然application/octet-stream是安全的，但尝试使用model/gltf-binary看看。

问题3：导出大文件（>50MB）时，浏览器卡死或崩溃。

• 解决方案：这是典型的内存溢出。立即切换到方法二（File System Access API）。如果浏览器不支持，则必须优化你的模型。考虑在导出前对模型进行轻量化处理：减少面数、压缩纹理、移除不必要的动画数据。也可以尝试将方法一的导出操作放入setTimeout或requestIdleCallback中，避免阻塞UI线程，但治标不治本。

问题4：在iOS Safari或某些移动端浏览器上导出失败。

• 排查：Safari对Blob URL和下载行为的支持有时比较特殊。确保你的<a>标签被添加到了document.body。有些版本需要用户手势（点击）直接触发URL.createObjectURL和a.click()，中间不能有异步操作（如await）。方法一的兼容性最好，如果仍失败，可能是浏览器策略限制。
• 备选方案：尝试方法三（Base64 Data URL），虽然效率低，但作为兜底方案有时能奏效。或者，引导用户使用Chrome或Firefox等浏览器。

问题5：如何给下载的文件一个中文名？

• 解决方案：如前所述，使用编码/解码。C#端：string encodedName = Uri.EscapeDataString(“中文模型.glb”);。JS端：var filename = decodeURIComponent(encodedName);。注意，download属性对文件名的支持因浏览器而异，这是最稳妥的方式。

问题6：我想在导出成功或失败时，在Unity的UI上显示提示。

• 解决方案：使用unityInstance.SendMessage进行回调。在jslib的成功和错误处理分支中，调用例如unityInstance.SendMessage(‘ExportManager’, ‘OnExportSuccess’, filename)。在Unity场景中，需要一个名为“ExportManager”的GameObject，其上挂载的脚本包含public void OnExportSuccess(string message)方法。失败时同理。

性能优化小技巧：

• 预分配内存：如果频繁导出，可以考虑在C#端复用同一个字节数组缓冲区，而不是每次导出都new byte[]，减少GC压力。
• 分块传输（针对超大文件）：修改jslib和C#接口，支持分块传输数据。C#端循环调用JS函数传递数据块指针，JS端将块数据追加到同一个文件流中。这需要更复杂的协议设计，但能彻底解决大内存问题。
• 提供导出进度：对于大文件，即使使用流式API，用户也想知道进度。可以在C#端分块传输时，每传输完一块就通过SendMessage更新Unity UI上的进度条。

实现WebGL下的文件导出，尤其是像GLB这样的二进制文件，是一个结合了Unity WebGL交互、浏览器API和前端技巧的综合性任务。从最基础的Blob下载，到应对大文件的流式写入，再到极端情况下的Base64备胎，这三种方法构成了一个完整的解决方案矩阵。最重要的是理解其背后的原理：内存指针传递、Blob对象、Object URL以及浏览器安全沙箱的限制。当你掌握了这些，不仅能解决GLB导出问题，任何从Unity WebGL向本地输出数据的需求，你都能游刃有余。