上周有个做工程管理的老哥来找我说他手上有三百多张 DWG 图纸想塞进自家那套管理系统里让外地的施工队直接在浏览器里点开就能看不用装任何客户端。需求听起来特别朴素——如何在网页打开 CADDWG 文件可真正动过手的人都清楚这一句话背后藏着十几个坑。我前后做过三套不同量级的方案从最简单的服务端出图到浏览器里跑 WebAssembly 内核解析踩过的坑足够写一篇长文。这篇就把 H5 前端显示 CAD 这件事从头到尾拆一遍DWG 到底难在哪、几条技术路线各自的取舍、怎么把一个实体真正画到 Canvas 上、以及那些只在深夜调试时才会冒出来的诡异问题字体变问号、大坐标抖动、几万实体卡成幻灯片。如果你正在做在线 CAD 平台或者只是想给自己的业务系统加一个网页 CAD 预览这篇应该能帮你少走至少两周弯路。1. DWG 在浏览器里直读为什么这么别扭1.1 二进制私有格式决定了前端硬解几乎走不通先摆一个事实DXF 是文本格式用记事本打开就能看到一堆数字和字符串交替排列的组码DWG 不是它是二进制压缩格式图元数据被打包成紧凑的字节流还带版本差异。DWG 的版本号写在文件头前六个字节长这样R14 是 AC10142000 是 AC10152004 是 AC10182007 是 AC10212010 是 AC10242013 是 AC10272018 之后的版本是 AC1032。不同版本的块结构、字符串编码方式、压缩算法都不一样光是版本兼容就够写一个模块。浏览器这边更麻烦。早年 IE 时代确实有跑通的方案——把 ActiveX 控件嵌进页面本质是调用本地已经装好的 CAD 程序渲染成图再贴回网页。这条路现在彻底断了NPAPI 插件体系被主流浏览器移除ActiveX 只有 Windows 上的老 IE 支持。所以今天谈网页打开 CAD实际是在谈两件事之一要么服务端把图纸转成浏览器能吃的格式要么把解析内核编译成 WebAssembly 塞进前端。1.2 图纸不是几条线渲染对象的种类比你想的多很多没画过图的同学会以为 CAD 图纸就是线加圆加文字。实际上一个正常建筑图里会出现这些对象直线 LINE、多段线 LWPOLYLINE/POLYLINE、圆弧 ARC、圆 CIRCLE、椭圆 ELLIPSE、样条曲线 SPLINE、块参照 INSERT、属性 ATTDEF/ATTRIB、文字 TEXT、多行文字 MTEXT、填充 HATCH、标注 DIMENSION、引线 LEADER、光栅图像 IMAGE、面域 REGION、三维实体 3DSOLID……每个对象的参数结构都不一样多段线还带凸度bulge用来在顶点之间插入圆弧段填充还带边界路径和填充图案定义。比对象更磨人的是属性系统。一条线的颜色可能是固定的索引色ACI 表里的 1 到 255也可能是随层 ByLayer也可能是随块 ByBlock还可能是真彩色 RGB。线宽可能是固定值也可能随层实际显示时还可能被打印样式表CTB/STB覆盖。线型是虚线还是点划线取决于 LTYPE 表里定义的一组画-空数组。这些全都要在渲染时逐级解析继承关系一层套一层。1.3 三个隐藏门槛字体、大坐标、实体规模第一是字体。国内建筑和机械图纸大量使用 SHX 形字体这是一种笔画式矢量字体不是 TrueType。浏览器没有内置的 SHX 渲染能力图纸里指定的字体文件也常常随图纸一起丢失结果就是满屏问号。第二是大坐标。测绘、总图、市政类图纸经常直接使用大地坐标系X 坐标动辄六七位数、上千万。WebGL 和 Canvas 内部大量使用 32 位浮点有效精度只有约 7 位十进制数字把千万级坐标直接塞进去图元位置会肉眼可见地抖动、重叠、错位。第三是实体规模。一个大型总图或者管线图实体数量轻松到几十万。如果每个实体都创建一个 DOM 节点SVG 路线或者一次独立的绘图调用帧率会掉到个位数。2. 四条技术路线的真实取舍2.1 服务端出图上线最快但基本只能看最省事的做法是在服务端把 DWG 渲染成图片或 PDF。思路是把图纸按缩放层级切成瓦片前端用类似地图瓦片的方式拼起来或者直接把 PDF 丢给前端配合 pdf.js 展示。优点非常明显前端逻辑极轻兼容性极好几万实体也就是服务端多跑几秒的事还能顺手做缩略图和水印。代价是失去了真正意义上的交互。你没法点选一条线看它的属性没法按图层显隐没法测量距离缩放超过瓦片层级就糊。如果需求只是让工人在手机上看一眼图纸长什么样这条路线性价比最高如果对方下一秒就要框选统计工程量那这条路直接作废。2.2 服务端转中间矢量格式在线 CAD 平台的主流选择这是我见过的大多数商业化在线 CAD 平台采用的架构。服务端跑一个完整的 CAD 解析内核把 DWG 还原成内存里的实体集合再序列化成自定义的 JSON 或者精简矢量格式前端拿到之后用 Canvas 或 WebGL 绘制。前端只负责照着数据画不承担任何格式解析压力包体可以控制在几百 KB。关键设计在于转成什么。我的做法是定义一套扁平化的图元描述每个图元只保留渲染必需的字段用数字枚举代替字符串用紧凑数组代替对象字段名配合 gzip 传输。同一张图纸原始 DXF 文本 8 MB转成这套格式大概 1.2 MB压缩后 300 KB 出头加载速度完全不是一个量级。这条路的成本在于你得有一个能稳定解析各种版本 DWG 的服务端内核还要处理转换任务的排队、超时、失败重试。图纸转换是个重 CPU 操作一张复杂总图可能跑十几秒必须做成异步任务加进度反馈不能让用户在页面上干等。2.3 浏览器内跑 WebAssembly 内核数据不出前端把 C/C 写成的 CAD 解析内核编译成 WebAssembly让浏览器直接解析 DWG是近几年越来越常见的选择。它最大的优势不是性能而是数据不离开浏览器——图纸不用上传到任何服务器对于设计院、军工配套这类对图纸保密极其敏感的客户这一条几乎是决定性的。代价也很实在。WASM 包体普遍在几 MB 到十几 MB 之间首次加载慢需要做懒加载和缓存策略解析时内存占用高一张 20 MB 的 DWG 可能吃掉几百 MB 内存移动端容易直接被系统杀掉页面解析本身是同步的跑在主线程上会冻结界面必须放进 Web Worker再通过 OffscreenCanvas 或者 transferable 数据把结果交给渲染线程。这条路我只有在客户明确要求图纸不出本机时才会选。2.4 纯 JavaScript 解析 DXF轻量场景的甜点区如果图纸能提前转成 DXF很多设计院内部交换用的就是 DXF前端就有一个非常轻的选项用纯 JS 解析 DXF 文本直接画。这类库通常只有几十 KB覆盖常用图元不需要任何后端。缺点同样明确只吃 DXF文本格式体积大同样内容的 DXF 通常是 DWG 的三到五倍解析大文件时字符串处理会拖慢主线程而且不同软件导出的 DXF 兼容性参差不齐。路线前端交互能力首屏速度后端成本格式覆盖适合场景服务端出图弱仅缩放平移快中全版本只看不改的移动端预览转中间矢量格式强中需等转换高全版本商业化在线 CAD 平台WASM 前端解析强慢首次无全版本图纸保密要求高的私有部署纯 JS 解析 DXF中快无仅 DXF内部工具、轻量预览选型时我一般会问三个问题图纸能不能上传到服务器用户需不需要点选和测量图纸平均多大这三个答案基本就锁定了路线。3. 把图纸真正画到画布上一条完整的渲染链路3.1 先看懂 DXF 的组码结构不管走哪条路线理解 DXF 的组码结构都有帮助因为它是理解实体-属性-表三层关系的入口。DXF 用一对一对的行表示数据奇数行是组码数字偶数行是值。一个最简单的文件片段长这样0 SECTION 2 ENTITIES 0 LINE 8 0 10 100.0 20 200.0 11 300.0 21 200.0 62 1 0 ENDSEC 0 EOF组码0表示这是个新对象值是对象类型比如 LINE、CIRCLE。组码8是图层名10/20/30是起点 XYZ11/21/31是终点62是颜色索引。圆的圆心用10/20半径用40。文字内容用1高度用40旋转角用50。这些组码是公开规范写解析器的时候基本就是一张对照表加状态机。真正需要留意的是表和块。图层信息不在 ENTITIES 段里而是在 TABLES 段的 LAYER 表线型在 LTYPE 表块的成员实体在 BLOCKS 段。所以解析顺序必须是先读表、再读块定义、最后读实体段否则渲染时拿不到图层颜色和块内图元的真实位置。3.2 视口与坐标变换所有渲染问题的地基CAD 的世界坐标 Y 轴向上Canvas 的屏幕坐标 Y 轴向下这个翻转如果不处理图纸会上下颠倒。我习惯封装一个视口对象把世界坐标和屏幕坐标的换算、缩放、平移全部收进去class Viewport { constructor() { this.scale 1; // 世界单位 - 屏幕像素 this.tx 0; // 平移量像素 this.ty 0; } // 世界坐标转屏幕坐标Y 轴翻转 toScreen(x, y) { return { x: x * this.scale this.tx, y: -y * this.scale this.ty }; } toWorld(sx, sy) { return { x: (sx - this.tx) / this.scale, y: -(sy - this.ty) / this.scale }; } // 以屏幕某点为锚点缩放锚点下的世界坐标保持不动 zoomAt(sx, sy, factor) { const next this.scale * factor; const k next / this.scale; this.tx sx - (sx - this.tx) * k; this.ty sy - (sy - this.ty) * k; this.scale next; } }zoomAt里那两行推导值得说一下因为很多人第一版都会写错导致缩放时图形跑偏。目标是让鼠标位置对应的世界坐标在缩放前后保持不变。屏幕坐标公式是sx x * scale tx所以世界坐标x (sx - tx) / scale。设缩放前世界坐标为x0缩放后为x1要求x0 x1(sx - tx) / scale (sx - tx) / (scale * k) tx sx - (sx - tx) * k同理解出ty。这样滚轮缩放时光标下的那个点会像被钉子钉住一样纹丝不动操作手感立刻上一个档次。初始化视口时通常先读取图纸所有实体的包围盒算出宽高然后让scale等于画布可用宽度除以图纸宽度再把图纸中心平移到画布中心function fitView(vp, bbox, canvasW, canvasH, padding 20) { const w bbox.maxX - bbox.minX; const h bbox.maxY - bbox.minY; const scale Math.min( (canvasW - padding * 2) / w, (canvasH - padding * 2) / h ); vp.scale scale; const cx (bbox.minX bbox.maxX) / 2; const cy (bbox.minY bbox.maxY) / 2; vp.tx canvasW / 2 - cx * scale; vp.ty canvasH / 2 cy * scale; }3.3 线型、线宽、颜色三个最容易做错的地方颜色解析要处理继承链。图元自身有颜色就用自身是 ByLayer 就往图层要是 ByBlock 就往块参照要。索引色需要一张 ACI 对照表1 到 9 是标准色10 到 249 是色轮250 到 255 是灰度。真彩色则直接取 RGB 值。我一般会在解析阶段就把继承链拍平渲染时只读最终值省掉渲染循环里的判断开销。线宽有个坑DXF 里的线宽值组码 370是以 0.01 毫米为单位的整数枚举不是像素。屏幕上怎么显示取决于你设定的每屏幕像素对应多少毫米。通常做法是给一个最小可见宽度比如 1 像素超过阈值才按比例展示否则细线全部糊成一片。至于打印样式表 CTB如果图纸带了理论上会覆盖线宽和颜色但实际预览场景里我一般先忽略除非客户明确要求还原打印效果。线型相对简单LTYPE 表里存着一串数字正数表示画线长度负数表示空白长度单位是图形单位需要乘上当前缩放比例换算成像素然后调用ctx.setLineDash()。要注意缩放比例很大时虚线段会密到看不见所以得给 dash 数组做一次过滤小于 0.5 像素的段直接合并。3.4 多段线的凸度圆弧到底怎么画LWPOLYLINE 的每个顶点可能带一个凸度值bulge它等于圆弧包含角四分之一的正切值bulge tan(θ/4)θ 是圆弧的包含角有符号正数表示逆时针。这是 2D 图纸里画圆弧段最常用的方式不处理的话所有倒角、圆角全会变成直角。换算成圆心和角度的过程是这样的function bulgeToArc(x1, y1, x2, y2, bulge) { const theta 4 * Math.atan(bulge); const dx x2 - x1, dy y2 - y1; const c Math.hypot(dx, dy); if (c 0) return null; const r c / (2 * Math.sin(theta / 2)); // 有符号半径 const h c / (2 * Math.tan(theta / 2)); // 弦中点到圆心的距离 const mx (x1 x2) / 2, my (y1 y2) / 2; // 弦向量逆时针旋转 90 度得到单位法向 const ux -dy / c, uy dx / c; const cx mx ux * h; const cy my uy * h; return { cx, cy, r: Math.abs(r), start: Math.atan2(y1 - cy, x1 - cx), end: Math.atan2(y2 - cy, x2 - cx), anticlockwise: bulge 0, }; }h这个公式有个很漂亮的特性当包含角接近 180 度时tan(θ/2)趋于无穷h趋于 0圆心正好落在弦中点当包含角趋近 360 度时圆心被推到无穷远半径变得极大。所以对接近整圆的圆弧我一般会做一次判断直接按整圆处理避免浮点溢出。绘制时把弧转成 Canvas 的arc(cx, cy, r, start, end, anticlockwise)就行注意坐标系已经翻转anticlockwise的语义也要跟着反过来这一点在调试时特别容易搞混——图形看着是对的但弧的方向反了闭合多段线的填充就会出现缺口。3.5 图层的显隐和点选查询怎么接图层控制本质上是给渲染循环加一个过滤器维护一个Set存隐藏图层名绘制前判断当前图元图层是否在集合里。更细一点还要处理图层关闭和图层冻结的区别——冻结图层除了不显示还要跳过包围盒计算否则一张被冻结的巨大图框会把你的初始视图拉得很远。图元颜色索引为负数是图层关闭的标记这个细节很多人都漏掉。点选查询需要反过来做一次命中检测。简单图形可以用包围盒加距离判断多段线就逐段算点到线段的距离。为了性能通常会先用四叉树或者网格索引把视口范围内的图元筛出来再逐个测距。命中之后把实体 ID 抛给上层打开属性面板展示图层、颜色、线型、坐标这些信息。这套逻辑不复杂但要在几万实体上做到点击响应在 50 毫秒内索引结构是必须的。4. 那些只在深夜才会冒出来的坑4.1 SHX 字体缺失文字全变问号这是国内图纸最普遍的问题。图纸里文字样式指向hztxt.shx、tssdeng.shx这类形字体浏览器里根本没有。我的处理方案是三步走解析文字样式表取出每个样式的字体文件名维护一张映射表把常见 SHX 字体名映射到可用的 Web 字体黑体、宋体、思源黑体这类映射表里没有的统一走默认字体并保留原始宽高比设置。映射表要按图纸类型维护。机械图纸常用的gbcbig.shx一般映射到等宽黑体建筑图纸的hztxt.shx映射到常规黑体效果比较接近。关键参数是宽度因子组码 41SHX 字体的字宽和 TrueType 差异很大不加补偿的话文字要么挤成一团要么松散到跑出图框。我的经验值是给映射后的字体额外乘一个 0.85 到 1.0 之间的宽度系数具体看图纸宁可略窄也不要溢出。还有一个细节SHX 字体是笔画字体笔画粗细不随字号变化看起来比较骨感TrueType 是描边字体字号越大笔画越粗。同一个文字样式在两种字体下的视觉重量不同这点在对照效果时要有心理准备别以为是自己画错了。4.2 大坐标导致的精度抖动前面提过测绘类图纸经常直接使用大地坐标。假设某条线的坐标是 (38512345.678, 5123456.789)scale取 0.01那么屏幕坐标大概是 385123 像素级别——数值没问题但 WebGL 里float32只有约 7 位有效数字这个量级的坐标在转换后只剩两位小数精度缩放放大之后线条会跳。解决办法是原点平移在解析阶段算出图纸包围盒的中心把所有坐标减去这个中心存成相对坐标渲染时只用相对值。这样数值量级从千万降到几百精度完全够用。需要在界面上展示绝对坐标时再把偏移量加回去。这个技巧在 GIS 和三维渲染里是标准操作但处理 CAD 图纸时很多人会忘。4.3 几万实体时的性能优化套路性能优化有几个层级按收益从高到低排第一层是视口裁剪。只绘制包围盒与当前视图相交的图元简单但效果显著一张总图缩小到全览时可能只有几百个图元在视口内。第二层是批量合并。同一图层、同一颜色、同一线宽的直线可以合并成一个Path2D对象一次stroke()画完。我实测下来把几千条短直线合并成一个路径绘制耗时从 40 毫秒降到 3 毫秒左右。注意合并之后就不能单独修改某一根线的样式了所以要在解析阶段就按样式签名分组。第三层是把渲染挪出主线程。用 Web Worker 加OffscreenCanvas解析和绘制都在后台线程做主线程只负责接收位图。这条路在桌面浏览器上很稳但移动端的支持情况参差不齐需要在初始化时探测能力不支持就降级回主线程渲染。第四层是渐进式渲染。先把视口内图元按重要性分批第一批画完就显示出画面剩下的用requestAnimationFrame分帧补齐。用户感知到的打开速度是第一批的时间而不是全部画完的时间。第四层还有个进阶版本按几何尺度分级。缩放很小时忽略文字、标注、填充这些细节图元放大到一定程度再加载。这个策略能让几百万实体的图纸也有可用的首屏表现代价是切换缩放级别时会有一瞬间的图元闪烁需要做淡入过渡来掩盖。4.4 中文乱码与编码问题DXF 的文本段编码是个历史遗留问题。老版本 DXF 里的中文通常是 GBK 或者 GB2312 编码新版本可能是 UTF-8还有的图纸带着$DWGCODEPAGE变量声明代码页。用TextDecoder解码时要先读这个变量按声明选编码读不到就按 GBK 试国内图纸概率最高再不行按 UTF-8 兜底。WASM 内核解析的情况稍好一般内核内部会处理编码转换但输出到 JS 字符串时仍可能出现半个汉字被截断的情况表现为末尾一个乱码方块。这不是编码错是字节切分位置不对需要在输出层按字符边界重新对齐。4.5 填充、块和布局空间的三个暗坑填充 HATCH 的边界通常是一组闭合路径还带孤岛检测。Canvas 的填充有nonzero和evenodd两种规则CAD 默认用奇偶规则处理孤岛所以画填充时必须显式指定ctx.fill(evenodd)否则带孔洞的填充会变成实心一块。块参照 INSERT 要处理三件事块定义里的图元坐标需要经过缩放-旋转-平移的复合变换块可以嵌套带属性的块比如轴线编号需要把 ATTRIB 的内容按 ATTDEF 的定位方式画上去。我踩过最深的坑是不均匀缩放的块——X、Y 方向缩放比例不同此时块内的圆弧会变成椭圆如果直接按圆弧处理就会画错必须降级成椭圆路径。布局空间Layout就更麻烦了。模型空间里是一比一的图形布局空间里是视口窗口加图框、标题栏、比例标注。要正确显示布局你得实现一套裁剪区域加独立变换矩阵的机制每个视口内部有自己的缩放和坐标原点。如果不是刚需我一般建议只支持模型空间布局空间转成图片展示性价比高得多。5. 工程化落地从能跑通到能上线5.1 转换任务做成异步队列服务端转换是重 CPU 操作必须异步化。我的做法是上传后立刻返回一个任务 ID转换在后台队列里跑前端通过轮询或者长连接拿进度。队列要做两件事限制并发数一般等于 CPU 核数以及设置超时熔断超过阈值就杀掉进程并标记失败避免一个畸形文件把整个队列堵死。进度反馈的粒度也有讲究。单纯报转换中用户会焦虑我一般按解析、转换、序列化三个阶段各报一次再配上实体计数让用户看到已处理 12 万实体等待体验会好很多。5.2 缓存和增量加载同一张图纸的转换结果应该缓存。缓存键用文件内容哈希而不是文件名因为文件名会被改、会被重传。缓存命中时首屏能从十几秒降到几百毫秒对体验的提升是数量级的。大图纸还要考虑增量加载。把实体按空间网格切成若干块前端先拿第一屏所在的块用户平移时再请求相邻块配合预取策略提前加载视野边缘外的两格滚动时基本不会有等待感。这套东西和地图瓦片的思路完全一致做过 WebGIS 的同学上手会很快。5.3 移动端的触控和性能边界移动端有两个硬约束内存和触控。内存方面尽量不保留原始解析结果渲染完就释放中间结构只留精简的渲染数据。触控方面单指拖拽平移、双指捏合缩放是最基本的要注意防止和页面滚动冲突在画布上监听touchmove时调用preventDefault同时把touch-action设为none。双指缩放的锚点应该是两根手指的中心点不是画布中心否则图形会飘。实现时记录起始两指距离和中心点移动时算比例因子调用前面那个zoomAt锚点传中心点屏幕坐标即可。5.4 权限和水印工程图纸的外发管控是刚需。至少要做三件事预览链接带有效期过期自动失效打开时按用户 ID 叠加半透明水印水印跟着视口变换走斜向平铺在整个画布上禁用右键和常见的截图快捷键只能算心理安慰真正有效的是服务端不返回原始文件只返回渲染数据。如果走 WASM 前端解析的路线图纸文件会完整下发到客户端这时候水印和链接有效期就是唯一的约束手段。这一点在选型阶段要和业务方讲清楚不要等上线了才被安全部门叫停。6. 我在几个项目里攒下来的取舍经验先说一个最实用的结论不要一上来就追求完全还原 CAD 的显示效果。第一版只要能正确显示线条、图层、基本文字就已经能满足 80% 的查看需求。剩余的 20%——打印样式还原、复杂填充、三维实体、动态块——每一项的投入产出比都很低除非甲方明确指名要否则不要主动碰。第二渲染层和解析层一定要解耦。我在第一个项目里把解析和绘制混在一起写后来想换渲染后端从 Canvas 2D 换到 WebGL时几乎重写了一遍。正确做法是解析层只管输出标准化的图元数据渲染层只管消费这些数据中间用一套明确的接口隔开。这样换渲染器、加缓存、做增量加载都是局部改动。第三坐标精度问题要在设计阶段就解决不要等出问题了再补。我吃过这个亏一个市政项目上线两周后客户反馈放大之后线条会跳动排查了半天才定位到大坐标精度最后做了原点平移连带把命中检测和标注定位的逻辑全改了一遍。如果一开始就用相对坐标存图元这些返工全都可以省掉。第四实体的属性继承颜色、线宽、线型尽量在解析阶段拍平不要留到渲染时动态查询。渲染循环里的每一次属性查找乘以几十万实体都是一次性能灾难。拍平的代价是内存占用大一点但换来的是渲染逻辑简单、调试容易、性能可控。最后分享一个调试技巧画图渲染出问题时不要盯着整张图找先用一个极简的测试文件就几条线、一个圆、一段文字、一条带凸度的多段线跑一遍确认基础链路没问题再逐步加复杂度。我自建的这套测试文件有十几个从纯直线到带填充带块带布局每个都对应一类曾经踩过的坑。有了这套回归用例后面每次改渲染逻辑都心里有底不会再出现修好 A 弄坏 B的情况。