圖紙還沒畫，咖啡先涼了：把 CAD 搬進瀏覽器，三個專案三種走法

2026年10月15日，掘金出現一篇長文，作者以實際體驗比較了三個想把 CAD 搬進瀏覽器的開源專案：CADCraft、OpenCAD Studio 與 MLightCAD CAD Viewer。文章的開場畫面很有共鳴：以前想看一張 DWG 圖，得開機、啟動 CAD 軟體、等載入，電腦配備差一點的，還得順手泡杯咖啡。現在越來越多專案宣稱，打開網頁就能看圖、畫圖，甚至編輯圖紙。

但作者丟出的問題也很直接：把桌面 CAD 編譯成 WebAssembly，然後就大功告成了嗎？

三個專案，三種思路

CADCraft：走 Rust 加 WebAssembly 路線，核心能力同時支援瀏覽器與桌面環境，定位是輕量級 2D CAD，提供基本繪圖與編輯。作者提醒一個常見誤解：用了 Rust 不代表效能自動起飛，用了 WASM 也不代表瀏覽器裡的 CAD 就能隨便跑。他打了個比方，換了好引擎的汽車，遇上堵車照樣動彈不得。圖紙解析、幾何生成、渲染、互動，哪一環卡住，使用者都感受得到。

OpenCAD Studio：同樣是 Rust 加 WASM，但野心大一些，除了 2D 繪圖，還提供部分 3D 實體建模能力，想做成更通用的 CAD 工作環境。作者的提醒是功能越多、工程複雜度越高，尤其在瀏覽器裡，記憶體、任務調度、檔案解析與介面回應都得重新考量。桌面能跑，不代表網頁版一樣順。他的建議很實際：別只開一張簡單的矩形圖紙就宣布測試通過，拿真實工程圖試試，因為生產環境的 DWG 往往比展示用的圖更有「驚喜」。

MLightCAD CAD Viewer：名字叫 Viewer，實際上支援圖元選取、編輯、圖層管理、測量與標註。技術棧是 TypeScript、Three.js 與 WebGL，思路跟前兩者不同：它關注的不是再造一個完整 CAD 軟體，而是把 CAD 能力變成 Web 應用裡的一個功能模組。

換個方向：CAD 可以不是軟體，而是零件

作者舉了幾個 MLightCAD 思路的應用場景：在專案管理系統裡直接查看 DWG、在製造業 SaaS 中把圖紙和零組件資料關聯起來、在網頁上測量尺寸加批註、把 CAD 編輯器嵌入自己的 Vue 應用，甚至把圖紙匯出成 HTML 讓別人直接打開看。

換句話說，CAD 未必要以獨立軟體的姿態存在，它可以是別的系統裡的一塊拼圖。

真正的考驗：大圖

文章後半段進入實戰部分。開一張簡單平面圖，三個專案可能都沒問題，但換成一張塞滿線段、複雜填充、文字、標註和嵌套圖塊的工程圖，高下才開始分曉。

作者指出 CAD 圖紙和一般圖片的本質差異：圖片只需顯示像素，CAD 要處理有結構的圖元。幾十萬條圖元、成千上萬個文字、複雜填充圖案一起上場時，事情就不簡單了。

他點出的第一個坑：DWG 檔案小，不代表渲染資料小。一個幾十 MB 的檔案，解析後生成的頂點、索引與其他渲染資料，體積可能明顯膨脹。所以不能只看檔案大小，要看解析之後究竟生成了多少東西。

第二個坑則是圖元一多，GPU 也會喊累。來源內容在此處截斷，後續細節無法確認，但從前文脈絡看，作者的核心論點已經清楚：瀏覽器裡的 CAD，考驗從來不在展示用的範例圖，而在真實世界的工程圖。

圍觀這篇文章的方式

這類技術長文在掘金上被轉傳，通常不是因為結論聳動，而是作者真的把三個專案打開來用過，並把「聽起來很美好」與「實際會卡在哪」之間的落差寫了出來。這與先前那篇把「沙箱」一次講明白的掘金長文有相似的走紅邏輯：一個被天天掛在嘴邊的概念，終於有人攤開來講清楚它能做什麼、不能做什麼。

至於瀏覽器會不會徹底取代桌面 CAD，作者沒有給出斷言。從文章提供的資訊看，比較確定的只有一件事：三條路線各有取捨，而真正的裁判永遠是那張又大又亂的真實工程圖。