GLB 和 glTF 有什么区别？网页 3D 模型该选哪个格式？

GLB 和 glTF 经常一起出现，因为 GLB 本质上是 glTF 的二进制容器形式。它们都可以描述网页和实时渲染里的 3D 模型，但工作流不一样。

简单说：想要一个方便上传、预览、存储和交付的单文件，选 GLB；想在制作流程里保留 JSON、二进制数据和贴图文件的可见性，选 glTF。

两者都能用于网页 3D。关键不是哪个“更高级”，而是你现在处在发布、调试、编辑还是交接阶段。

glTF 是什么？

.gltf 文件是 JSON。它描述 3D 场景里的节点、网格、材质、动画、相机、骨骼、贴图，以及对外部资源的引用。

因为它是 JSON，开发者可以更容易查看结构：节点名、材质名、扩展、贴图引用、buffer 引用和资产元数据都比较透明。排查导出问题、写自动化资产流程、做版本控制时，这种透明度很有价值。

代价是：.gltf 往往不是完整模型本身。它可能还需要：

• .bin 二进制 buffer
• PNG、JPG、WebP、KTX 等贴图
• 通过 URI 引用的其他资源

只要路径变了，或者资源少传一个，模型就可能加载失败。

GLB 是什么？

GLB 会把 glTF 的 JSON 和二进制数据打包到一个二进制文件里。glTF 2.0 规范定义了这种容器形式，让一个模型可以在同一个文件里包含结构描述和二进制数据。

所以 GLB 很适合网页交付：

• 只有一个文件，上传更简单。
• 路径不容易断。
• 在线预览更方便。
• 存储和 CDN 分发更直接。
• 非技术用户不容易漏传贴图目录。

对于商品模型、客户交付、网页查看和工单附件，GLB 通常是更稳的默认选择。

什么时候选 GLB？

下面这些情况更适合 GLB：

• 要发给同事或客户快速预览。
• 要上传到网页 3D 查看工具。
• 要放到商品详情页或配置器里。
• 要作为 issue 或工单附件。
• 不想处理贴图路径丢失问题。
• 想在浏览器本地快速检查模型。

例如你可以直接把 GLB 放进 3D 模型查看，检查面数、顶点数、边界尺寸和渲染外观，再决定是否需要压缩或交付。

什么时候选 glTF？

下面这些情况更适合保留 glTF：

• 需要直接检查或编辑 JSON。
• 希望贴图保持独立文件。
• 要排查材质、扩展或资源引用。
• 构建流程会重写图片、buffer 或 metadata。
• 需要在 Git 里看到更清晰的文本 diff。
• 美术和开发要分别检查资源文件。

问题是交接更脆弱。只发 .gltf 不发 .bin 和贴图，模型是不完整的。因此很多团队会在制作阶段用 glTF，在最终交付阶段导出 GLB。

这种分阶段处理很常见：美术阶段保留可编辑资源，开发阶段检查加载器和扩展，发布阶段再输出单文件。这样既能保留调试能力，也能减少上线时的资源路径问题。

常见误区

第一个误区是把 .gltf 当成完整模型。很多时候它只是清单文件，真正的几何和贴图在旁边的资源里。

第二个误区是以为 GLB 就一定优化好了。GLB 只是打包形式，里面仍然可能有超大贴图、没用节点、过高面数、重复材质和未配置的压缩扩展。

第三个误区是忽略加载器兼容性。Draco、meshopt、KTX2 等扩展都可能需要额外 decoder。模型文件本身没错，但运行环境不支持，也会加载失败。

还有一个误区是只看文件格式，不看内容预算。同样是 GLB，一个 2 MB 的低面数商品模型和一个塞满 8K 贴图、动画轨道、隐藏节点的 120 MB 模型，对网页性能的影响完全不同。格式解决的是打包方式，性能还要看贴图、几何和运行时支持。

快速选择表

场景	更适合
浏览器快速预览	GLB
上传到商品 3D 展示	GLB
检查 JSON 结构	glTF
保留独立贴图文件	glTF
发一个文件给客户	GLB
自动化构建流程	制作阶段 glTF，交付阶段 GLB

如果你不确定当前模型属于哪个阶段，可以先问一句：接下来的人是要继续编辑它，还是只要把它放进网页里看？前者更偏 glTF，后者更偏 GLB。这个判断比单纯记格式定义更有用，也更贴近真实交付。

一句话总结

GLB 更适合网页交付和快速查看，glTF 更适合制作、调试和流水线处理。大多数非技术交接、浏览器预览和产品上传场景，优先选 GLB；但 GLB 仍然需要检查贴图大小、面数、材质和扩展兼容性，不能把“单文件”误解成“已优化”。