如果你在 2026 年做 Web3D 项目，有一个数字比任何性能跑分都更能说明这个生态的成熟度：glTF 2.0 在 2022 年 8 月 4 日正式成为 ISO/IEC 12113:2022 国际标准。
这件事的分量经常被低估。回想一下 2015 年 10 月 glTF 1.0 发布时，它还只是 Khronos 推的一个提案，业内主流引擎的支持是零星的。而今天，一个 3D 资产格式成了国际标准——这意味着全球公共采购、监管框架、教育体系都开始承认它。NVIDIA 开发者生态系统副总裁、Khronos 总裁 Neil Trevett 在当时的官方新闻稿里的说法很直接："2013 年，Khronos 发起了 glTF 计划，目标是创建一种与 JPEG 一样普遍的图像 3D 资产格式——现在 glTF 和 JPEG 一样，是一项国际标准。"
一个对照：JPEG 从 1992 年成为国际标准，到今天用了三十多年。glTF 从 2015 年发布到 2022 年成为 ISO 标准，只用了七年。
一、这个标准是怎么诞生的：三个关键时间点
ISO 标准的转化流程是评估一个技术成熟度和行业接受度的最硬指标。glTF 走完这条路的时间线很短，值得完整看一遍：
| 时间 | 事件 | 为什么重要 |
|---|---|---|
| 2013 年 | Khronos 发起 glTF 计划 | 目标是"与 JPEG 一样普遍"的 3D 资产格式 |
| 2015 年 10 月 | glTF 1.0 发布 | 确立"运行时传输格式"的定位 |
| 2017 年 6 月 | glTF 2.0 发布 | 加入 PBR 物理材质、稀疏访问器、变形目标 |
| 2021 年 5 月 | ISO/IEC JTC 1 批准 Khronos 作为 PAS 提交者 | Khronos 成为全球仅有的 15 个 SDO 之一 |
| 2021 年 10 月 | glTF 2.0 提交至 JTC 1 | 经全体有资格投票的国家标准机构一致批准 |
| 2022 年 8 月 4 日 | 作为 ISO/IEC 12113:2022 发布 | 没有要求任何技术更改 |
最值得注意的细节是：glTF 2.0 在成为国际标准的过程中，没有被要求做任何技术更改。ISO 委员会在技术层面完全接受了现有实现，只做了流程性的转换。这在标准转化中是极高的评价——它说明 glTF 2.0 的规范质量在提交前就已经达到了国际标准的水准，而不是靠后续修订补上去的。
同时 Khronos 承诺会继续把新功能定期更新进 ISO/IEC 12113，以避免行业分裂。这意味着这个标准不会冻结在一个老版本上。
二、2026 年正在发生什么：从"单个 3D 资产"到"体积媒体"
标准化的价值在 2026 年有了新的进展，这也是判断该标准生命力的最好指标。
体积媒体子组成立（2026 年 6 月 15 日）
Khronos 3D Formats 工作组宣布成立 Volumetric Media Subgroup（体积媒体子组）。这个动作的方向非常明确：glTF 原本处理的是单个 3D 资产（一个模型、一套材质、几段动画），而下一步要处理的是"体积媒体"——也就是带空间信息的多视角/立体内容。
glTF 2.1 提案：JPR 的分析（2026 年 7 月 2 日）
图形硬件行业权威研究机构 Jon Peddie Research（JPR）在 7 月 2 日发布了一篇分析，标题是 "glTF 2.1—beyond single 3D assets"，直译就是"glTF 2.1——超越单个 3D 资产"。
把这三件事串起来看趋势就很清楚了：一个资产格式在成为国际标准四年后，工作组正在推动它从"装单个模型"进化到"装空间内容"。这通常是一个格式生态真正走向成熟、开始承载更复杂应用形态的标志。
三、谁在用：一份可核查的采用清单
「广泛采用」这句话很容易变成空话，但 glTF 的采用方是可以点名核查的：
| 采用方 | 采用方式 | 时间 |
|---|---|---|
| Microsoft | 宣布整个产品线使用 glTF 2.0 作为 3D 资产格式：Paint 3D、3D Viewer、Remix 3D、Babylon.js、Microsoft Office | 2017 年 3 月 3 日 |
| VRM Consortium | 开源交互式 3D 头像格式 VRM 1.0 基于 glTF 2.0 构建 | — |
| 3D PDF（PDF Association） | glTF 2.0 成为受支持的 PDF 3D 资源；iOS 查看器支持全部基础 glTF 2.0 功能及部分扩展，含 Draco 压缩与透明涂层 PBR 扩展 | 2025 年 8 月 |
| Smithsonian Institution | 开放获取计划将约 280 万 2D 图像和 3D 模型发布到公共领域，3D 模型以 glTF 形式提供 | 2020 年 2 月 |
| Khronos 官方 iOS 查看器 | 以 Apache 2.0 许可发布完整应用源代码 | — |
| Sketchfab | 平台上有 100,000+ 个 CC 许可的 glTF 模型 | — |
其中 Smithsonian 把 280 万件 3D 模型以 glTF 格式开放这一条，对做 Web3D 的人有直接的实用价值：这是一个质量可控、许可清晰的公共 3D 资产库。做原型、找参考模型、跑兼容性测试，都可以先从这里取材，不用自己建模。
另外注意 3D PDF 那一条的意义：glTF 2.0 被打包进了 PDF 这个全球流通最广的文档格式里。如果你的客户是传统制造、需要在 PDF 交付物里嵌 3D 展示，glTF 是绕不开的格式。
四、压缩：Draco 还是 Meshopt，这是个真问题
模型体积是 Web3D 项目的第一大成本。glTF 生态为此提供了三条压缩扩展，选错会带来持续的性能损失：
| 扩展 | 作用对象 | 特点 |
|---|---|---|
| KHR_draco_mesh_compression | 几何数据 | Google 开发，压缩率通常最高，可减小 50%–90% 体积 |
| EXT_meshopt_compression | 几何数据 | 压缩率略低于 Draco，但解码速度显著更快，更适合 Web 端实时加载 |
| KHR_texture_basisu | 纹理 | Basis Universal / KTX2 容器，GPU 直接解压，对几何压缩无效 |
关键认知：几何压缩和纹理压缩是两件独立的事，Draco 和 Meshopt 都不解决纹理问题。一个 45MB 的模型如果体积大头是贴图，压几何是白费力气。正确的做法是先用分析工具看 GLB 内部各部分占比，再决定压哪一块。
还有一个工程上很实用的边界条件：对于面数极少（少于 1000 面）或文件本身极小（低于 100KB）的模型，压缩反而会让文件变大——压缩元数据开销超过了收益。给这类模型加 Draco 是纯粹的性能倒退。
框架支持上有一个容易踩的坑：Babylon.js 和 model-viewer 内置了 Draco 解码器但不支持 Meshopt，而 Three.js 两者都支持（Meshopt 需 r136+）。如果你的项目可能在多个查看器之间复用模型资产，Draco 的兼容性更保险；如果只在自己控制的 Three.js 项目里用，Meshopt 的解码速度优势更值钱。
五、一个需要清醒看待的现实：Khronos 不是唯一的标准制定者
这里必须纠正一个常见的认知偏差。ISO/IEC 12113 听起来很权威，但要注意它的产生方式：
ISO/IEC 国际标准在世界范围内得到认可，通常构成 IT 产品和服务在公共采购上的技术监管基础。Khronos 很自豪能成为 ISO/IEC JTC 1 PAS 提交者，并打算主动将其他广泛采用的 Khronos 规范转换为国际标准——注意最后这半句：这是一个主动的、面向未来的计划，不是"已完成的转换清单"。
更重要的是，在超大地理数据集与数字孪生领域，Khronos 并不是唯一、甚至不是主要的标准提供者：
- 3D Tiles——由 OGC（开放地理空间委员会）定义的、海量异构 3D 内容的流式渲染开放标准，面向倾斜摄影、城市模型、卫星数据
- OpenXR——Khronos 主导，用于跨厂商访问 XR 运行时
- 3D Commerce——Khronos 商标之一，商品 3D 化标准
实践结论是：glTF 管"单个资产怎么传"，3D Tiles 管"海量空间数据怎么流式加载"，两者是互补而非竞争关系。如果你做的是城市级孪生、数字地球、大规模倾斜摄影项目，最终大概率是 glTF 资产 + 3D Tiles 索引的组合架构。用 glTF 直接硬扛百万级瓦片是不现实的。
六、怎么用这份信息：2026 年的实践建议
把上面的信息转化成可执行的动作：
第一，如果你的新项目还没定格式，就用 glTF 2.0，这个决策现在没有争议空间。它已经是 ISO 国际标准，是 Three.js、Babylon.js、model-viewer、Unity、Unreal 的默认格式，也是 3D PDF 的资源格式。除非你有非常特殊的理由（极端几何量、平台硬性限制），否则选别的都是在给自己增加集成成本。
第二，资产格式选 glTF，压缩方案按框架选。纯 Three.js 项目用 Meshopt（解码快），需要跨 Babylon.js / model-viewer 复用用 Draco，纹理单独上 KTX2。三者不冲突，几何和纹理分别处理。
第三，动手前先做一次体积归因。用 GLB 分析工具看几何/贴图/动画的占比。几何占大头就上压缩，贴图占大头就换 KTX2/WebP，小模型（<100KB 或 <1000 面）不要压。跳过这一步的优化往往在做无用功。
第四，跟踪 glTF 2.1 和体积媒体子组的进展，但不要等。2.1 目前还是提案阶段，涉及空间内容和多视角数据。你的常规产品展示 / 工业可视化项目用 2.0 完全够用，等 2.1 落地通常还要一到两年。关注即可，不要为等一个未定标准而推迟项目。
第五，做大规模空间数据项目时，把 3D Tiles 一起纳入技术选型。glTF 解决不了"百万级瓦片如何按需流式加载"这个问题，那是 OGC 3D Tiles 的领域。
七、结语
把时间线拉直来看，glTF 这十三年做对了一件事：它没有试图成为 authoring 格式，而是明确定位成"运行时传输格式"。
glTF 2.0 规范原文里有一段话说得很清楚——glTF 刻意不保留 3D 创作信息，以保持运行时效率；它是可扩展的、互操作的 3D 资产"传输"格式，弥合 3D 内容创作工具与现代图形应用之间的鸿沟。
这个取舍带来的结果是：它比 FBX 轻、比 OBJ 结构化、比 Collada 好解析，而且不绑定任何厂商。代价是它做不了 Blender、3ds Max 那种"创作"工作。2022 年成为 ISO 标准、2026 年开始做体积媒体扩展，验证了这个定位是对的。
所以对你的实际决策只有一句话：格式不用再纠结了，纠结的应该是压缩配比和加载性能。这两件事有明确的判断标准和工具，而格式选择早已没有悬念。
