以前想看个 DWG 文件，第一反应是什么？打开电脑，启动 CAD，等软件加载，再等图纸加载。如果电脑配置一般，还得顺便喝杯咖啡，给自己一点耐心。现在不一样了，越来越多的项目开始尝试把 CAD 搬进浏览器。打开网页就能画图、看图，甚至编辑图纸。听起来很美好，仿佛以后连 CAD 软件都不用安装了。
但问题来了：把 CAD 放进浏览器，真的只是把桌面软件编译成 WebAssembly，然后就大功告成了吗？ 最近我研究和体验了三个项目：CADCraft、OpenCAD Studio 和 MLightCAD CAD Viewer。它们都在尝试让 CAD 在浏览器里跑起来，不过技术路线和产品定位各有不同。今天就聊聊这三个项目，以及我在实际使用中发现的一些问题。
一、三个项目，三种思路
1. CADCraft：Rust 加持，轻量级 2D CAD
项目地址：CADCraft on GitHub
CADCraft 主要使用 Rust 开发，通过 WebAssembly 将核心能力带到浏览器，同时支持桌面环境。它的定位比较明确：轻量级 2D CAD，支持基本的绘图和编辑操作。Rust 的性能和内存安全特性都不错，WebAssembly 也能让一套核心代码在不同平台复用。这套组合看起来很合理。不过，这里有个容易产生的误解：
用了 Rust，不代表性能自动起飞；用了 WASM，也不代表浏览器里的 CAD 就能随便飞。
就像给汽车换了个好发动机，不代表堵车时也能一路狂飙。图纸解析、几何生成、渲染和交互，哪个环节拖后腿，用户都能感受到。
2. OpenCAD Studio：不只画 2D，还想玩 3D
项目地址：OpenCAD Studio
OpenCAD Studio 同样采用 Rust 和 WebAssembly 技术路线，除了 2D 绘图，还提供部分 3D 实体建模能力。它想做的事情更多一些：既要能画图，又希望具备更通用的 CAD 工作环境。这当然是个不错的方向。但功能越多，工程复杂度也可能越高。特别是到了浏览器里，内存、任务调度、文件解析和界面响应都需要重新考虑。桌面程序能跑，不等于浏览器版本也能跑得一样顺畅。
所以，如果你准备把它用到实际项目里，建议别只打开一张简单的矩形图纸就宣布测试通过。最好拿真实的工程图试试，毕竟生产环境里的 DWG，往往比演示用的图纸更有“惊喜”。
3. MLightCAD CAD Viewer：不只是看图，还想让 CAD 成为 Web 组件
项目地址：MLightCAD CAD Viewer
先解释一下名字：虽然叫 CAD Viewer，但它不只是一个只能看图的 Viewer，也支持图元选择、编辑、图层管理、测量和标注等操作。它的思路和前面两个项目略有不同，更关注浏览器环境下的 CAD 渲染、编辑，以及如何把 CAD 能力集成到其他 Web 应用里。
技术栈主要是 TypeScript、Three.js 和 WebGL。
为什么这么做？因为很多时候，开发者需要的不是再造一个完整的 CAD 桌面软件，而是给现有业务系统加上 CAD 能力。例如：
- 在项目管理系统里直接查看 DWG。
- 在制造业 SaaS 中关联图纸和零部件数据。
- 在网页中测量尺寸、添加批注、审查工程图。
- 把 CAD 编辑器嵌入自己的 Vue 应用。
- 将图纸导出成 HTML，方便别人直接打开查看。
换句话说，CAD 不一定非要是一个独立软件，也可以成为 Web 应用中的一个功能模块。这也是 MLightCAD 比较关注的方向。
二、真正的考验来了：大图！
打开一张简单的平面图，三个项目可能都能正常工作。但如果换成一张包含大量线段、复杂填充、文字、标注和嵌套块的工程图呢？这时候，CAD 软件的真实水平才开始接受考验。
CAD 图纸和普通图片不一样。图片只需要显示像素，CAD 则需要处理各种有结构的图元。一条直线还好说，一个圆弧也不难处理。但如果图纸里有几十万条图元、成千上万个文字，还有复杂的填充图案，事情就没那么简单了。主要有几个容易踩坑的地方。
1. 图纸文件不大，不代表渲染数据不大
一个 DWG 文件可能只有几十 MB，但解析后生成的顶点、索引和其他渲染数据，体积可能明显膨胀。特别是复杂填充、曲线和文字，处理起来可不只是把文件读出来那么简单。所以，不能只看 DWG 文件大小，还要看解析之后究竟生成了多少东西。
2. 图元太多，GPU 也会喊累
假设一张图纸有十万个图元，如果每个图元都单独创建一个渲染对象，会发生什么？CPU 需要管理大量对象，渲染过程中还会产生大量 Draw Call。GPU 再强，也不是所有工作都能替 CPU 做。这就像一个餐厅有十万个客人，每个人点菜都要老板亲自接单、确认、签字。厨房再大，老板也能先累趴下。
一种常见的优化方法就是 Geometry Batching（几何批处理） ：把适合一起绘制的图元合并起来，减少 Draw Call，同时保留必要的图元信息，方便后续选择和编辑。当然，批处理也不是越多越好。合并之后还得考虑图元更新、图层显示、选中高亮等问题。
3. CAD 文字，远比想象中麻烦
CAD 文字不是简单地调用一下浏览器的 fillText() 就完事了。MText 有自己的格式规则，SHX 字体可能需要按笔画绘制，文字高度、对齐、旋转和特殊符号也都需要处理。如果一张图纸里有几万个文字，字体处理和文字布局就可能成为性能瓶颈。有时候，线条早就画完了，文字还在慢慢加载。用户只会觉得：这软件怎么还没打开？至于你后台用了什么高级算法，用户并不关心。
4. 选中一个图元，最好别把整张图重画一遍
CAD 不仅要显示，还要编辑。用户修改一条线，程序应该尽可能只更新受影响的内容，而不是动不动就把整个场景重新构建一遍。否则，拖动、选择和修改都可能卡顿。
所以，真正做好一个 CAD 编辑器，需要同时考虑几何处理、渲染、缓存、图元索引和增量更新。单纯换一种编程语言，并不能解决所有问题。
三、三个项目的实际体验怎么样？
在我自己的体验中，使用较大图纸打开和编辑时，CADCraft 和 OpenCAD Studio 都出现过比较明显的卡顿；MLightCAD CAD Viewer 在我测试的这些图纸上，交互流畅度更好一些。
这里特别说明一下：这是我的实际使用观察，不是严格控制硬件、图纸和软件版本的标准化性能测试。不同图纸、浏览器、电脑配置和版本，都可能影响最终结果。
如果你也想比较这几个项目，建议拿自己业务中的真实图纸测试，而不是只看演示视频。我比较关注以下几个指标：
| 测试项目 | 为什么重要 |
|---|---|
| 首次打开时间 | 决定用户要等多久 |
| 缩放和平移 | 最基本的操作，卡顿特别明显 |
| 图元选择 | 能不能快速选中目标 |
| 修改图元 | 编辑时是否需要等待 |
| 内存占用 | 大图可能直接把浏览器拖垮 |
| 复杂文字和填充 | 最容易暴露处理能力的地方 |
我也不认为这次体验就能证明 Rust 或 WebAssembly 不适合大型 CAD。恰恰相反，Rust 和 WASM 都有很大的价值。只是从技术选型到最终产品，中间还有一大段工程工作要做。
能在浏览器里运行，只是第一步；能让用户拿真实图纸干活，才算真正过关。
四、MLightCAD 做了哪些性能优化？
既然前面提到了实际体验，顺便聊聊 MLightCAD 在这方面的一些技术思路。
1. 几何批处理
前面说过，图元太多会导致大量渲染对象和 Draw Call。MLightCAD 采用了几何批处理机制，把符合条件的图元组织到共享的顶点和索引缓冲区中，同时保留图元对应的元数据。这样既能减少部分绘制开销，也能为图元级的选择、显示控制和更新提供基础。
2. 利用 GPU 处理部分显示效果
虚线、点划线和复杂填充，都可能带来额外的几何处理成本。通过自定义 Shader 和渲染材质，可以让 GPU 参与生成部分显示效果，减少某些不必要的 CPU 工作。不过要注意，GPU 并不是万能的。图纸解析、边界处理和几何生成仍然可能需要大量 CPU 计算。
3. 字体缓存和文字处理
对于 CAD 文字，需要针对 MText、SHX 字体等内容做专门处理。合理的缓存机制可以避免重复加载和处理相同资源，改善文字较多的图纸的加载与渲染体验。
4. 尽量只更新真正发生变化的图元
如果修改一个图元就重建整张图纸，性能很难做好。因此，渲染系统还需要维护图元和对应几何数据之间的关系，让一些修改可以局部完成。当然，如果修改涉及复杂几何，重新生成相关数据仍然是不可避免的。
5. 大坐标和海量图元选择
工程图还可能遇到一些不太显眼的问题，例如坐标值特别大、图元数量特别多。这些问题会影响数值精度、视图定位和选择效率，也需要单独处理。更多技术细节可以参考 MLightCAD CAD Viewer Wiki。
这里想强调的是：这些优化不是某个单独的“黑科技”，而是围绕 CAD 的实际工作负载，一点点解决问题。
五、除了性能，还得看你想拿它做什么
选 CAD 项目，不能只看谁打开图纸最快，还要看它适不适合自己的业务。
如果你需要一个轻量级的 2D CAD 工具：
可以关注 CADCraft，看看它的绘图功能、跨平台能力和实际图纸兼容性是否满足需求。
如果你希望有更通用的 CAD 环境，并且需要部分 3D 建模能力：
可以研究 OpenCAD Studio，尤其要确认你需要的功能在当前版本中是否已经可用。
如果你想把 CAD 集成到现有 Web 应用中：
可以看看 MLightCAD CAD Viewer。
除了直接打开 DWG/DXF，它还提供 SDK、图元编辑、测量、标注以及自包含 HTML 导出等能力。比如，你可以把 CAD 编辑器嵌入自己的业务系统，而不是让用户在几个软件之间来回切换。如果只是分享图纸，也可以考虑将图纸导出为 HTML，让接收者通过浏览器查看，不必为了看一张图再安装完整的 CAD 软件。
需要注意的是，HTML 导出适用于相应的查看和审阅场景，并不意味着它可以完全替代原始 DWG/DXF 文件或完整编辑器。
相关示例：
六、最后聊聊 WebAssembly：它不是性能免死金牌
最近不少 CAD 项目都在使用 WebAssembly，这个方向确实值得关注。它能让开发者复用 C、C++、Rust 等语言编写的核心代码，在浏览器中执行原本更适合编译运行的计算任务。但浏览器和桌面环境终究不一样。内存管理、文件访问、线程调度、JavaScript 交互和图形渲染，都有各自的限制。即使核心算法写得再漂亮，如果渲染对象过多、数据重复生成，或者耗时任务阻塞了界面，用户照样会看到一个卡住的画布。
所以，我认为讨论浏览器 CAD 时，不应该简单地争论 Rust 和 TypeScript 谁更快，或者 WASM 和 JavaScript 谁更强。更值得关注的是整个系统：
- 图纸解析是否高效？
- 几何数据是否合理组织？
- 渲染开销是否可控？
- 大图交互是否流畅？
- 编辑操作能否增量更新？
- 是否方便集成到实际业务中？
这些问题，才真正决定一个浏览器 CAD 能不能用于生产环境。
总结
CADCraft、OpenCAD Studio 和 MLightCAD CAD Viewer 都在探索 CAD 的 Web 化，但侧重点有所不同。
CADCraft 更关注轻量级 2D CAD 和跨平台能力；OpenCAD Studio 希望提供更通用的 CAD 环境；MLightCAD CAD Viewer 则更侧重浏览器中的 CAD 渲染、编辑和应用集成。
从我的实际体验来看，MLightCAD 在所测试的大图场景中表现更流畅。不过，这只是特定测试条件下的观察，最终选择仍然应该结合自己的图纸、硬件和业务需求。最后送给准备开发 Web CAD 的朋友一句话：
把 CAD 跑进浏览器不算最难，难的是让它在十万条图元面前，依然像个正常的软件。
毕竟，用户可以接受软件功能少一点，但让用户放大一张图都要等半天，那就真的有点说不过去了。
