1. 为什么直接硬啃二进制 DWG 是个坏主意

C# 读取 DWG、DXF 文件并做面积计算这件事，我最早是抱着"一个文件格式而已，解析一遍不就行了"的心态进场的。结果第一个 DWG 文件就让我卡了整整两天：文件头能读出来，版本号能读出来，但往下走对象映射表的时候全是加密的字节块，偏移量算出来指向的位置完全对不上。后来才发现，DWG 从较新的版本开始对文件内部的对象数据做了分段加密，段与段之间还有校验，光靠猜测字段结构是走不通的。这件事之后我彻底改了思路：解析 DWG/DXF 的核心不在于"读懂二进制"，而在于选对入口，然后把精力全部砸在组码语义和几何还原上。这篇文章就按这个顺序讲——先把路线选对，再把组码吃透，再谈面积怎么算才不返工。

需要先明确一个前提：这套东西适合什么人。如果你是做工程量统计、图纸批处理、机加工排版、装修算量、管线长度估算这类系统的开发者，需要在服务端或者桌面端批量拿到图纸里的闭合轮廓面积、周长、图层归属，那后面的内容基本可以直接抄。如果你的需求只是偶尔看一眼图纸，装个看图软件手动量一下比写代码快得多——这个判断我很认真地建议你先做，我见过太多人为了省一次手工测量，写了两千行解析代码。

1.1 DWG 是私有二进制容器，DXF 才是公开的交换层

这两者经常被混为一谈，但它们的性质完全不同。DWG 是面向软件内部使用的二进制容器，结构紧凑、读取快，但字段布局、压缩方式、加密规则都随版本演进，且不是公开规范。你去硬解它，本质上是在对着样本做逆向，一旦碰到没见过的版本或者第三方软件导出的"非标准 DWG"，就是无穷无尽的兼容性补丁。DXF 则是一个明确的文本交换格式，全部内容用"组码 + 值"的成对行来表达，结构上有段（SECTION）、表（TABLE）、块（BLOCK）、实体（ENTITIES）的清晰分层，配套的规范描述足够你把一个 LWPOLYLINE 从字节流还原成带凸度的多段线。

所以我的第一条实践结论很直白：在 C# 里做业务逻辑，一律以 DXF 为输入，DWG 只作为上游原料。DWG 进来之后先做一次格式转换，转成 ASCII 版 DXF，再进解析器。这样解析器只需要维护一套逻辑，兼容性风险全部收敛到转换环节，而转换环节是独立的、可以单独测试的、出问题能立刻定位的。

下面这张表是我在几个真实项目里反复验证过的路线对比，你可以直接拿去做选型依据：

选型时我建议按"文件来源是否可控"来切。如果图纸来自外部合作方、扫描归档、各种来源混杂，那第一条路线几乎没有悬念；如果图纸全部由内部固定几台机器、固定软件版本产出，第四条路线的成本最低。商业内核那条路不是不好，是很多时候预算批不下来，而且它把"能不能跑"这件事绑定在了第三方身上，交付之后客户环境里少一个运行时依赖就起不来，这种事故我遇到过一次，之后就很少主动推荐了。

1.2 转换环节的三个关键参数，选错后面全是坑

把 DWG 转成 DXF 不是一个"点一下导出"的简单动作，有三个参数会直接影响后面解析的成败，而它们通常藏在导出对话框的角落里。

第一个是DXF 版本。选 R2018 还是 R2013，取决于你的解析器支持到哪。较新的版本会引入一些新实体和新的组码，如果你的解析器只处理了老版本的子集，用新版本导出会冒出你没见过的实体类型，虽然可以靠"未知实体跳过"兜住，但被你跳过的那部分图形可能就是用户要算面积的那部分。我的做法是统一锁一个中间版本导出，所有输入走同一条路，解析器的测试用例也能收敛。经验上锁在 R2013 或者更早的稳定版本，覆盖面最广。

第二个是ASCII 还是二进制。这个必须选 ASCII。二进制 DXF 的组码是二进制编码的，值也是二进制，读取逻辑要另写一套，而且不同软件导出的二进制 DXF 在若干细节上还有差异，纯属给自己找麻烦。ASCII 版虽然文件大好几倍，但可以流式读、可以 diff、出问题能直接用文本编辑器打开看现场，排错效率完全不是一个量级。

第三个是编码。中文图纸里图层名、块名、标注文字经常是中文，导出的 DXF 头部的$DWGCODEPAGE会写明代码页，常见的是简体中文对应的代码页。如果转换工具导出时编码处理不当，你会在图层名里看到一堆问号或者乱码方块，虽然不影响几何计算，但一旦业务需要按图层过滤，就彻底废了。我在项目里做的第一件事就是在解析器初始化时注册代码页编码支持，然后用$DWGCODEPAGE的值动态决定编码，而不是硬编码成 UTF-8。

提示：转换这一步一定要保留原始文件的备份和转换日志。我遇到过转换后面积比原图小了 3% 的情况，最后发现是原图里有几个实体是其他软件的代理对象，转换时被丢弃了。没有日志的话，这种问题只能靠"感觉不对"来发现。

2. 组码读起来像天书？先把四层结构拆开

DXF 的文本结构说穿了极简：每一行要么是组码，要么是组码对应的值，两行一组，一码一值。组码是一个整数，决定后面那行值该怎么解释——是字符串、是双精度浮点、是 16 位整数还是 32 位整数。真正让人头晕的不是这个规则，而是同一个数字在不同上下文里含义不同：组码 10 在实体里通常是 X 坐标，在表项里可能是别的意思；组码 70 在 LWPOLYLINE 里是闭合标志位，在图层表里是颜色标志。所以正确的理解方式是：先按"段 → 表/块/实体 → 具体类型"的顺序确定上下文，再按上下文查组码含义，而不是拿一个组码表全图乱查。

我最初写的第一版解析器就是没有上下文概念的，读到一个 70 就往一个全局字典里塞，结果整个文件解析完，字典里全是互相覆盖的垃圾。第二版加了上下文栈，代码反而短了一半。这个教训值得单独说一句：解析器的核心数据结构不是"组码表"，是"上下文栈"。

2.1 两行一组的读取循环，和它埋着的两个雷

最基础的读取循环长这样，看起来毫无技术含量，但有两个细节必须处理对。

public readonly struct DxfPair { public readonly int Code; public readonly string Value; public DxfPair(int code, string value) { Code = code; Value = value; } } public static IEnumerable<DxfPair> ReadPairs(TextReader reader) { string codeLine; while ((codeLine = reader.ReadLine()) != null) { if (codeLine.Length == 0) continue; // 空行直接跳过 var valueLine = reader.ReadLine(); // 值行可能缺失 if (valueLine == null) yield break; if (!int.TryParse(codeLine.Trim(), out var code)) continue; yield return new DxfPair(code, valueLine.TrimEnd('\r', '\n')); } }

第一个雷是值行的前导空格不能裁。组码 1 的文本内容、组码 2 的块名、标注文字这些，前导空格是有意义的，某些软件导出的块名确实带前导空格，你一 Trim 就再也对不上了。所以代码里只对码行做 Trim，值行只做行尾处理。这个坑我踩过一次，表现形式是"块引用找不到对应的块定义"，查了两个小时才发现是名字被我自己裁了。

第二个雷是换行符。StreamReader.ReadLine本身能处理\r\n、\n、\r三种，但如果你图省事用了File.ReadAllText再Split('\n')，遇到老文件里的孤立\r就会切错，整个文件从此偏移一行，后面全部错位。这也顺带说明为什么不要用一次性读取——不只是内存问题，是正确性问题。

第三个（顺带说）是编码。读取时用new StreamReader(path, encoding, detectEncodingFromByteOrderMarks: true)，编码从头部$DWGCODEPAGE拿。拿不到就退回到系统默认代码页，别直接假设 UTF-8。

2.2 靠组码 0 建立骨架：段、表、实体三类分界

整个 DXF 的骨架可以用一个很粗暴的规则识别：组码 0 出现的位置就是"一个新东西开始了"。它的值告诉你这个新东西是什么：SECTION是段开始，ENDSEC是段结束，TABLE是表开始，ENDTAB是表结束，BLOCK是块定义开始，ENDBLK是块结束，其余值（比如LINE、LWPOLYLINE、INSERT、TEXT）基本都是实体类型名。

基于这个规则，解析主循环可以写成状态机：维护一个currentSection，遇到SECTION就读下一对的组码 2 拿到段名（HEADER、TABLES、BLOCKS、ENTITIES、OBJECTS），然后分派给不同的处理器。HEADER段里全是$变量名加值，用来读$INSUNITS、$DWGCODEPAGE、$EXTMIN、$EXTMAX这些全局设置。TABLES段里是图层表、线型表、样式表，做图层过滤的时候要在这里把图层名和颜色、可见性建一张映射表。BLOCKS段里是块定义，一个块从BLOCK开始到ENDBLK结束，中间夹着构成它的实体。ENTITIES段是模型空间里的实际图形，也是面积计算的主战场。

我强烈建议在这一层就把"实体列表按类型分组"做掉，而不是边解析边算面积。原因很简单：面积计算需要完整的几何信息（比如块引用的变换、多段线的所有顶点），而流式解析到一半的时候信息是不全的。分成两步——第一步解析成内存对象树，第二步在对象树上计算——代码清晰度和可调试性都高一个档次。

2.3 老式 POLYLINE 与新式 LWPOLYLINE：两套完全不同的拼装逻辑

这是解析 DXF 时最容易翻车的地方，我把它单独拎出来讲，因为两种多段线的结构差异大到像是两个格式。

新式 LWPOLYLINE是一个自包含的实体。它的顶点信息不是子实体，而是在同一个实体的组码流里依次出现：一个组码 10（X）配一个组码 20（Y），重复 N 次，就是 N 个顶点。凸度（bulge）由组码 42 携带，关键点是——42 紧跟在他所属的那个 10/20 后面出现，作用于"从当前这个顶点出发的那一段弧"，不是作用于整条线。如果你把 42 当成全局属性存一次，多段线就变成了一大堆直线段拼起来的错误形状，面积自然也就错了。组码 70 是标志位，最低位是 1 表示闭合，这个必须读，因为它决定了最后一段要不要连回起点。

老式 POLYLINE完全是另一套：POLYLINE只是一个头，后面跟着一串VERTEX子实体，每个 VERTEX 有自己的 10/20/30 和 42，最后必须以SEQEND收尾。这里有个隐藏的坑：不只是普通顶点用VERTEX，样条控制框架点也用VERTEX，靠 VERTEX 自己的组码 70 里的标志位区分——标志位为 16 的是样条框架点，不是真正的几何顶点，必须跳过。我见过有图纸把样条拟合的多段线导出成老式 POLYLINE，如果不跳过框架点，算出来的面积会大出十几倍。

拼装的实现思路是维护一个"当前打开的多段线"引用：遇到POLYLINE就新建并挂起，遇到VERTEX就往挂起的那条线里追加顶点，遇到SEQEND就关闭并入库。LWPOLYLINE则是一把梭，读完整个实体就入库。两套逻辑并行存在，千万不要试图合并。

2.4 一个组码的值是什么类型，只能由组码号段决定

值的类型推断有一张规范定义的号段表，不是猜的，是按号段来的。用错类型最典型的后果是坐标精度丢失——把浮点当整数解析，小数点后面全没了，一米长的线变成零米，面积算出来是 0，而且不报错。这张表我在这里列一部分常用的，够覆盖绝大多数实体：

实践中的做法是：解析器内部一律先按字符串存，等到具体实体的解析逻辑里去按需转换。这样虽然多一次转换开销，但错误定位极其方便——出问题的时候你能看到原始字符串，而不是一个已经被错误转换过的数字。等到性能成为瓶颈（通常是几十万实体量级），再做按号段的提前类型化。

3. 把组码还原成几何：顶点、凸度、变换

拿到了顶点数组、凸度数组、闭合标志，是不是就能算面积了？在理想情况下可以。但真实图纸里，你至少还要处理四件事：圆弧段的几何还原、坐标系的转换（OCS 到 WCS）、块引用的嵌套变换、以及单位换算。少做任何一件，算出来的数字在特定图纸上就会离谱，而且往往是在客户验收的时候才暴露出来。

这一节我按"从单条多段线到整张图"的顺序讲，每步都给出可以直接用的实现思路。

3.1 凸度是理解这整件事的钥匙

凸度（bulge）这个量的定义是该段圆弧的圆心角四分之一的正切，即bulge = tan(θ/4)。正负号表示方向：正值是逆时针（从起点走向终点时向左凸），负值是顺时针。这个定义如果你只记结论不推导，很容易在边界情形上犯迷糊，我把推导过程简单走一遍。

已知圆弧从点 P1 到 P2，圆心角为 θ。弦长c = |P2 - P1|，半径R = c / (2·sin(θ/2))。凸度b = tan(θ/4)，反过来θ = 4·atan(b)。所以只要知道两点坐标和一个 bulge 值，圆弧就完全确定了——圆心、半径、起止角都能算出来。这个"两点 + 一个标量就能唯一定义圆弧"的设计非常巧妙，它让多段线可以直接表达任意圆弧连接，而不需要额外的圆心半径字段。

有了 θ 和 R，弓形面积（圆弧和弦围成的那块月牙形面积）就是：

A_seg = (R² / 2) · (θ − sin θ)

当 θ 在 0 到 2π 之间时，sin θ 的正负会自动让这个式子的符号跟着 θ 的符号走，所以正向弧得正面积、反向弧得负面积，天然适配有符号面积累加。这个性质让后面的面积计算代码变得很短。

3.2 鞋带公式和弧段修正的正确拼法

多段线的有符号面积由两部分组成：直线段围成的多边形面积（鞋带公式），加上每一段圆弧的弓形修正量。鞋带公式是：

A_poly = 0.5 · Σ (x_i · y_{i+1} − x_{i+1} · y_i)

逆时针为正，顺时针为负。问题在于弓形面积的符号取决于两个因素：凸度的符号，和多边形整体的走向。如果多边形是顺时针的，鞋带结果是负的，而弓形如果直接按凸度符号加，符号就反了。

最干净的解决方案是先把顶点序列统一成逆时针：算出A_poly之后，如果它是负的，就把顶点数组反转、所有凸度取负。之后再统一做累加，这时所有符号都是一致的，不需要在每一段上做方向判断。我在项目里就是这么干的，代码可读性比在一堆if里判断方向好太多。

public static double PolygonArea(List<Pt> pts, List<double> bulges) { int n = pts.Count; double a = 0; for (int i = 0; i < n; i++) { var p = pts[i]; var q = pts[(i + 1) % n]; a += p.X * q.Y - q.X * p.Y; } a *= 0.5; if (a < 0) // 统一成逆时针 { pts.Reverse(); bulges.Reverse(); for (int i = 0; i < bulges.Count; i++) bulges[i] = -bulges[i]; a = -a; } for (int i = 0; i < n; i++) { double b = bulges[i]; if (Math.Abs(b) < 1e-9) continue; // 近似直线，跳过 var p = pts[i]; var q = pts[(i + 1) % n]; double chord = Math.Sqrt((q.X - p.X) * (q.X - p.X) + (q.Y - p.Y) * (q.Y - p.Y)); if (chord < 1e-12) continue; // 退化段 double theta = 4.0 * Math.Atan(b); double r = chord / (2.0 * Math.Sin(theta / 2.0)); a += r * r / 2.0 * (theta - Math.Sin(theta)); } return a; }

这里有个数值上的细节值得说：当|b|非常小（比如 1e-9 量级）时，θ 趋近于 0，R 会变得极大，R²可能溢出到无穷，而(θ − sin θ)又极小，两个量相乘本该是个有限的小数。用浮点算就会出现Infinity × 0 = NaN。所以必须设一个阈值直接跳过，1e-9是我实测下来比较安全的界限，对应弓高远小于图纸精度。同理，弦长退化（两个顶点重合）也要跳过，否则sin(θ/2)也可能出问题。

还有一点是坐标量级。鞋带公式在坐标绝对值很大的时候（比如图纸坐标系原点在城市基准点上，坐标值上百万），x_i·y_{i+1}会到 10¹² 量级，两个大数相减得到一个小数，有效数字大量丢失。解决办法是在计算前把坐标平移到质心或者第一个顶点，算完面积不受影响（平移不改变面积）。这个处理在几十平米的小房子上体现不出来，在你处理地籍图、总图的时候，误差能达到几平方米。

3.3 块引用：变换矩阵要一层层叠上去

图纸里大量重复的元素都会做成块，用INSERT引用。INSERT的组码包含插入点（10/20/30）、X/Y/Z 三个缩放（41/42/43）、旋转角度（50，单位是度，注意转换弧度）、以及拉伸方向（210/220/230）。块定义本身的BLOCK实体有一个基点（也是 10/20/30），这个基点必须参与变换，否则整个块会偏移。

正确的世界坐标变换是：

P_world = P_insert + R(angle) · S(sx, sy) · (P_block − P_base)

顺序不能乱，尤其是缩放和旋转之间不可交换。当块里又嵌套了块，就要递归地把矩阵乘下去。我的做法是定义一个轻量的 2D 仿射变换结构（其实就 6 个参数：m11, m12, m21, m22, dx, dy），然后把父变换和子变换相乘，递归深度通常不超过 3 层，不会爆栈。

一个实践中的取舍：如果业务只关心面积，其实不需要真的做坐标变换。因为面积在均匀缩放下按比例变化（面积乘以缩放因子的乘积），旋转和平移不改变面积。所以对块内的闭合轮廓，你可以在块的局部坐标系里算面积，然后乘以|sx · sy|。这个技巧能省掉大量变换运算，在批量处理时很明显。但要注意：如果 X 和 Y 缩放不一致（非均匀缩放），圆弧会被拉成椭圆，弓形面积公式不能直接用了，这时候必须老老实实把弧离散成折线再算。我在代码里加了一个判断：Math.Abs(sx - sy) > 1e-9就走离散路径。

3.4 单位：$INSUNITS 决定面积要乘一个什么系数

$INSUNITS定义在 HEADER 段里，值是一个整数，表示图纸的插入单位。常用值如下：

这里要特别小心：这个字段是"建议值"，很多图纸根本没设置，值为 0。为 0 的时候你无法从文件里推断单位，只能靠业务侧约定或者让用户手动指定。我在系统里做的是三档策略：文件里有值就用文件的；没值就看图层名或者标注文字里有没有"mm"、"毫米"这类线索；都没有就用配置项兜底，并且在结果里标注"单位未确认"，让用户自己核。宁可标一个不确定，也不要悄悄按米算，最后差了六个数量级，责任全在你身上。

还有一点：面积是长度单位的平方，所以换算系数是长度系数的平方，这个很多人在第一次写的时候会忘，我见过把毫米直接乘 0.001 当面积系数的代码，结果小了整整一千倍。

4. 面积计算：鞋带公式只是起点

上面讲的都是"单条闭合多段线"的理想情形。真实图纸里，你要算面积的对象远比这复杂：填充（HATCH）的边界可能是多条曲线拼起来的、带孔洞的多个闭合环；有时候用户要算的是"扣除内部障碍物之后的净面积"；有时候他给的是好几条线段，需要你先判断它们能不能围成一个闭合区域。这一节我按复杂度递增讲四种场景，每种都给可复现的处理方法。

4.1 填充边界：91/92/93/72 这几个组码必须读懂

HATCH 实体的面积不能直接读，要自己从边界算。它的边界描述结构是这样的：组码 91 是边界路径的数量；每条路径由组码 92 开头，92 的值是路径类型标志（最低位 1 表示外部边界，0 表示内部孤岛，第二位表示是否是多段线路径）；组码 93 是该路径的边数；然后按组码 72 逐条描述边。

边类型 72 的取值决定后面跟什么字段：值为 1 是直线边，给起点（10/20）和终点（11/21）；值为 2 是圆弧边，给圆心（10/20）、半径（40）、起始角（50）、终止角（51）、以及逆时针标志（73）；值为 3 是椭圆弧；值为 4 是样条。实际图纸里绝大多数是直线边和圆弧边，把这两种处理扎实，覆盖率就很高了。

这里有个非常容易出错的地方：HATCH 的边界信息有两种存储方式。一种是真的有边数据（72 系列），另一种是"多段线路径"，只给一个指向已有 LWPOLYLINE 的引用，需要你去ENTITIES段里把那条多段线找出来再算。判断依据是 92 值的第二位。我最初只处理了第一种，结果在部分图纸上 HATCH 的面积全是 0，查了很久才发现是走了第二条路。

4.2 孔洞扣减：靠有符号面积自动完成，不用判断"谁在里面"

带孔洞的区域，比如一块板上有几个圆孔，用户的净面积就是外轮廓面积减孔面积。很多人第一反应是写点在多边形内的判定，逐个判断哪个环在里面。其实完全不需要——如果外轮廓是逆时针、内孔是顺时针（这在 DXF 里是标准约定），你只要把所有环的有符号面积直接相加，结果就自动是净面积。因为内孔的有符号面积是负数，加进去自然就扣掉了。

这个技巧的价值在于它绕开了"环的包含关系判定"这个 O(n²) 的麻烦事。但它的前提是方向约定被遵守了。真实图纸不一定遵守，尤其是从别的软件导过来的图。所以稳健的做法是：先算每个环的绝对面积，找出最大的那个作为外轮廓，然后检查其余环的方向是否与外轮廓相反，相反的直接加，相同的那就说明方向反了，取负号再加。写起来也就十几行代码。

还有一种更麻烦的情形：多级嵌套，孔里面还有岛。这种情况靠"面积大小排序"就不够了，需要做真正的包含关系判定。我的经验是，碰到多级嵌套的图纸，先在业务上确认一下是不是真的需要这么精细，很多时候用户只是想要个大致面积。如果确实需要，用射线法做一次点在多边形内的批量判定，配合面积排序做分层，代码量会上升一个档次，但逻辑是清楚的。

4.3 由散乱线段拼出闭合区域：容差和去重是全部难点

有时候图纸里的区域不是一条完整的多段线，而是由十几条独立的LINE首尾相接围成的。用户的需求是"选中这块区域，告诉我面积"。这时候你需要做的第一件事是图元拼接：把端点距离在容差内的线段连起来。

难点全在容差上。DXF 里的坐标是双精度浮点，但不同软件导出的坐标精度不一样，再加上用户画图时不一定捕捉得准，端点之间经常差个零点几毫米到几毫米。容差设小了连不上，设大了会把本来分开的两条线错误地连起来，形成一个错误的闭合区。我的做法是按图纸尺寸自适应设定容差：先读 HEADER 里的$EXTMAX和$EXTMIN算出图纸的包围盒对角线长度，容差取对角线的百万分之一量级，同时设一个下限（避免超小图纸上容差过小）。这个策略在几百张图的回归测试里表现比较稳。

拼接的算法本身可以用一个简单的索引：把所有端点坐标按一个网格量化（比如量化到容差大小的整数倍），建一个字典，键是量化后的坐标，值是所有以这个点为端点的线段。然后从任意一条线开始深度优先往下走，直到回到起点，得到闭环。这个方法在几千条线的规模下性能完全够用。

拼完之后还要处理自交和重复边。自交会让鞋带公式给出错误结果（甚至给出一个正负抵消后的荒谬值），重复边会让面积偏大。检测自交可以用 O(n²) 的线段两两求交，对几万个顶点的图来说太慢，通常的做法是先做一次扫描线或者用包围盒过滤。我的建议是：把自交检测做成可开关的校验项，只在用户点"校验"的时候跑，不要放在主流程里。主流程只算面积，快就完事了。

4.4 算完不信？三招校验你的结果

面积这种数字，用户第一反应一定是拿去跟图纸上标的数对一下。差值超过容忍度就会质疑你的整个系统。所以我养成了一个习惯：每个算出来的面积都带一个可信度标记和一个交叉校验值。

第一招是横向比对。对同一条多段线，用两种独立的方法各算一遍：一种是上面那套有符号面积加弓形修正；另一种是把所有圆弧按足够小的角度离散成折线，再用纯鞋带公式算。两者差值应该在万分之一以内，超过了就说明凸度处理有问题。这个方法对定位"圆弧方向搞反"这类 bug 特别有效，因为离散法不涉及方向逻辑。

第二招是包围盒估算法。任何多边形面积一定小于它包围盒的面积，也一定大于某个内接形状的面积。如果算出来比包围盒还大，那百分百是符号或者自交的问题。这个检查几乎零成本，我在代码里当成断言用。

第三招是用户可见的对照值，把外接矩形尺寸、周长、顶点数一并输出。用户看到"12.3 米 × 8.1 米，面积 99.6 平方米"这样的组合，心里就有底了。只给一个裸的面积数字，反而让人不放心。

注意：别拿"与 CAD 软件里 AREA 命令的结果完全一致"当验收标准。CAD 里 AREA 会对自交图形给出按子区域累加的结果，而你的有符号面积公式会给出净面积，两者在多环自交的图形上天然不同。验收标准应该写"在闭合、无自交的图形上，误差小于 0.01%"。

5. 工程化落地：大文件、容错和我踩过的坑

代码跑通一张图纸和代码跑通一万张图纸，是两个完全不同的项目。这一节讲的是把它做成能交付的东西时会遇到的现实问题。

5.1 别把文件读进内存，也别过度设计

一张普通建筑图纸导出成 DXF 大概几兆到几十兆，一个包含大量细微填充的装配图能到几百兆。这些文件如果ReadAllText直接读进来，再加上解析出来的对象树，内存占用能到好几个 G。服务端跑批的时候同时处理几个文件就 OOM 了。

正确的做法是流式读组码、只保留需要的实体。具体来说：读的时候用StreamReader逐行读；解析 ENTITIES 段的时候，只对关心的实体类型（LWPOLYLINE、POLYLINE、HATCH、CIRCLE、INSERT、LINE）建对象，其余类型（TEXT、DIMENSION、各种标注）直接跳过不建对象，只是把组码消耗掉。这一个优化在真实文件上能省掉 70% 以上的内存和大量的对象分配。OBJECTS段和CLASSES段如果业务不需要，整段跳过即可——它们占了文件很大比例，但对几何计算毫无用处。

反过来也别过度设计。我一度想做成"完全流式、零内存"的架构，结果发现面积计算天然需要完整的闭合环，边读边算根本不可能。最终方案是"流式读入 + 按需保留 + 算完立刻释放"，在批处理循环里显式地把每个文件的对象树置空，简单有效。

5.2 未知实体、坏行、超长行：容错的三条底线

解析器的健壮性由三条底线决定。

第一条，遇到不认识的实体类型必须跳过而不是抛异常。DXF 版本一直在演进，总有你没实现的类型，图纸里还可能有第三方软件的私有实体。跳过策略要在组码层实现：读到组码 0 且值不认识，就一路吞组码直到下一个组码 0，把这个实体整体丢弃。我见过因为一个不认识的实体导致整个文件解析失败的实现，那种体验非常糟糕。

第二条，坏行要能跳过并记日志。真实文件里偶尔会有截断的行、空行、组码不是数字的行。上面那段读取代码里用int.TryParse加continue就是在做这件事。但跳过不能悄无声息，要计数、要记日志，因为一个文件跳过了 5000 行，那解析结果的完整性就有问题，得让上层知道。

第三条，超长行要有上限。扩展数据、某些文本实体的组码值可能很长，如果来一个恶意构造的文件，一行几百兆，ReadLine会直接把内存撑爆。虽然这是极端情形，但在任何接收外部文件的系统里都值得加一个行长上限保护。

5.3 我踩过的坑，按血泪程度排序

下面这张表是我这些年攒下来的清单，基本每一条都对应过一次线上问题或者一次加班。

最后再补充一个不太算坑但很容易忽略的点：同一个文件里可能同时存在模型空间和图纸空间（布局）的实体。ENTITIES 段里的实体默认都在模型空间，图纸空间的内容由组码 67 的值标记（1 表示图纸空间）。如果业务只关心模型空间的图，就要按 67 过滤，否则会把图框、标题栏这些也算进去，面积一下子多出好几倍。这个小细节我是在一次结果异常排查里才注意到的，当时怎么算都比对不上，最后发现是把两个图框的矩形面积也算进去了。

真要说经验，我觉得最值得记住的一句是：面积计算本身不到一百行代码，剩下的九千行全在处理"这张图纸跟上一张不一样"。所以我把所有容错、所有特殊情况的日志都留着，每次线上出现面积异常，第一件事不是改代码，是把那份 DXF 存下来加进回归用例集。一年多下来，这个用例集成了整个系统最有价值的东西。