mrdoob/three.js

解决什么问题

在网页里做 3D，过去要么直接写 WebGL，自己处理矩阵、着色器和绘制顺序，要么引入一整套游戏引擎、让引擎决定应用结构。three.js 在 WebGL 和 WebGPU 之上提供场景图、相机、材质和渲染循环，屏幕上出现一个立方体只需要十几行代码。README 很简短——它是个库，不是产品宣传页——真正的资料在示例和文档站点里。

有什么不同

相对原生 WebGL，它去掉了样板代码，但仍贴近 GPU：你思考的是 mesh、geometry、material 和 light，而不是引擎级的 entity 和 prefab。相对 Unity、Godot 这类游戏引擎（Web 导出是一个编译后的运行时），它是嵌进现有 JavaScript 应用里的渲染库——没有编辑器、没有专有场景文件格式、没有强制的生命周期，这也正是它成为数据可视化、产品配置器和 WebXR 实验默认选择的原因。值得注意的方向是它自研的着色语言（three.js 一直在推进基于节点的 shader 体系，Hacker News 上的 "Three.js Shading Language" 帖子讨论的正是这个），以及多后端：主构建包含 WebGL 和 WebGPU 渲染器，SVG 和 CSS3D 渲染器以 addon 形式提供。

适合谁

需要在网页产品里放 3D 的前端开发者和创意编程者——产品配置器、可视化、作品集、小型 WebXR 场景——以及想用 JavaScript 写图形程序的研究者和艺术家。如果你需要带物理、关卡编辑和资源管线的完整游戏引擎，或者目标平台是原生应用，它并不合适。场景规模特别大的团队也应评估更底层或更专用的渲染器，因为 three.js 优先考虑易用性，而不是极限渲染吞吐。

上手成本

MIT 许可，可从 npm 安装；README 里给出的是 import * as THREE from 'three';，不强制任何构建工具。成本主要在概念上：理解场景图和渲染器生命周期，并持续关注 release note，因为项目迭代快，文档专门有迁移指南正是因为 API 会变。完整 clone 历史约有 2GB，这也侧面说明了项目的年头和体量。README 对架构和限制着墨很少，学习基本要靠示例站点。

点评

作为 Web 图形库，它的成熟度几乎到顶：2010 年创建，116,000+ stars、36,000+ forks，3D、WebGL、WebGPU、WebXR 都是活跃 topic。它没有上过每日 trending 榜，但月度 JavaScript 榜显示单月 +1,355 stars、排在第 13——是稳定而广泛的关注，不是短期爆发。成熟意味着示例和答案极多，也意味着 API 变化快、需要跟进。做浏览器 3D，它就是那个基准线；只有达到游戏级需求时才该考虑别的方案。