先说结论：C# 读取 CAD 图纸这件事，难点主要不在语言，而在格式。DXF 是明文的组码-值对，DWG 是压缩过的二进制私有结构，两者的解析成本差着数量级。我这些年做过不少和图纸打交道的活——批量统计厂房构件面积、从图纸里抽图层清单做物料表、给产线做图纸自动归档，绕来绕去最终都落到同一套东西上：先用一个能流式读组码的解析器把 DXF 拆成内存对象，再在对象上做几何计算。面积计算是这条链路上最容易被低估的一环，看着一个鞋带公式就能收工，真上手才发现圆弧凸度、内环扣除、单位换算、块参照变换，每一个都能让你算出来的数字差出百分之十几。这篇把我踩过的坑和沉淀下来的代码结构摊开讲，从组码读到面积出，适合已经会用 C#、但没系统啃过 CAD 文件格式的朋友，也适合被"图纸数据导不出来"折磨过的工程岗同行直接抄结构。
1. 路线选择：为什么把主力放在 DXF 上
1.1 两种格式的本质差异决定了解析路径
DXF 的设计初衷就是交换。它把图纸里的所有东西摊平成"组码 + 值"的文本对，一行组码一行值，人类肉眼都能读。你用记事本打开一个 DXF，看到的是这样的东西：0 / SECTION、2 / ENTITIES、0 / LWPOLYLINE、8 / 墙体、90 / 4、70 / 1、10 / 0.0、20 / 0.0……每一行都有明确含义，段落之间用 ENDSEC 收尾。这种结构的最大好处是可以边读边解析，不需要把整个文件建成索引，几百万行的图纸用流式读取器完全扛得住。
DWG 完全是另一回事。它是二进制容器，内部有对象字典、句柄表、压缩段，还随版本变。R13 之后每一版的文件结构都动过，想从零写一个 DWG 解析器，工作量和写一个小型 CAD 内核差不多。所以业界的普遍做法是：要么调用 CAD 平台自带的进程外接口，让它帮你把 DWG 另存成 DXF；要么用第三方的格式转换组件做一次批量转换。这两条路都不便宜，但换来的是稳定——格式转换的脏活让别人干，你只管消化 DXF。
我自己的判断标准很粗暴：如果图纸是一次性交付、量大、来源杂，就走转换路线，先把 DWG 统一转成 DXF 再进自己的解析器；如果是交互式场景，比如用户在软件里点开一张图看面积，那就直接调平台接口拿几何数据，别折腾文件。两条路的岔口画清楚，后面的代码才不会被格式问题绑架。
1.2 三条技术路线的取舍与适用场景
实际能走的路就那么几条，我把它们放在一起对比，选择时对号入座就行。
| 路线 | 实现方式 | 优点 | 代价 | 适用场景 |
|---|---|---|---|---|
| 自写 DXF 解析 | 逐行读组码，自己建实体模型 | 零依赖、可控、能跑在服务端 | 只覆盖用到的实体类型 | 批量统计、后台服务、Linux 容器 |
| 开源 DXF 库 | 引第三方包直接读实体集合 | 上手快、实体覆盖全 | 版本维护看运气，异常处理黑盒 | 快速原型、中小项目 |
| 平台接口调用 | 调 CAD 平台的自动化接口 | 几何计算最准、支持 DWG | 依赖客户端安装、进程重、并发差 | 桌面工具、单机处理 |
自写解析这条路的心理门槛最高，但收益也最实在。它不要求你把 DXF 规范全部啃完，只要覆盖业务真正用到的实体类型，通常就是 LWPOLYLINE、LINE、CIRCLE、ARC、HATCH、INSERT 这六种，加上图层和块表，代码量在两千行以内。剩下的几十种实体，遇到再说，遇到不认识的直接跳过并记日志，比让整个程序崩掉优雅得多。
注意：不要一上来就追求"完整支持 DXF 规范"。规范里大量实体是给三维和专业领域用的，二维图纸统计面积根本用不上。先跑通六种核心实体，比写完两万行没人维护的解析器强。
1.3 我最终采用的分层架构
代码分三层，边界清楚，改起来不牵连。第一层是流式词法层，只干一件事：把文件切成一串(组码, 值)对，不做任何语义判断。第二层是段树层，靠组码 0 的值识别 SECTION、ENDSEC、BLOCK、ENDBLK，把线性的组码流还原成"段 → 实体 → 属性"的树。第三层是几何层，把实体里的坐标、凸度、半径翻译成可以用数学处理的对象，面积计算全部在这一层完成。
这么分层最直接的好处是排错有方向。算出来的面积不对，先看词法层读到的组码有没有错位，再看段树有没有把实体挂错段，最后才是几何公式。三层里层的代码可以单独写单元测试，喂一段手写的 DXF 文本进去，断言解析出的顶点数量和坐标。这个测试在我后来改代码时救过好几次命，尤其是处理凸度符号的那次。
2. 组码与段树：把图纸还原成可编程的数据
2.1 组码不是键值对，别用 JSON 思维读它
新手最容易犯的错，是把 DXF 当成配置文件来读。它确实长得像键值对，但同一个组码在一段里会重复出现，而且顺序有意义。LWPOLYLINE 里，组码 10 和 20 成对出现表示一个顶点，有多少个顶点就重复多少遍；组码 42 表示"上一个顶点开始的这段弧的凸度"，它的位置在顶点之后、下一个 10 之前。你要是用字典去存，后一个 10 直接把前一个覆盖，顶点全丢。
正确的心智模型是"事件流"。每读到一个组码，就是在按顺序播放一条指令：读到 10 就记住"接下来要开一个新顶点"，读到 20 就把 Y 坐标补上，读到 42 就把凸度回填给刚结束的那个顶点。状态机式的读法能天然处理重复组码，也能处理可选组码缺失的情况。这个思路转换过来，后面的代码就顺了。
还有一点：组码的值是文本，但类型由组码的数值范围决定。10 到 39 是双精度浮点，60 到 79 是 16 位整数，90 到 99 是 32 位整数，100 到 102 是字符串，210 到 239 是双精度（用于拉伸方向）。你拿 70 当 double 去解析，遇到 "1" 能转成功，遇到别的就抛异常，而且错得莫名其妙。按组码区间分派解析函数，是必须做的第一件事。
2.2 文件骨架：靠 0 号组码识别段落边界
DXF 的骨架全写在 0 号组码上。文件开头是 0/SECTION 加 2/段名，结尾是 0/ENDSEC。段里再嵌实体，每个实体用 0/实体类型开头。BLOCKS 段特殊一点，里面是 0/BLOCK…0/ENDBLK 包起来的块定义。EOF 出现在文件最后，读到它就可以停了，不用等流结束。
识别边界的时候有个细节：段名在 2 号组码里，而且只在 SECTION 之后的第一个 2 号组码才是段名。如果 SECTION 后面紧跟的不是组码 2，说明文件有问题，这时候记录一条警告然后跳过整个段比较稳妥。另外 TABLES 段里有一堆表，LAYER 表、LTYPE 表、STYLE 表，每个表内部又是 0/TABLE…0/ENDTAB 的嵌套结构，手写解析器的时候要注意别把 TABLES 里的 0/LAYER 误判成 ENTITIES 段里的实体——虽然类型名一样，但上下文不同。
我处理的办法是维护一个段栈。压栈时记录段名，出栈时校验，实体只在栈顶是 ENTITIES 或 BLOCKS 的时候才被收集。这样即使文件里夹了嵌套结构，也不会串味。
2.3 四个关键段各自管什么
HEADER 段是全局变量的仓库，格式是 9/$变量名 后面跟若干个值组码。跟面积计算关系最大的是 $INSUNITS，它告诉你图纸的插入单位：1 是英寸，2 是英尺，4 是毫米，5 是厘米，6 是米。这个值决定你算出来的面积要不要乘系数。很多图纸这个值是 0，意思是"无单位"，这时候只能靠人工约定，我一般会在配置里留一个默认单位，读不到就用默认值，并在报告里标注。
TABLES 段里跟业务最相关的是 LAYER 表，每个图层有名字（组码 2）、颜色（62）、线型（6）、可见性（70 的某一位）。做面积统计时按图层过滤是最常见的需求，比如只统计"墙体"图层。用图层表的顺序做索引，比在实体里反复比字符串快。
BLOCKS 段存块定义，ENTITIES 段存实际图元。块参照（INSERT）在 ENTITIES 里只占一条记录，真正的几何在 BLOCKS 里。要算块参照覆盖的面积，必须把块定义取出来，按插入点、缩放、旋转做变换，再算。这一步是面积统计里最大的误差来源，后面单独说。
2.4 组码区间与常见取值坑
| 组码区间 | 数据类型 | 用到的典型位置 |
|---|---|---|
| 0–9 | 字符串 | 实体类型、段名、块名、图层名 |
| 10–39 | 双精度 | 点坐标、半径、凸度、缩放比例 |
| 40–59 | 双精度 | 半径、高度、行距 |
| 60–79 | 16 位整数 | 颜色号、标志位、可见性 |
| 90–99 | 32 位整数 | 顶点数量、面数 |
| 100–102 | 字符串 | 子类标记、应用组 |
| 210–239 | 双精度 | 拉伸方向（OCS 法向量） |
坑集中在两处。一是 40 和 10 都用双精度，但含义天差地别，靠语义区分不能靠类型。二是 62 颜色在图层表和实体里都会出现，负数表示图层关闭，不是颜色值本身。还有 70 这个组码是万能标志位，多段线里 1 表示闭合，块定义里表示匿名块，含义随上下文变。写解析器时，同一组码在不同实体类型下的解释必须分开写，别想着抽一个通用映射表。
3. 用 C# 实现一个轻量 DXF 解析器
3.1 流式读取器：两行一组，永不整体加载
读取器的核心循环就三行：读一行当组码，读一行当值，分派。用 StreamReader 逐行读，内存占用跟文件大小无关，一张两百兆的 DXF 也能跑。这里有个必须处理的细节：组码行可能有前导空格，值行可能为空，而 DXF 允许空字符串作为值。所以判断"文件结束"要用 ReadLine 返回 null，不能用 IsNullOrEmpty。
public sealed class DxfPairReader : IDisposable { private readonly StreamReader _reader; private int _lineNo; public DxfPairReader(string path) { // 老版本 DXF 用 ANSI 代码页，R2007 之后是 UTF-8 var enc = Encoding.GetEncoding(936, EncoderFallback.ReplacementFallback, DecoderFallback.ReplacementFallback); _reader = new StreamReader(path, enc, detectEncodingFromByteOrderMarks: true); } public bool TryRead(out int code, out string value) { code = 0; value = null; var codeLine = _reader.ReadLine(); if (codeLine == null) return false; _lineNo++; var valueLine = _reader.ReadLine() ?? string.Empty; _lineNo++; // 组码行可能带前导空格，Trim 后再解析 if (!int.TryParse(codeLine.Trim(), NumberStyles.Integer, CultureInfo.InvariantCulture, out code)) { throw new DxfFormatException($"第 {_lineNo - 1} 行组码非法：{codeLine}"); } value = valueLine; return true; } public void Dispose() => _reader.Dispose(); }注意 CultureInfo.InvariantCulture 这个参数。DXF 里的小数点永远是点，不是逗号，但 .NET 默认跟随系统区域设置。在某些区域设置下，double.Parse("1.5") 会解析失败或者解析成 15。这个坑我在部署到一台区域设置非默认的服务器上时踩过一次，排查了半天才想到是区域问题。所有数值解析，全都显式传 InvariantCulture，一次都别省。
3.2 实体模型：用抽象基类还是裸结构
实体建模我推荐一个极简的抽象基类，只放三个字段：图层名、句柄、颜色号。子类各自带自己的几何数据。不做接口继承树，不做访问者模式，因为业务里真正需要多态的只有"算面积"和"算长度"两个方法，其他都是数据搬运。
public abstract class DxfEntity { public string Layer { get; set; } = "0"; public string Handle { get; set; } = string.Empty; public int Color { get; set; } = 256; // 256 = ByLayer } public sealed class DxfLine : DxfEntity { public DxfPoint Start { get; set; } public DxfPoint End { get; set; } } public sealed class DxfPolyline : DxfEntity { public List<DxfVertex> Vertices { get; } = new(); public bool IsClosed { get; set; } } public struct DxfVertex { public double X; public double Y; public double Bulge; // tan(圆心角 / 4)，0 表示直线段 }用 struct 存顶点是为了减少大图纸的 GC 压力，一张图几万个顶点，class 分配开销是实打实的。但注意 struct 是值类型，往 List 里加的时候是复制，取出来改要重新赋值回去，别写成list[i].X = 10这种改不进去的代码——那是编译不过的，但用 ref 局部变量时容易搞混。
3.3 LWPOLYLINE 与凸度的读法
轻量多段线是二维图纸里出现频率最高的实体，也是面积计算的主战场。它的组码序列有固定套路：90 是顶点数，70 是标志位（1 表示闭合），然后每个顶点先出 10/20，可能跟一个 42 表示凸度，再出下一个 10/20。
private DxfPolyline ReadLwPolyline(DxfPairReader reader, string layer) { var pl = new DxfPolyline { Layer = layer }; double curX = 0, curY = 0; bool hasPoint = false; int declaredCount = -1; while (reader.TryRead(out int code, out string val)) { if (code == 0) { /* 下一个实体，交给上层处理 */ break; } switch (code) { case 90: declaredCount = int.Parse(val, CultureInfo.InvariantCulture); break; case 70: pl.IsClosed = (int.Parse(val, CultureInfo.InvariantCulture) & 1) == 1; break; case 10: if (hasPoint) pl.Vertices.Add(new DxfVertex { X = curX, Y = curY }); curX = double.Parse(val, CultureInfo.InvariantCulture); hasPoint = true; break; case 20: curY = double.Parse(val, CultureInfo.InvariantCulture); break; case 42: // 凸度属于"上一个已完成的顶点" if (pl.Vertices.Count > 0) { var last = pl.Vertices[pl.Vertices.Count - 1]; last.Bulge = double.Parse(val, CultureInfo.InvariantCulture); pl.Vertices[pl.Vertices.Count - 1] = last; } break; } } if (hasPoint) pl.Vertices.Add(new DxfVertex { X = curX, Y = curY }); if (declaredCount > 0 && declaredCount != pl.Vertices.Count) { // 数量不符通常意味着文件被截断或组码错位，记日志但继续 throw new DxfFormatException($"多段线顶点数不符：声明 {declaredCount}，实读 {pl.Vertices.Count}"); } return pl; }这里的逻辑重点是"延迟添加"。读到 10 的时候不能立刻加顶点，因为 20 还没来，42 也还没来。等到下一个 10 出现，或者实体结束，才把攒好的顶点提交。这个模式在处理所有"成组出现但组数不定"的 DXF 结构时都适用，HATCH 的边界、SPLINE 的控制点，全是同一个套路。
开头说到的第 2.1 节心智模型，落到代码上就是这一段的状态机。凸度回填那几行写得别扭，但这是 struct 的代价，没法避免。如果你用 class，可以直接pl.Vertices[^1].Bulge = b，简洁很多。我的选择是拿性能换简洁，你按自己的量级决定。
3.4 块参照与坐标变换
INSERT 实体本身不含几何，只有块名、插入点、X/Y/Z 三个缩放因子、旋转角。要算它覆盖的面积，得去 BLOCKS 段里找同名块定义，取出块里的图元，套上变换矩阵。
变换顺序是：先缩放，再旋转，最后平移。写成矩阵就是 S 乘 R 乘 T（按行向量约定）。手算容易搞反，我一般直接构造 System.Numerics.Matrix3x2，让库去做乘法。
private static Matrix3x2 BuildInsertMatrix(double ix, double iy, double sx, double sy, double rotDeg) { float rad = (float)(rotDeg * Math.PI / 180.0); return Matrix3x2.CreateScale((float)sx, (float)sy) * Matrix3x2.CreateRotation(rad) * Matrix3x2.CreateTranslation((float)ix, (float)iy); }有个隐蔽的坑：缩放因子可以是非均匀的。当 sx 不等于 sy，而且块里含圆弧时，圆弧会变成椭圆，用原来的半径公式算面积必错。处理办法是检测 |sx - sy| 是否在容差内，不在就把那段弧按椭圆弓形重新算，或者干脆降级为用弦长近似并标注精度损失。我做过一个项目里块参照被用来做门窗编号，缩放是 1:1，这种情况下根本不用管；但另一个项目的图框块被拉伸过，就是在这里翻的车。
提示：块参照可以嵌套。INSERT 里再套 INSERT，递归深度通常不超过五层，但一定要设上限，防止图纸出错导致栈溢出。我设的阈值是 10，超过就跳过并记一条警告。
4. 面积计算：从鞋带到弧段补偿
4.1 鞋带公式与符号约定
闭合多边形面积的标准做法是鞋带公式，也叫高斯面积公式。对有 n 个顶点 (x_i, y_i) 的闭合轮廓，有符号面积等于：
$$A = \frac{1}{2}\sum_{i=0}^{n-1}(x_i y_{i+1} - x_{i+1} y_i)$$
下标按模 n 循环。这个公式算出来的是带符号面积，顶点逆时针排列为正，顺时针为负。取绝对值就是面积大小。之所以用带符号版本，是因为它可以叠加：多个轮廓相加时，外环逆时针、内环顺时针，直接求和就自动完成了内环扣除，不需要额外的包含判断。
public static double SignedArea(IReadOnlyList<DxfVertex> pts) { double sum = 0; int n = pts.Count; for (int i = 0; i < n; i++) { var a = pts[i]; var b = pts[(i + 1) % n]; sum += a.X * b.Y - b.X * a.Y; } return sum * 0.5; }这个公式的几何意义是：把多边形拆成一堆从原点出发的三角形，每个三角形的有符号面积累加。落在原点同侧的三角形贡献叠加，异侧的互相抵消，最后剩下的就是多边形本身的面积。理解了这层，你就能明白为什么顶点顺序必须一致——顺序乱了，抵消关系就错了，结果会离谱。实测一张 100×50 的矩形，逆时针四个角点算出来 5000，顺时针算出来 -5000，绝对值都对。
数值稳定性上有个小技巧：当顶点坐标的绝对值远大于图形的尺寸时（比如图纸基准点在世界坐标的十几万米外），直接算会出现大数相减的精度损失。做法是先算所有顶点的重心，把所有坐标平移过去再做鞋带，最后结果不变。这个平移在一次计算里做一次就行，成本可以忽略。
4.2 凸度转弓形面积的完整推导
LWPOLYLINE 的段不一定是直线。每个顶点上的 42 号组码给了凸度 b，定义是 b = tan(θ/4)，θ 是这段弧对应的圆心角，正负决定逆时针还是顺时针。b 为 0 就是直线段，b 为 1 是半圆，b 大于 1 表示圆心角超过 180 度。
算面积时，鞋带公式只处理了顶点连成的多边形，圆弧段"鼓出去"或者"凹进去"的部分需要单独补。补的量就是弓形面积，即扇形减去三角形。
推导走一遍：设弦长 c，圆心角 θ，半径 R。由 c = 2R·sin(θ/2) 得 R = c / (2·sin(θ/2))。扇形面积是 R²θ/2，三角形面积是 R²sinθ/2，两者相减：
$$A_{seg} = \frac{R^2}{2}(\theta - \sin\theta)$$
θ 用 4·atan(b) 代入，符号自然带上。整个轮廓的面积等于鞋带面积加上所有弓形面积的有符号和。
public static double ArcSegmentArea(in DxfVertex a, in DxfVertex b) { double b0 = a.Bulge; if (Math.Abs(b0) < 1e-12) return 0.0; // 直线，无补偿 double dx = b.X - a.X, dy = b.Y - a.Y; double chord = Math.Sqrt(dx * dx + dy * dy); if (chord < 1e-12) return 0.0; // 退化段 double theta = 4.0 * Math.Atan(b0); double halfSin = Math.Sin(theta / 2.0); if (Math.Abs(halfSin) < 1e-12) return 0.0; // 极端情况，接近整圆 double r = chord / (2.0 * halfSin); return 0.5 * r * r * (theta - Math.Sin(theta)); }拿一个具体例子验证：正方形边长 100，四个角点，每条边的凸度取 tan(45°/4) ≈ 0.19891，相当于每条边向外鼓出一个 90 度圆弧。弦长 100，θ = π/2，R = 100 / (2·sin(π/4)) = 70.71。弓形面积 = 0.5 × 5000 × (1.5708 - 1) ≈ 1427。四条边共补 5708，加上正方形本身 10000，总面积约 15708。你可以用"半径 70.71 的圆面积 15708"反向验证——四个 90 度弓形加正方形，正好拼成一个完整的圆，数值对得上，说明公式没写错。
用整圆做自检是我常用的手段。任何含弧轮廓，如果它恰好能拼成整圆、半圆或者四分之一圆，先拿这个特例验证代码，比直接上复杂图纸排查快得多。
4.3 内环扣除、自相交与容差
含孔洞的轮廓（比如带开孔的板）在 DXF 里通常是多条闭合多段线，或者一个 HATCH 带多个边界环。HATCH 的边界环顺序有讲究：外环逆时针，内环顺时针。直接用带符号面积求和，内环自动扣掉。麻烦的是有些导出软件不守规矩，环的方向全一样，这时候就得自己判断包含关系。
判断办法是射线法：从内环任取一点，向外发射一条水平射线，数它跟其他环的交点个数，奇数说明在内部。点在多边形内的经典算法，注意处理顶点正好落在射线上的退化情况——统一规则是"包含下端点、不包含上端点"，就不会重复计数。
自相交轮廓是另一个麻烦。鞋带公式对自相交多边形给出的是"带符号面积之和"，跟人眼理解的面积可能不一致。八字形多段线，人眼看是两个三角，鞋带会给出零。这种图在实际业务里通常是画错了，我的处理是先做一次自相交检测，检测到就在报告里把这个实体的面积标为"待人工确认"，不硬算。检测用 O(n log n) 的扫描线太重，我用的是简单版的 O(n²) 线段相交判断，顶点数少于 500 时完全够用。
容差方面，坐标比较统一用 1e-9 的绝对容差，面积结果保留六位小数输出。工程图纸的单位是毫米，面积单位是平方毫米，业务上通常要换算成平方米，除以 1e6。这一步换算要跟 $INSUNITS 的判断绑在一起，单位是厘米的话系数是 1e4，是米的话不换算。我见过有人统一除以 1e6，结果图纸单位是厘米，面积小了四个数量级，报表出来全是 0.00。
4.4 单位、精度与输出的落地细节
单位这块再强调一次，因为它是最容易在交付环节翻车的地方。$INSUNITS 为 0 的图纸占比不低，尤其是从别的软件导出的 DXF。这时候不能瞎猜，我的做法是读图纸的图形范围（HEADER 里的 $EXTMIN 和 $EXTMAX），看数值量级：几百的量级大概率是毫米，几十的大概率是米或英寸，然后跟用户配置的默认单位做交叉校验，不一致就报警。
精度上还有个坑是浮点累加。几万个顶点的鞋带求和，朴素的 double 累加会积累舍入误差，虽然量级很小，但跟期望值差个 0.01 也够让人怀疑。稳妥的做法是用 Kahan 求和，多几行代码，精度提升明显。我给个简化版：
double sum = 0, c = 0; foreach (var (a, b) in Edges(pts)) { double y = a.X * b.Y - b.X * a.Y - c; double t = sum + y; c = (t - sum) - y; sum = t; }Kahan 的核心是把每次加法丢掉的那点低位误差单独存起来，下次补回去。代码看着绕，但理解了"补偿项"的概念就通了。实测一万个顶点的随机多边形，朴素累加跟 Kahan 的差在 1e-7 量级，对工程应用来说其实无所谓，但既然不费事，加上更安心。
5. 常见问题与排查速查
5.1 编码问题：中文图层名变乱码
这个问题的症状很有辨识度：英文图层正常，中文图层全变成问号或者怪符号。原因在读取器的编码选择上。R2007 之前的 DXF 用 ANSI 代码页，简体中文环境是 GBK（代码页 936）；R2007 之后改成了 UTF-8。判断版本看 HEADER 里的 $ACADVER，AC1021 及以上是 UTF-8。
麻烦的是 .NET Core 和 .NET 5+ 默认不带 GBK 编码，需要先注册代码页提供程序：
Encoding.RegisterProvider(CodePagesEncodingProvider.Instance); var gbk = Encoding.GetEncoding(936);不注册的话，GetEncoding(936) 直接抛异常。这个异常信息还算清楚，但第一次遇到容易懵。另一个更隐蔽的情况是文件里混了 BOM，StreamReader 开了 detectEncodingFromByteOrderMarks 之后行为会变，建议先用二进制方式读前几个字节判断，再决定用哪个编码打开。
还有一种情况是文件本身声明了 $DWGCODEPAGE 但实际内容又不符合。这时候只能用启发式：先按 UTF-8 读，遇到非法字节序列再回退到 GBK。.NET 有个技巧，用 UTF8Encoding(false, true) 构造严格模式，解码失败会抛异常，catch 住换编码重试。代价是要读两遍，但总能读对。
5.2 数据换算类问题：算出来对不上
面积算错的排查，我固定按这个顺序走，命中率很高。
先确认顶点顺序。随便挑一个闭合多段线，把顶点坐标打印出来，画在纸上，看是顺时针还是逆时针。如果整个图层的轮廓方向跟其他图层相反，说明导出软件对这层做了镜像，面积符号会反，取绝对值能救，但内环扣除会失效。
再确认凸度符号。凸度为正是逆时针弧，从起点到终点鼓向哪边，取决于起终点的相对位置。有个速查办法：拿 b = 1 的半圆测，起点 (0,0)、终点 (100,0)，逆时针半圆应该在 y 轴负方向还是正方向？答案是正方向（上方），因为逆时针从 (0,0) 到 (100,0) 走的是上半圆。如果你的代码算出下半圆，说明 θ 的符号处理反了。
最后确认单位。把面积除以 1e6 之后看是否落在合理区间，比如一个标准车位大概 12 到 15 平方米，一个房间 20 到 40 平方米。数量级对不上就是单位问题，不用再往下查。
5.3 排查速查表
| 症状 | 最可能原因 | 快速验证 | 处理方式 |
|---|---|---|---|
| 中文图层乱码 | 编码选错 | 看 $ACADVER 版本 | 按版本选 GBK 或 UTF-8 |
| 顶点数不对 | 组码错位 | 打印前 20 个组码 | 检查 10/20 配对逻辑 |
| 面积为 0 | 轮廓未闭合 | 检查 70 标志位 | 手动补首尾点或读 70 位 |
| 面积偏小 | 圆弧未补偿 | 找含 42 组码的顶点 | 加弓形面积 |
| 面积翻倍 | 块参照被重复计算 | 统计 INSERT 数量 | 去重或跳过块内图元 |
| 内环未扣除 | 环方向相同 | 算每个环的带符号面积 | 射线法判包含并反转 |
| 数值全是 0.00 | 单位换算系数错 | 看 $INSUNITS 值 | 按单位表取系数 |
| 大图纸内存爆 | 一次性加载 | 看内存峰值 | 改流式读取 |
这张表我贴在显示器边上用了两年，新同事接手时直接照着查，比从头讲一遍快。
5.4 一个完整的小流程
把前面的东西串起来，跑一遍从文件到报表的完整链路：打开 DXF，读 HEADER 拿单位和范围，跳过 TABLES 但收下图层名，进 BLOCKS 收块定义，进 ENTITIES 逐实体分派。遇到 LWPOLYLINE 且闭合的，按图层分组，算带符号面积加弓形补偿；遇到 HATCH，取所有边界环按方向求和；遇到 INSERT，查块定义并套变换矩阵，递归处理。最后按图层汇总，除以单位系数，输出 CSV。
整个过程单线程跑一张两万实体的图纸，耗时大概两三秒，瓶颈在读文件而不是算面积。如果要提速，按段并行读是不行的（段有顺序依赖），但实体级的面积计算完全可以并行，用 Parallel.For 包住计算循环就行，注意结果收集要用线程安全的容器或者先分区再合并。
6. 写在代码之外的几点体会
这套代码我用在过好几个场景，最大的感受是：格式解析的复杂度是确定的，业务理解的复杂度是不确定的。DXF 规范再厚，读上两周也就摸清了常用部分；但"这张图纸里哪些线框该算面积、哪些只是标注引线"这种判断，问十个人能给出八个答案。所以在写解析器之前，一定要先跟使用方确认口径：闭合多段线算不算、HATCH 算不算、块参照要不要展开、图层白名单怎么定。这些定下来，代码的结构自然就清楚了。
第二个体会是别过早优化。我最早那版解析器为了省内存，把顶点存成 float，结果一张精密模具图纸上，坐标精度丢了之后面积误差到了千分之三，客户不认。改回 double 之后问题消失，内存多用了不到一倍，完全在可接受范围。工程领域的数据，double 是底线，别想着省。
第三个是日志。解析过程中的异常不要直接抛出去让上层崩掉，而是收集成"问题清单"，跟结果一起输出。一张图纸有几万个实体，其中两三个解析失败太正常了，为了两个坏实体让整批统计失败，业务上不可接受。我的做法是每个实体解析包在 try 里，失败的记下句柄和错误原因，最后在报表末尾附一个"跳过记录"页签，让使用方自己判断要不要人工补。
最后分享一个自检习惯：每次改完面积计算相关的代码，拿三个固定的测试文件跑一遍回归——一个纯直线的矩形、一个带四分之一圆弧的 L 形、一个带内环的环形。三个文件的期望值我手算过，写在测试里。这个习惯让我在半年内避免了好几次"改一处坏三处"的事故，成本极低，收益极高。
