Three.js 加载 glTF 慢需先定位瓶颈：网络下载、CPU 解析（GLTFLoader.parse）或首帧渲染；再针对性优化——压缩纹理用 KTX2+Basis Universal，几何体用 Draco（须配解码器），分块加载与懒实例化降低主线程压力。
Three.js 加载 glTF 模型慢，先看瓶颈在哪
加载慢不等于模型“大”，更可能是网络传输、解析或渲染初始化阶段卡住。用浏览器 DevTools 的 Network 和 Performance 面板确认：是 gltf 文件下载耗时长？还是 GLTFLoader.parse() 耗 CPU？抑或 scene.add() 后首帧掉帧？不同瓶颈对应完全不同的优化路径。
压缩纹理：用 KTX2 + Basis Universal 替代 PNG/JPG
纹理常占 glTF 包体积 70% 以上。直接压缩 PNG 不仅效果差，还无法 GPU 直接解码。必须转成 GPU 原生支持的格式：
- 用
toktx工具将 PNG 转为.ktx2，启用--encode basis（Basis Universal 编码） - 在 glTF 中通过
EXT_texture_webp或KHR_texture_basisu扩展声明，Three.js 会自动调用THREE.TextureLoader的ktx2支持 - 实测：一个 8MB 的 4K albedo PNG → 转成 BC7 KTX2 后仅 1.2MB，且 GPU 解码零等待
toktx --encode basis --genmipmap --bcmp input.png output.ktx2
精简几何体：draco 压缩不是万能的，得配对解码器
draco 能把 .glb 几何数据压到原大小 10–15%，但代价是 JS 解码开销。若没配对加载，Three.js 会静默失败，控制台只报 DRACOLoader: Cannot decode DRACO compressed buffer。
- 导出时用 Blender glTF 插件勾选
Draco Compression，或用gltf-pipeline -d - 代码中必须显式注册解码器：
DRACOLoader.setDecoderPath('./js/libs/draco/')，且确保draco_decoder.js和draco_wasm_wrapper.js在该路径下 - 移动端注意：WASM 解码比 JS 快，但首次需编译；低端安卓可能 fallback 到 JS 解码，延迟更高
分块加载与懒实例化：避免一次性 add() 全部节点
哪怕模型已压缩，scene.add(...) 大量 Mesh 仍会阻塞主线程。尤其含数百子对象的建筑模型，add 过程本身就能卡帧。
立即学习“前端免费学习笔记（深入）”；
- 用
gltf.scene.traverse()提前遍历，按语义分组（如name含"wall"或"furniture"） - 用
requestIdleCallback()分批 add，每批 ≤ 10 个 Mesh，避免连续 50ms 以上占用 - 真正需要渲染时才创建材质/几何体：例如用户拖拽到某楼层再加载该层家具，而非启动就全 load()
复杂模型的加载优化，本质是把「一次性重活」拆成可中断、可调度、可降级的小任务。压缩只是起点，加载策略和运行时管理才是决定体验的关键。
