上个月有个做工程管理系统的朋友找我，说他们接了个需求：把甲方发来的一批 DWG 图纸在网页上打开，还要能点选图元看属性，最后把数据落到自己的业务库里。这其实是特别典型的 DWG 数据交换场景，只不过大部分团队在动手之前，都没认真拆过“交换”这两个字里到底藏着几条路径。他们的第一反应是找一个能读 DWG 的库，读出来不就完了？结果试了两个星期才发现，预览要一套东西、抽数据要另一套东西、回写又是第三套，前面选错了后面全要返工。这篇就把我这些年做 DWG 数据交换方案选型的思路摊开讲：从链路拆解、路线对比、指标取舍，到几个真实会翻车的细节。不管你是要给系统加个图纸预览，还是要做批量转档归档，或者要把图里的设备参数扒到数据库里，应该都能在里面找到对应的判断依据。
1. 先把“交换”拆开：DWG 流出的四条真实链路
很多人一上来就问“哪个库能读 DWG”，这个问题本身就不成立，因为“读”这个词在图纸场景里至少对应四种完全不同的活儿。同一份 DWG 文件，给施工方看是一回事，给业务系统算是一回事，交给业主归档又是一回事，改完再还回去还是另一回事。这四件事对技术底座的要求差别极大，有的只要几何轮廓，有的必须拿到属性值，有的必须写回文件，有的干脆只要一张图。
我一般建议团队先把需求按链路归类，再去看方案。为什么？因为每条链路的“保真度下限”和“可接受的损耗”完全不同。预览链路丢一点线宽能忍，抽数据链路丢一个属性字段就是事故；转档链路丢几个不常用的对象还能解释，回写链路把动态块炸成静态块，设计方第二天就会打电话过来。链路不定，选型就是盲选。
下面这四条链路，是我在做项目时最常用的拆法，基本能覆盖 90% 的需求。
1.1 只要看得见：预览与轻量化浏览
这条链路的目标很朴素：让人在浏览器或者手机上把图打开，能缩放、平移、切图层、量个距离、圈个问题。使用方通常是没有装专业制图软件的人，比如现场施工、监理、审图、销售，甚至客户自己。
这类需求的关键词是“轻量”。你不需要拿到每一个图元的完整语义，只需要把画面还原出来。字体对不对、填充有没有、标注清不清楚，才是这类用户真正在意的。一个尺寸标注显示成“?”或者尺寸线跑到图外面去，用户立刻就会说“你这系统不对”。
我见过不少团队在这条链路上走了弯路：为了追求“可交互”，硬着头皮在 Web 端做几何解析，结果一个几十兆的总图直接把浏览器干趴下。其实预览链路的正确姿势往往是“服务端转、客户端看”——把 DWG 在服务端转成一种轻量的中间表示（矢量切片、SVG、PDF，或者专门优化的私有格式），前端只做渲染和交互。代价是丢掉一部分语义，收益是性能和兼容性都能稳住。
提示：预览链路的验收标准不要写成“能打开”，要写成“某一批真实图纸打开后，字体正确率、标注可见率、填充还原率达到多少”。否则测的时候全绿，上线第一天就挨骂。
1.2 只要能算：图元与属性的结构化提取
这条链路的目标是把图纸变成数据。典型场景：把图里的设备编号、管径、标高、材料表抽出来写进资产库；把块属性里的台账信息同步到运维系统；把图层名当作分类依据做统计分析。
它和预览链路几乎是反过来的——画面好不好看无所谓，字段对不对、覆盖全不全才是命门。这时候你需要的是真正的解析能力：能遍历实体、能读块参照和块属性、能读扩展数据、能读图层和线型表、能沿着扩展字典往下挖。
这里我得强调一个容易忽略的点：属性信息在 DWG 里有好几种存放方式，块参照上的属性值、属性定义的默认值、扩展数据里的自定义键值对、扩展字典里的对象、还有写进文字实体的“伪属性”，来源不同，读法完全不同。你在选型时要问的不是“能不能读属性”，而是“能不能读我这种图的属性”。这两个问题的答案经常不一样。
1.3 只要交得出：格式转换与版本降级
交付链路是最容易被低估的。它看起来只是“把 A 格式存成 B 格式”，实际上牵扯到版本兼容、对象降级、布局处理、外部参照打包等一堆事。
最常见的诉求是版本降级：对方系统老，只认低版本文件；或者归档要求统一成某个固定版本。另一类是格式转换：转 PDF 给业主签字，转图片做封面，转 DXF 给第三方系统导入。
我个人的经验是，格式转换的坑八成不在转换本身，而在“转换完之后对不对”。高版本里的动态块、注释性对象、材质、字段、地理坐标，降级过程中会被静默处理掉，程序不报错，文件也能打开，但图已经不是你原来那张图了。所以这条链路的选型重点，是看方案能不能给出“降级损耗清单”，而不是只看它支不支持目标版本。
1.4 还要改得动：带修改的回写与合并
这是四条链路里最难的一条，也是报价差得最远的一条。需求通常是：在线批注、在线改图、在线签审之后，把修改结果写回 DWG 交还给设计方。
写回比读取难一个数量级。读取是“把文件翻译成人能看懂的东西”，写回是“在不破坏原有结构的前提下，往一个复杂的对象网络里插东西”。而且写回之后，文件还要能被原来的制图软件正常打开、正常编辑，不能出现“能打开但一编辑就崩”的情况。
我处理这类需求时会先问一句：回写的是“新增图元”还是“修改已有图元”？前者相对好办，往模型空间里加实体、加批注即可；后者麻烦得多，需要稳定的图元标识、需要处理图层锁定、需要处理块内编辑的坐标系变换。很多轻量方案在这条链路上直接出局，因为它们的定位就是只读。
2. 四类技术路线的能力边界
链路拆清楚了，接下来才轮到看方案。市面上能处理 DWG 的技术路线，大致分四类，能力边界差别很大。我不打算按“哪个好”来排，因为选型从来不是选最好的，是选最合适的。下面按“能力从强到弱、成本从高到低”的顺序说。
2.1 原生授权内核：能力天花板，约束也最硬
第一类是图纸格式的原始提供方给出的原生开发接口，以及配套的独立读写组件。它的优势几乎没法替代：对新版本格式的支持最快，对自定义对象的支持最完整，渲染结果和原软件的一致性最高，读和写都覆盖得比较全。
代价也很明确。第一是平台绑定，多数情况下主战场在 Windows，跑在 Linux 上要么功能阉割，要么需要额外的适配层，容器化部署会很难受。第二是授权，按席位或者按服务器收费，商用项目里这是一笔每年都要出的固定开销，而且往往有调用方式上的限制。第三是部署复杂度，运行时依赖一堆东西，镜像体积大，跨机器迁移容易出环境问题。
我的判断标准是：如果你的项目里出现了“自定义对象必须正确显示”“回写后必须能被原软件正常编辑”这类硬要求，那基本只能往这条路走，别的方案都是在赌。
2.2 跨平台商业内核：一次接入，多端兜底
第二类是行业联盟或者第三方厂商做的跨平台内核，提供 C++、C#、Java 等多种语言绑定，Windows 和 Linux 都能跑，读写能力也比较完整。
这类方案在工程系统里用得非常多，因为它的性价比区间很舒服：比原生方案便宜，比开源方案可靠，Linux 支持对现在的容器化部署很友好。它的短板主要在自定义对象上——遇到专业领域的扩展对象，如果没有对应的扩展模块，还是会被降级成代理图形，只能看轮廓，读不到参数。
还有一个隐形成本要注意：大版本升级时 API 会有变动。我吃过一次亏，升了一个大版本，几个取属性的接口签名变了，编译能过但语义变了，跑出来的数据少了一批字段，靠对账才发现的。所以用这类方案，一定要把版本号钉死，升级前跑一遍全量回归。
2.3 开源读写库：能跑起来和能上生产是两回事
第三类是开源社区维护的读写库。它的吸引力很直接：免费、可改、源码在手，出问题能自己进去看。
但我在生产环境里用它的次数不多，原因不是它不好，而是它的能力边界经常和业务预期错位。典型情况是：标准实体读得不错，遇到复杂实体就开始丢；写回能力弱，很多时候只能写简单的几何；新版本格式的支持往往滞后，遇到刚出的版本文件直接报错。
还有一个容易被忽视的点是合规。开源不等于没有约束，许可证条款、格式相关的法律风险、社区维护的持续性，都得提前评估。我一般建议：开源方案可以用在内部工具、离线批处理、一次性迁移这类容错高的场景，别拿它去扛对外的核心业务。
2.4 命令行工具与云端转换服务：把重活外包
第四类是把转换这件事外包出去：用现成的命令行工具做批处理，或者调用云端的转换接口。
这条路的好处是启动快，几天就能出效果，不用自己啃格式细节。适合的场景也很清楚：批量归档、一次性数据迁移、低频的格式转换。
问题在于可控性。命令行工具的报错信息往往很粗，一个文件失败了你不知道是字体问题还是内存问题；云端服务的每一次调用都要把图纸传出去，数据外发的合规审查在很多项目里是过不去的坎；按量计费在图纸量大的时候账单会很难看。
注意：如果决定走云端转换，先把“图纸能不能出内网”这个问题在法务和甲方那边确认掉，别等系统做完了才发现这条路封死。
3. 六个真正卡人的选型指标
方案看得差不多了，接下来是拍板。我列了六个在实际项目里最容易被忽略、但事后最容易变成事故的指标。它们的重要程度和“方案宣传页上写的东西”往往不成正比。
3.1 版本兼容：文件头里的那串标识才作数
DWG 的版本不是靠扩展名区分的，是靠文件头里的版本标识。低版本文件用高版本软件打开没问题，反过来就不行。做交换方案，第一件事是把“我方需要支持哪些版本读写”列成一张表。
我一般按这几个档位来划分需求：很老的版本、中期版本、较新版本、当前主流版本。中间那几个版本的文件结构变化比较大，尤其是引入新压缩和新对象模型的那一版，很多老库在这一档上直接失守。而最近这些年的大版本，文件结构反而相对稳定，新版本主要是在增加少量对象类型。
降级这件事要单独说。从高版本存成低版本，程序不会告诉你丢了什么。我整理过一份常见的损耗清单，你可以拿去当验收用例：
| 降级后可能丢失或退化的内容 | 表现 | 影响 |
|---|---|---|
| 动态块 | 变成静态块，参数丢失 | 无法再调参数，只能看到当前状态 |
| 注释性对象 | 注释比例失效，文字大小错乱 | 出图时字要么太大要么太小 |
| 字段 | 变成静态文字 | 后续无法自动更新 |
| 材质与渲染属性 | 丢失 | 影响效果图类交付 |
| 地理坐标信息 | 丢失或偏移 | 对接 GIS 时坐标全错 |
| 点云与大体量参考 | 被剥离 | 图面缺内容 |
3.2 实体覆盖率：自定义对象是真正的分水岭
标准实体（直线、圆弧、多段线、文字、标注、填充、块）各家方案支持得都还行。真正拉开差距的是专业领域的自定义对象，比如建筑里的墙门窗、机电里的管线设备、市政里的构筑物。
这类对象在文件里是以扩展对象的形式存在的，只有带对应扩展模块的环境才能正确解析。没有模块的环境打开文件，会把它替换成代理图形——一个只能显示轮廓、不能编辑、也读不到参数的占位物。
所以选型时的关键问题是：我的图纸里有没有这类对象？占比多少？我需要读到它们的参数吗？如果只是要看个大概，代理图形够用；如果要抽设备参数、要做工程量统计，那就必须解决扩展模块的问题，绕不过去。
3.3 保真度分级：几何对了不等于图对了
“转换成功”这四个字太模糊了。我一般把保真度分成几层来看，每一层的验收方式都不一样。
| 保真层级 | 检查内容 | 常见失分点 |
|---|---|---|
| 几何层 | 线条位置、长度、角度是否一致 | 圆弧方向反了、多段线凸度丢失 |
| 样式层 | 线型、线宽、颜色、图层是否保留 | 线型比例错、ByLayer 变成固定色 |
| 文字层 | 字体、字高、对齐方式、中文是否正常 | 中文变问号、字宽比例错 |
| 标注层 | 标注样式、测量值、箭头形式 | 标注被炸开成线和文字 |
| 布局层 | 图纸空间、视口、打印样式 | 视口比例错、只导出了模型空间 |
| 参照层 | 外部参照、光栅图的路径与绑定 | 参照丢失、图片显示为红框 |
这张表我一般直接当作测试用例清单，每上一个方案就跑一遍，比看十页说明文档管用。
3.4 吞吐与并发：真正的瓶颈是单文件内存
性能这件事，很多人只盯着“每秒处理多少个文件”，其实瓶颈往往在单个大文件上。一张上百兆的总图，解析时的内存峰值可能是文件体积的好几倍，几个并发一起来，机器直接 OOM（内存溢出）。
我的做法是分档处理：小文件走高频队列，大文件单独走低并发通道，并且给每个任务设内存上限和超时。批量任务不要做成“一次性把文件列表全丢进去”，要做成有界队列加背压，否则高峰期的失败率会非常难看。
另外提醒一句，解析速度在冷启动和热启动下差别很大，第一次加载字体、加载配置会慢很多。压测的时候别只测热态，冷态才是用户第一次打开时的真实体验。
3.5 授权与部署：算五年总账，别只看首年
商业内核的报价方式五花八门：按席位、按服务器、按年订阅、按调用量、按 CPU 核数。选型时一定要把部署形态和计费方式放在一起算。
举个我遇到过的情况：方案按服务器授权，看起来很划算，但为了扛并发要开多台实例，每台都要一份授权，总价立刻翻倍。另一种是按调用量计费，平时很便宜，赶上年底集中归档，一个月的账单能顶半年。
还有部署约束。有些方案要求固定的运行环境，容器化以后镜像好几个 G，每次发布都痛苦；有些方案在离线内网部署时需要额外的授权文件更新流程，运维要专门排一个人。这些在 POC 阶段都体现不出来，上线三个月以后全变成运维负担。
3.6 可控性：出事的时候你能不能定位
最后一个指标最虚，但长期价值最高：出问题的时候，你能不能自己定位。
我判断的标准很具体：转换失败时，日志里有没有文件名、失败阶段、错误类型；能不能拿到单文件复现的最小路径；有没有办法跳过某个特性做降级处理；升级后行为变化有没有变更说明。
一个只能告诉你“转换失败”的方案，和一个能告诉你“第 37 个实体类型 X 不支持，已跳过”的方案，运维成本差着数量级。前者意味着每次出问题都要提工单等回复，后者意味着你自己半小时就能定位。
4. 三条链路的方案组合与落地细节
前面讲的是“怎么选”，这部分讲“选完怎么落地”。同样是预览，做在浏览器里和做在客户端里，技术组合完全不一样。我挑三条最常见的链路，把组合方式和实现细节说清楚。
4.1 在线预览批注：转换与渲染要分工
预览链路我推荐的组合是：服务端负责把 DWG 解析并转换成轻量中间格式，客户端只负责渲染和交互。这个分工的好处是，解析这件重活只做一次，之后所有用户打开的都是同一份中间产物，性能和一致性都能保证。
具体做法是在文件入库时触发一次转换任务，产出几样东西：一份矢量化的画面数据（按图层组织，方便前端做图层开关）、一份图元索引（用于点选和查询）、一份缩略图、以及原始文件的元信息（版本、单位、图纸范围）。
这里有个设计选择值得说一下：图层开关到底在前端做还是后端做。前端做交互快，但要一次性把全部矢量数据推给浏览器，大图会卡；后端做请求多，但可以按需加载。我的经验是按图的大小分流，小图前端一次性加载，大图按范围分块加载。
批注层的设计也有讲究。批注不要直接画在转换后的画面上，要单独存一份坐标数据，坐标用图纸坐标系而不是屏幕坐标系，这样缩放、旋转、换设备打开都能对齐。批注和原始图元之间用图元 ID 关联，这个 ID 要在同一份文件多次转换之间保持稳定，否则用户刷新一次批注就飘了。
4.2 批量转档归档：队列、重试与质检缺一不可
批量转档看起来最简单，实际上运维问题最多。我一般的架构是：文件先入队列，转换 Worker 从队列取任务，转换完成写回结果并记录状态，失败的进重试队列，重试若干次仍失败进人工处理队列。
几个必须做的细节。第一是幂等，同一个文件重复投递不能产生两份结果，用文件的唯一标识加哈希做去重。第二是超时隔离，单个文件设置硬超时，超时就杀掉进程，否则一个畸形文件能把整个 Worker 卡死。第三是质检，转换完不要直接标成功，要检查产物是否为空、页面数是否异常、文字是否全是问号，这三项能挡住大部分静默失败。
还有一个经验：大文件和小文件一定要分队列。混在一起跑，一个大文件就能把后面的小文件全堵住，用户看到的进度条半天不动，体验极差。
4.3 参数抽取进库：字段映射表比代码更重要
抽取这条链路，我见过最多的失败原因是“字段映射没想清楚就开写代码”。图纸里的属性命名五花八门，同一个设备编号，有的图里叫“设备编号”，有的叫“编号”，有的叫“EQ_NO”，还有的写在扩展数据里。
正确的顺序是先做映射表，再做代码。映射表里要写清楚：目标字段名、来源类型（块属性 / 扩展数据 / 文字内容 / 图层名）、来源键名、是否必填、默认值、转换规则（比如单位换算、编码替换）。
代码层要做的是幂等写入：同一张图重复抽取，结果要覆盖而不是重复插入，用“图纸ID + 图元ID”做唯一键。还要做覆盖率统计，每批次跑完统计一下各类字段的抽取成功率，低于阈值就告警。这个统计比任何日志都有用，因为字段缺失往往是静默发生的，不统计根本发现不了。
5. 那些文档里不会写的翻车点
这部分是我这些年踩过的坑，几乎每一个都曾经让我在半夜改代码。它们有个共同特点：在测试环境跑得好好的，一到真实图纸上就出问题，而且出错方式很隐蔽。
5.1 字体缺失：中文变问号的全过程
DWG 里的文字有相当一部分用的是专用矢量字体，不是系统字体。这些字体文件平时跟着制图软件一起装，转换服务器上如果没有，文字就渲染不出来，中文直接变成问号或者方块。
更麻烦的是，有些图用了大字体配合的模式，主字体管西文，大字体管中文，缺了任何一个都会花。还有一种情况是字体文件名被改过，或者引用了内网共享路径上的字体，服务器根本访问不到。
我的处理方式是建一个字体库目录，把常见字体全部放进去，转换时优先从这个目录查。缺字体的时候不要静默，要在产物里标注“缺失字体清单”，让用户自己补。这个清单功能帮我省了大量沟通成本——用户看到清单，自己就知道该传什么字体上来了。
5.2 外部参照与光栅图：路径断了就白转
外部参照是图纸复用的常见手段，一张总图引用十几张分图是常态。这些参照在文件里存的是路径，有相对路径也有绝对路径，还有内网共享路径。转换服务器拿到的往往只是一个孤零零的 DWG 文件，路径全是断的。
结果就是：图能打开，但引用的内容全没了，只剩一个标记框。用户一看就说“你这转换丢东西了”。
解决思路有三个，按可靠性排序：一是让上传方打包上传，把参照文件一起传上来，转换时做路径重映射；二是转换时把参照绑定进主文件，产出独立文件；三是在界面上明确提示“本图含 N 个外部参照，未上传”，让用户知情。第三种虽然不完美，但至少不会让人误以为转换成功。
5.3 代理对象：能看不能读
前面提过代理对象，这里补充一个具体场景。有些团队做完预览以后，觉得效果不错，就顺手加上“点选设备看参数”的功能，结果发现点上去什么都没有。原因是这些设备是自定义对象，在解析环境里被降级成了代理图形，轮廓有，参数没了。
这个坑的隐蔽之处在于，它不会报错。预览功能完全正常，你只有在做数据抽取的时候才会发现字段全是空的。所以我的建议是：在 POC 阶段就要拿带自定义对象的真实图纸测一遍抽取，别等预览验收完了才想起来测数据。
5.4 大地坐标与精度：图跑到天边去了
测绘和市政类图纸经常用大地坐标，数值动辄七八位数。这种图纸在转换和渲染时特别容易出问题：要么整个图跑到画面外，要么缩放到极限才看得见一点点线条。
原因是渲染引擎默认按图纸的实际坐标范围来定视野，坐标值太大，精度不够，线条就会抖动或者重叠。解决办法是在转换阶段做一次坐标平移，把图纸整体挪到原点附近，同时把平移量单独存下来，展示坐标的时候再加回去。
还有一个精度问题要注意：浮点数在高位数值上做运算会有舍入误差，坐标值越大，误差越明显。如果业务上需要高精度的距离测量，一定要在原始坐标系下算，别在平移后的坐标上算完再换算。
6. 我的选型心法：先定边界，再谈性能
折腾了这么多年，我现在做选型基本不看宣传参数，先问三个问题。
第一个问题：这个需求里，最不能妥协的是什么？是画面必须和原图一模一样，还是数据字段一个都不能少，还是改完之后必须能被原软件正常编辑。这三个“必须”分别指向三条完全不同的技术路线，选错了后面全是补丁。
第二个问题：图纸的来源可控吗？如果图纸全部来自内部规范制图，字体、图层、块命名都有标准，那方案可以选得激进一点；如果图纸来自各个甲方、各个设计院、各个年代，那就得按最脏的情况准备，容错和降级能力比性能重要得多。
第三个问题：五年以后这套东西还在吗？商业内核的授权是持续支出，开源方案的维护是持续投入，云端服务的价格是持续变量。算账的时候别只算第一年，把运维人力、升级成本、故障损失一起算进去，结论经常和第一年的报价相反。
最后分享一个我自己一直在用的做法：任何方案在正式选型前，先拿 20 张真实图纸跑一遍。这 20 张里要有大图、有小图、有老版本、有新版本、有外部参照、有自定义对象、有中文标注、有大地坐标。跑完把结果做成一张对照表，谁行谁不行一目了然。这比任何一份产品白皮书都靠谱，也比任何一次厂商演示都真实——演示用的图，永远是挑过的。
