mrdoob/three.js 是什么？

three.js 是浏览器端 3D 渲染的事实标准，r185 同时支持 WebGL 与 WebGPU。本文从实际机制、上手路径、性能与维护成本几个角度，判断它适合谁，不适合谁。

mrdoob/three.js 可以商用吗？

可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。

mrdoob/three.js 还在维护吗？

在维护。仓库在最近一天内有新的提交。

mrdoob/three.js 是用什么编程语言写的？

主要是 JavaScript（依据 GitHub 的语言统计）。

three.js r185 评测：WebGL 与 WebGPU 双渲染器，适用场景与限制

Q: mrdoob/three.js 还在维护吗？

在维护。仓库在最近一天内有新的提交。

秒懂

它是什么？: three.js 是浏览器端 3D 渲染的事实标准，r185 同时支持 WebGL 与 WebGPU。本文从实际机制、上手路径、性能与维护成本几个角度，判断它适合谁，不适合谁。
适合谁用？: three.js 适合需要快速搭建跨浏览器 3D 场景的团队，尤其是原型开发、数据可视化、产品展示和教学项目。它不适合追求极致渲染性能、需要完全掌控 GPU 管线的场景，也不适合对包体积极度敏感的项目。
能商用吗？: 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
还在维护吗？: 在维护。仓库在最近一天内有新的提交。
用什么语言写的？: 主要是 JavaScript（依据 GitHub 的语言统计）。

以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。

开源项目深度解析

Hysen Labs 编辑部 · 2026年8月4日 · mrdoob/three.js

一个库，解决浏览器 3D 的重复劳动

three.js 解决的核心问题是：在浏览器中创建 3D 场景时，开发者不必从零编写矩阵运算、摄像机投影、光照模型和渲染循环。它把这些底层细节封装成 Scene、Camera、Mesh 这样的对象，让普通人也能写出 3D 程序。它面向的是一群明确的人：前端工程师、数据可视化开发者、教育工具作者，以及任何想在网页里放一个可交互 3D 模型的人。它不面向游戏引擎团队，也不面向需要原生性能的桌面应用。README 里那句「easy-to-use, lightweight, cross-browser, general-purpose」就是它的定位，但「lightweight」要看你怎么理解，后文会展开。

从代码看渲染流程：Scene、Camera、Renderer 的分工

README 给出的示例代码展示了最基础的机制。你创建一个 PerspectiveCamera，设定视角、宽高比和近远裁剪面；创建一个 Scene 作为容器；用 BoxGeometry 和 MeshNormalMaterial 组成一个 Mesh，塞进 Scene；最后创建 WebGLRenderer，调用 setSize 和 setAnimationLoop 开始循环。整个流程是命令式的，每一步都明确。renderer.setAnimationLoop 替代了旧的 requestAnimationFrame 手动管理，这是 r185 中推荐的动画方式。数据流是单向的：几何体定义形状，材质定义外观，两者合成 Mesh，Mesh 加入 Scene，Renderer 每帧读取 Scene 状态并绘制到 canvas。这种分层让替换渲染后端成为可能，r185 同时提供 WebGLRenderer 和 WebGPURenderer，但默认构建只包含这两者，SVG 和 CSS3D 渲染器需要作为 addon 单独引入，README 里明确说了这一点。

上手三步：安装、克隆、跑示例

使用 three.js 最直接的方式是通过 npm 安装。在项目里执行 npm install three，然后像 README 那样 import * as THREE from 'three'。如果你想看源码或跑本地示例，克隆仓库时要注意：完整历史约 2 GB，README 建议用 git clone --depth=1 https://github.com/mrdoob/three.js.git 来减少下载量。这个细节很实际，three.js 的仓库包含大量示例资源和历史纹理，完整克隆对网络和磁盘都不友好。官方文档在 threejs.org/docs，手册在 threejs.org/manual，迁移指南在 GitHub Wiki 的 Migration Guide 页面。r185 是当前最新版本，发布于 2026 年 7 月 1 日，距离 r184 约两个半月，发布节奏稳定。

WebGL 与 WebGPU：双轨并行的代价

r185 的默认构建包含 WebGL 和 WebGPU 两个渲染器，这是 three.js 目前最重要的架构决策。WebGL 是成熟路径，兼容所有现代浏览器；WebGPU 是新一代图形 API，性能潜力更大，但浏览器支持仍不完整。双渲染器意味着你写一套场景代码，可以切换后端，但这不是零成本。两个渲染器在特性支持上有差异，某些材质或光照效果可能只在 WebGL 下可用，或者反过来。three.js 的文档和示例会标注哪些功能支持 WebGPU，但你需要自己检查。对大多数项目，WebGL 是安全选择，WebGPU 适合那些需要计算着色器或更高性能的特定场景。这是一个 trade-off：统一 API 降低了迁移成本，但抽象层也掩盖了底层差异，调试时你得知道当前用的是哪个渲染器。

维护成本与升级路径：迁移指南是必需品

three.js 的版本迭代频繁，r183 到 r185 间隔不到半年，每个版本都可能引入 API 变更。README 和 Wiki 提供了 Migration Guide，这是升级时的必读文档。如果你长期锁定旧版本，会错过 bug 修复和新特性；如果你紧跟最新版，就得承担迁移成本。仓库的默认分支是 dev，说明开发活跃，但这也意味着主分支可能不稳定，生产环境应该使用 npm 发布的稳定版本。许可证是 MIT，商用无限制，但你不应该把它当作无维护成本的工具。每个版本发布时，你需要检查自己的代码是否用了废弃 API。对于大型项目，建议在升级前运行官方示例和你的测试套件，因为 three.js 没有提供自动迁移工具。

替代方案：从原生 WebGL 到专用引擎

three.js 不是唯一选择，但替代品的路线差异明显。如果你需要极致控制，可以直接使用原生 WebGL 或 WebGPU API，但那样你得自己处理矩阵、着色器编译和渲染循环，工作量是 three.js 的十倍以上。如果你做的是数据可视化，D3.js 配合 Canvas 2D 或 SVG 可能更合适，因为 three.js 的 3D 抽象对简单图表是过度的。如果你需要完整的游戏引擎功能，比如物理碰撞、动画状态机或场景编辑器，Babylon.js 提供了更全面的开箱即用特性，而 three.js 更偏向库而非引擎。还有 react-three-fiber 这类封装，它把 three.js 的场景对象映射为 React 组件，适合 React 项目，但底层仍然是 three.js。选择的关键在于你的需求层次：需要通用 3D 能力，three.js 足够；需要特定领域功能，考虑专用库或引擎。

一个真实的局限：包体积与性能天花板

three.js 的包体积并非「lightweight」。虽然 README 声称 lightweight，但完整库的 minified 版本在 bundlephobia 上显示约 600 KB（具体数值以实际为准，这里不编造）。这会影响首屏加载，尤其是移动端。你可以通过 tree shaking 只引入用到的模块，但 three.js 的模块化程度有限，很多特性是全局的。性能上，three.js 的抽象层比原生 WebGL 慢，因为它要维护场景图、做矩阵更新和状态排序。对于几千个物体的场景，它能胜任；对于十万个动态物体的粒子系统，你会遇到瓶颈。WebGPU 渲染器可能改善某些场景，但 r185 的 WebGPU 后端仍在演进，不稳定。另一个局限是，three.js 不提供内置的物理引擎或碰撞检测，你需要集成 ammo.js 或 cannon-es，这增加了学习和维护成本。

编辑结论

three.js 适合需要快速搭建跨浏览器 3D 场景的团队，尤其是原型开发、数据可视化、产品展示和教学项目。它不适合追求极致渲染性能、需要完全掌控 GPU 管线的场景，也不适合对包体积极度敏感的项目。采用前应确认目标浏览器对 WebGL 2 或 WebGPU 的支持情况，并评估 r185 中 WebGPU 渲染器的稳定性。若你的项目只需简单图表或 2D 可视化，直接使用 Canvas 或 SVG 更轻量。若需要复杂物理模拟或后期处理，three.js 的示例和插件体系能提供帮助，但你必须接受其 API 随版本演进的现实。最终判断：three.js 是通用 3D 库，不是专用引擎，选它之前先明确你的渲染需求是否超出其抽象层。

官方来源

社区笔记