把 AutoCAD 搬进浏览器，到底有多难？聊聊 CADCraft、OpenCAD Studio 和 MLightCAD

以前想看个 DWG 文件，第一反应是什么？打开电脑，启动 CAD，等软件加载，再等图纸加载。如果电脑配置一般，还得顺便喝杯咖啡，给自己一点耐心。现在不一样了，越来越多的项目开始尝试把 CAD 搬进浏览器。打开网页就能画图、看图，甚至编辑图纸。听起来很美好，仿佛以后连 CAD 软件都不用安装了。

但问题来了：把 CAD 放进浏览器，真的只是把桌面软件编译成 WebAssembly，然后就大功告成了吗？ 最近我研究和体验了三个项目：CADCraft、OpenCAD Studio 和 MLightCAD CAD Viewer。它们都在尝试让 CAD 在浏览器里跑起来，不过技术路线和产品定位各有不同。今天就聊聊这三个项目，以及我在实际使用中发现的一些问题。

CADCraft 主要使用 Rust 开发，通过 WebAssembly 将核心能力带到浏览器，同时支持桌面环境。它的定位比较明确：轻量级 2D CAD，支持基本的绘图和编辑操作。Rust 的性能和内存安全特性都不错，WebAssembly 也能让一套核心代码在不同平台复用。这套组合看起来很合理。不过，这里有个容易产生的误解：

用了 Rust，不代表性能自动起飞；用了 WASM，也不代表浏览器里的 CAD 就能随便飞。

就像给汽车换了个好发动机，不代表堵车时也能一路狂飙。图纸解析、几何生成、渲染和交互，哪个环节拖后腿，用户都能感受到。

OpenCAD Studio 同样采用 Rust 和 WebAssembly 技术路线，除了 2D 绘图，还提供部分 3D 实体建模能力。它想做的事情更多一些：既要能画图，又希望具备更通用的 CAD 工作环境。这当然是个不错的方向。但功能越多，工程复杂度也可能越高。特别是到了浏览器里，内存、任务调度、文件解析和界面响应都需要重新考虑。桌面程序能跑，不等于浏览器版本也能跑得一样顺畅。

所以，如果你准备把它用到实际项目里，建议别只打开一张简单的矩形图纸就宣布测试通过。最好拿真实的工程图试试，毕竟生产环境里的 DWG，往往比演示用的图纸更有“惊喜”。

项目地址：MLightCAD CAD Viewer

先解释一下名字：虽然叫 CAD Viewer，但它不只是一个只能看图的 Viewer，也支持图元选择、编辑、图层管理、测量和标注等操作。它的思路和前面两个项目略有不同，更关注浏览器环境下的 CAD 渲染、编辑，以及如何把 CAD 能力集成到其他 Web 应用里。

技术栈主要是 TypeScript、Three.js 和 WebGL。

为什么这么做？因为很多时候，开发者需要的不是再造一个完整的 CAD 桌面软件，而是给现有业务系统加上 CAD 能力。例如：

换句话说，CAD 不一定非要是一个独立软件，也可以成为 Web 应用中的一个功能模块。这也是 MLightCAD 比较关注的方向。

打开一张简单的平面图，三个项目可能都能正常工作。但如果换成一张包含大量线段、复杂填充、文字、标注和嵌套块的工程图呢？这时候，CAD 软件的真实水平才开始接受考验。

CAD 图纸和普通图片不一样。图片只需要显示像素，CAD 则需要处理各种有结构的图元。一条直线还好说，一个圆弧也不难处理。但如果图纸里有几十万条图元、成千上万个文字，还有复杂的填充图案，事情就没那么简单了。主要有几个容易踩坑的地方。

一个 DWG 文件可能只有几十 MB，但解析后生成的顶点、索引和其他渲染数据，体积可能明显膨胀。特别是复杂填充、曲线和文字，处理起来可不只是把文件读出来那么简单。所以，不能只看 DWG 文件大小，还要看解析之后究竟生成了多少东西。

假设一张图纸有十万个图元，如果每个图元都单独创建一个渲染对象，会发生什么？CPU 需要管理大量对象，渲染过程中还会产生大量 Draw Call。GPU 再强，也不是所有工作都能替 CPU 做。这就像一个餐厅有十万个客人，每个人点菜都要老板亲自接单、确认、签字。厨房再大，老板也能先累趴下。

一种常见的优化方法就是 Geometry Batching（几何批处理） ：把适合一起绘制的图元合并起来，减少 Draw Call，同时保留必要的图元信息，方便后续选择和编辑。当然，批处理也不是越多越好。合并之后还得考虑图元更新、图层显示、选中高亮等问题。

CAD 文字不是简单地调用一下浏览器的 fillText() 就完事了。MText 有自己的格式规则，SHX 字体可能需要按笔画绘制，文字高度、对齐、旋转和特殊符号也都需要处理。如果一张图纸里有几万个文字，字体处理和文字布局就可能成为性能瓶颈。有时候，线条早就画完了，文字还在慢慢加载。用户只会觉得：这软件怎么还没打开？至于你后台用了什么高级算法，用户并不关心。

CAD 不仅要显示，还要编辑。用户修改一条线，程序应该尽可能只更新受影响的内容，而不是动不动就把整个场景重新构建一遍。否则，拖动、选择和修改都可能卡顿。

所以，真正做好一个 CAD 编辑器，需要同时考虑几何处理、渲染、缓存、图元索引和增量更新。单纯换一种编程语言，并不能解决所有问题。

在我自己的体验中，使用较大图纸打开和编辑时，CADCraft 和 OpenCAD Studio 都出现过比较明显的卡顿；MLightCAD CAD Viewer 在我测试的这些图纸上，交互流畅度更好一些。

这里特别说明一下：这是我的实际使用观察，不是严格控制硬件、图纸和软件版本的标准化性能测试。不同图纸、浏览器、电脑配置和版本，都可能影响最终结果。

如果你也想比较这几个项目，建议拿自己业务中的真实图纸测试，而不是只看演示视频。我比较关注以下几个指标：

我也不认为这次体验就能证明 Rust 或 WebAssembly 不适合大型 CAD。恰恰相反，Rust 和 WASM 都有很大的价值。只是从技术选型到最终产品，中间还有一大段工程工作要做。

来源：稀土掘金　原文