1. 动手前先分清三种“直连”的边界先说我自己的情况。我在做设备管理类上位机的时候经常接到这种需求界面上点一个按钮AutoCAD 里自动打开对应的一张图纸把某个设备图元高亮出来或者月底要把一批 DWG 合并成一张总图顺便把图纸里的设备编号、型号、安装位置提取到 Excel 里。最开始我也是从搜索引擎上扒“C# 直连 CAD”的代码结果发现同一句话在不同人写的博客里完全是三回事。闭门研究了一个星期后我觉得必须先搞清楚一个基本问题你说的“直连”到底是哪一种连接我把市面上常见的做法拆成三类做完对比之后很多坑就提前避开了。方案连接方式CAD 是否需要打开适合场景典型瓶颈COM 自动化外部程序通过 COM 接口控制正在运行的 AutoCAD需要轻量调用打开图纸、简单遍历、发送命令大批量操作非常慢UI 容易卡.NET 插件netload编译好的 C# 程序集加载进 CAD 进程内执行需要真正干活批量编辑、遍历实体、事务操作需要写插件调试门槛略高DWG 文件解析脱离 CAD 进程直接读写 DWG/DXF不需要服务器端处理、无界面批处理商用库授权成本高文件格式复杂一句话总结我的经验如果只是偶尔连一下 CAD用 COM如果要稳定处理几百张图纸就把业务写成插件加载到 CAD 进程里如果服务器上根本没装 CAD那只能走文件解析路线。三种路线不冲突很多项目的最终形态是 COM 入口 插件干活 文件解析做兜底组合起来用。为什么强调先用这句话开头因为我见过太多人拿着 COM 的方案批量处理图纸跑一次二三十分钟中途 CAD 还弹个对话框进度条直接卡死然后跑来问是不是代码写错了。其实从选型那一刻就已经错了。接下来的章节我会按这三条线一条条说清楚每条都会配上能直接拿去改的代码和我在实际项目里踩过的坑。2. 快速连上一台正在运行的 CADCOM 自动化的正确姿势2.1 从 C# 里找到 CAD 实例并打开图纸COM 方式的核心是拿到 AutoCAD 的 Application 对象。这里我推荐不要直接引用某个版本的 Interop 库因为不同版本 ProgID 不一样引用死了以后换台机器就废了。我用的是通过 ProgID 动态创建然后用 dynamic 调成员using System; using System.IO; using System.Reflection; using Microsoft.Win32; public class CadComConnector { private dynamic _app; public bool Connect(bool visible true) { // 枚举注册表里所有 AutoCAD.Application 开头的 ProgID string progId null; using (RegistryKey key Registry.ClassesRoot.OpenSubKey()) { foreach (string name in key.GetSubKeyNames()) { if (name.StartsWith(AutoCAD.Application)) { progId name; break; } } } if (string.IsNullOrEmpty(progId)) { Console.WriteLine(本机没有安装 AutoCAD 或 COM 组件注册信息已损坏); return false; } Type? t Type.GetTypeFromProgID(progId); if (t null) return false; try { _app Activator.CreateInstance(t); // 连接已在运行的实例 } catch { _app Activator.CreateInstance(t, true); // true 表示如果没运行则启动新的 } _app.Visible visible; return true; } public void OpenDwg(string filePath) { if (_app null) throw new InvalidOperationException(未连接 CAD); dynamic docs _app.Documents; _app.Documents.Open(filePath, true); } }几个细节要提醒。Activator.CreateInstance(type)默认是去连“正在运行的” AutoCAD 实例如果当前没有运行的实例就会抛异常第二个参数传true才会在没有实例时自动启动一个新的。这个行为很关键很多教程只写了CreateInstance(t)结果在没开 CAD 的机器上直接报“CLSID 无效”新手会以为是引用问题。还有一个坑AutoCAD 的 COM 组件在某些版本上支持dynamic但如果你打开的是早期 32 位 CAD而你的 C# 程序集编译成了 AnyCPU 或 x64调用时会报“类未注册”。我一般直接把程序集编译目标设成 x64AutoCAD 2013 以后基本全是 64 位这样省很多事。2.2 打开图纸后遍历图元能跑通但别太乐观连上以后最简单的操作是遍历模型空间的所有实体。下面这段代码是把模型空间里所有圆心的 X 坐标打印出来可以用来做初步验证public void DumpCircles(string filePath) { Connect(); OpenDwg(filePath); dynamic doc _app.ActiveDocument; dynamic modelSpace doc.ModelSpace; int count modelSpace.Count; Console.WriteLine($模型空间实体总数{count}); for (int i 0; i count; i) { dynamic ent modelSpace.Item(i); if (ent.ObjectName AcDbCircle) { Console.WriteLine($圆心坐标{ent.Center.X}, {ent.Center.Y}, {ent.Center.Z}); } } }这里说句实话COM 接口遍历几万个实体时性能很差。我实测过一张中等复杂度的布置图图元数量在两三万级别时用这种方式逐个读取属性耗时能到几十秒。为什么因为 COM 的每一次属性访问都要跨进程做一次 marshaling而且有些版本的 CADItem(index)接口实现还附带类型检查。那 COM 方式在什么场景下是真有价值的我认为有三类给桌面工具做一个“控制 CAD”的按钮。比如从某个系统里选中一台设备点击后打开对应图纸并把视图缩放到这台设备周围发送命令行命令比如_ZOOM、_REGEN、_PLOT把 AutoCAD 当“操作员”用快速读取当前打开图纸的路径、文件名、DWG 版本号等轻量信息。真要大规模批量处理请看下一章把插件挂进 CAD 进程里这才是 C# 干 CAD 的主战场。2.3 用 SendCommand 代替逐个操作但注意窗口焦点COM 里最实用的函数其实是SendCommand它接收一个命令字符串直接投到 CAD 的命令行执行。比如下面的代码可以强制重生成并缩放到全图dynamic doc _app.ActiveDocument; doc.SendCommand(._REGEN ); doc.SendCommand(._ZOOM _E ); // 命令行格式别漏了空格CAD 的命令行靠空格触发执行这里的最低级但最坑的错误命令末尾忘了加空格。其实不是忘了加而是你从 Excel 宏或其他语言迁移过来时习惯性认为SendKeys那种按回车即可但 CAD 命令行解析依赖空格或回车作为命令结束SendCommand传的空格才是真正的“回车”。我一开始漏了结果命令行只输入了一半CAD 毫无反应。另一个经验当你用 COM 控制 CAD 时尽量别让别的窗口抢焦点。CAD 的命令行窗口如果失焦某些需要对话框配合的命令会弹到后台然后程序就卡在那边等你点确定。因此我在上位机里调用 COM 时会把 CAD 窗口Visible true并WindowState 1最大化至少让人知道它正在被控制。3. 真正能扛批量任务的方案把 C# 插件挂进 CAD 进程3.1 从零写出一个能被 netload 加载的最小插件如果你要处理的不是一张两张图而是几十上百张图我强烈建议走插件路线。原理很简单把 C# 写的类库编译成 DLL在 CAD 里用NETLOAD命令加载然后 DLL 里写的命令直接运行在 CAD 进程内和 AutoCAD .NET API 零距离对话。先看一个具备完整骨架的最小命令它的作用是在模型空间画一条直线using Autodesk.AutoCAD.ApplicationServices; using Autodesk.AutoCAD.DatabaseServices; using Autodesk.AutoCAD.Geometry; using Autodesk.AutoCAD.Runtime; namespace CadTools { public class DrawCommands { [CommandMethod(DRAW_LINE)] public void DrawLine() { Document doc Application.DocumentManager.MdiActiveDocument; Database db doc.Database; using (Transaction tr db.TransactionManager.StartTransaction()) { // 打开块表相当于整个图纸的目录 BlockTable bt (BlockTable)tr.GetObject(db.BlockTableId, OpenMode.ForRead); // 打开模型空间图纸内容真正所在的位置 using (BlockTableRecord btr (BlockTableRecord)tr.GetObject(bt[BlockTableRecord.ModelSpace], OpenMode.ForWrite)) { Line line new Line(new Point3d(0, 0, 0), new Point3d(100, 0, 0)); btr.AppendEntity(line); // 把实体添加到模型空间 tr.AddNewlyCreatedDBObject(line, true); // 告诉事务这是一个新对象 } tr.Commit(); } doc.Editor.WriteMessage(\n直线已创建); } } }工程环境要注意的点项目类型选类库.NET Framework不要选 .NET Core 或 .NET 5除非你确定目标机装的是 AutoCAD 2025 这种新版。大多数工厂和设计院还在用 2014 到 2020 版这些版本只支持 .NET Framework 4.x。目标平台设成x64。AutoCAD 本身是 64 位进程你的插件必须也是 64 位用 AnyCPU 在 64 位 CAD 上经常出现“无法加载程序集”的提示。添加引用AcDbMgd.dll数据库相关类型、AcMgd.dll应用程序相关类型这两个文件在 CAD 安装目录下。命令方法必须是public类也必须是public并且要有无参构造函数否则NETLOAD会提示命令类无效。加载方式在 CAD 命令行输入NETLOAD选中编译好的 DLL然后输入DRAW_LINE。如果一切正常模型空间里会多出一条直线命令行显示“直线已创建”。3.2 CAD 的“数据库模型”到底是怎么回事第一次接触 .NET API 的人很容易被Transaction、BlockTable、BlockTableRecord三个词劝退。我尽量用大白话解释。你可以把整个 DWG 文件当成一个数据库。数据库文件的“表”里存着各种符号定义块定义、图层、文字样式、线型其中最重要的是“块表”。模型空间本身也是一个“块表记录”图纸里绝大多数几何图元都被存放在这一条记录下面。所以你要往图里画东西就必须启动事务Transaction——相当于 SQL 里的BEGIN TRANSACTION打开块表BlockTable——相当于打开表清单打开模型空间这块表记录BlockTableRecord——相当于打开数据表往里面追加实体——相当于INSERT INTOCommit()提交事务——相当于COMMIT改了才真正落盘。为什么要强制走事务因为 CAD 的多文档、撤销、外部参照、命令中断机制全都建立在事务之上。如果你在图面上改了实体但不 commit或者忘了 dispose 未提交事务轻则改动不生效重则可能导致 CAD 图形数据库状态错乱保存时出现“图形文件被锁定”或崩溃。这套类比理解之后你去看网上各种 .NET API 的代码基本都能看懂了。发现没有所有正经代码里都有一行.TransactionManager.StartTransaction()不是惯例是底层架构的硬性要求。3.3 外部上位机如何和 CAD 插件配合我推荐的通信姿势插件写好了但你是用它开发上位机不可能每次都让用户手动敲NETLOAD更不可能让用户敲命令。最稳的做法是插件启动时自动开启一个命名管道服务端上位机作为客户端往管道里发 JSON 指令CAD 进程内执行任务后把结果写回来。我在一个车间图纸管理项目里就是这么做的。上位机界面点“读取当前图纸设备数”程序往命名管道发一段消息{task:count_blocks,blockName:EQUIP}CAD 进程里的插件监听到消息立即遍历当前图纸里的块引用把计数和每个块的坐标、属性拼成 JSON 回传。上位机收到结果后刷新 UI全程不卡界面也不用管 COM 的跨进程性能问题。一个简单的命名管道服务端骨架如下using System.IO; using System.IO.Pipes; using System.Text; using System.Text.Json; // 这通常放在 IExtensionApplication.Initialize() 里启动 NamedPipeServerStream server new NamedPipeServerStream( CadPipe_YourApp, PipeDirection.InOut, 1, PipeTransmissionMode.Byte); Task.Run(async () { while (true) { await server.WaitForConnectionAsync(); using (StreamReader reader new StreamReader(server, Encoding.UTF8)) using (StreamWriter writer new StreamWriter(server, Encoding.UTF8)) { string request await reader.ReadLineAsync(); if (request ! null) { string response ProcessRequest(request); // 这里执行 CAD 操作 await writer.WriteLineAsync(response); await writer.FlushAsync(); } } server.Disconnect(); } });这样方案的好处是显而易见的上位机完全不需要引用任何 AutoCAD 程序集未来 CAD 换版本也不影响大批量处理都在 CAD 进程内原生执行速度比 COM 快一个数量级进程通过命名管道隔离CAD 崩溃不至于把上位机带崩。如果你不想自己造管道轮子也可以直接上一个轻量的本地 HTTP 服务比如Kestrel监听http://localhost:23456CAD 插件里启动 WebHost。效果类似只是部署时多注意端口冲突问题。管道的好处是免端口、适合局域网/Win 服务环境到处能用不需要管理员权限。4. 不启动 CAD 图形界面也能批处理核心控制台与纯文件方案4.1 用 accoreconsole.exe 做无头批处理后来项目越来越大客户要求在服务器上定时做批量合并和属性提取服务器上不能弹 CAD 窗口也不能登录用户桌面。这时候不能用带界面的 AutoCAD但还有一条路AutoCAD 核心控制台accoreconsole.exe。accoreconsole.exe随 AutoCAD 一起安装在安装目录下比如C:\Program Files\Autodesk\AutoCAD 2024\accoreconsole.exe它不需要完整图形界面启动后就是一个命令行进程可以打开 DWG、加载你的 C# 插件、执行命令、保存退出。配合脚本文件.scr就能做无头批处理命令大体如下C:\Program Files\Autodesk\AutoCAD 2024\accoreconsole.exe /i D:\dwg\input.dwg /s D:\scripts\run.scrrun.scr内容示例NETLOAD D:\plugins\CadTools.dll PLUGIN_EXPORT_BLOCKS _QSAVE _CLOSE其中_QSAVE是保存当前图纸_CLOSE是关闭文档。这样每次处理一张图脚本结束后进程退出。如果你的批量任务是“遍历一个文件夹下所有 DWG”用 C# 写一个外层程序循环调用这个命令行即可非常稳定。这里要特别提醒accoreconsole 是无窗口环境插件里不能弹对话框、不能依赖Application.DocumentManager.MdiActiveDocument的某些 UI 交互。在插件代码里读取当前文档的入口和普通 CAD 一样但凡是涉及doc.Editor.GetString()这种交互输入的命令跑在控制台里会直接失败挂起。所以批处理插件要单独写成“无交互”模式参数全部从外部传入。4.2 纯 C# 打开 DWG 文件比你想的更复杂如果服务器上连 AutoCAD 都没装就只能走纯文件解析。这也是“C# 直连 CAD”被搜索最多的含义之一。很遗憾技术现实比较骨感DWG 是一个未完全公开、且历版本不断演变的二进制格式。直接写一个纯 C# 解析器能实现但维护成本高到不现实。真正靠谱的路径是这三条方案说明适用性ODA Drawings SDK老牌 Open Design Alliance 提供的商业 SDK有 .NET 封装支持各种版本的 DWG 读写预算充足的企业项目、服务器批量处理首选netDXF / dxf-codegen 等开源库只能解析 DXF 文本格式DXF 是 DWG 的交换格式无法直接读现代加密 DWG内部格式统一、对旧版本兼容要求不高的项目AutoCAD/中望 CAD 命令行批处理不写解析器直接调用文件所属 CAD 的无头模式服务器允许安装 CAD 授权批处理体量大我做过的几个项目里只有一个是“服务器不装 CAD”的当时选了 ODA 的 .NET 绑定来处理 DWG 转 DXF 再交给上位机做数据读取。这里要提一个常见的心理预期问题很多同学以为“读取 DWG”像读取 XML 一样简单实际上一张 DWG 里面除了图元几何还有块表记录、扩展数据、代理实体、图形缓存、坐标转换表等一堆结构缺一样都无法正确还原图纸。即使你用 ODA也建议先做个“读取后用 CAD 打开对比”的验证步骤。如果只是读 DXF开源库确实方便示例代码如下netDXFusing netDxf; DxfDocument dxf DxfDocument.Load(drawing.dxf); foreach (var entity in dxf.Entities) { if (entity.Type EntityType.Circle) { Circle circle (Circle)entity; Console.WriteLine($圆心 {circle.Center.X}, {circle.Center.Y}, 半径 {circle.Radius}); } }但这套东西有一个无法绕过的边界DXF 不等于 DWG尤其是高版本 AutoCAD 的 DWG 经过压缩和扩展导出成 DXF 时可能丢自定义对象、动态块行为、打印样式等数据。所以如果你要做的是专业的全量数据处理别过度指望开源纯解析能解决所有问题。5. 实战组合批量合并 DWG 图纸并导出设备属性表5.1 在插件里把 N 张图纸“搬”进同一张总图这是我被问得最多的需求“我手头有几十张分专业的设备布置图想全部合到一张总图里最好每个专业放到不同的区域。”用 .NET API 实现的核心是把另一个 DWG 文件作为“块”插入当前数据库。步骤拆解using Autodesk.AutoCAD.DatabaseServices; private ObjectId InsertExternalDwg(Database destDb, string srcFile, string blockName, Point3d position) { ObjectId blockId; using (Database srcDb new Database(false, true)) { // 1. 把源 DWG 读入一个临时数据库 srcDb.ReadDwgFile(srcFile, FileShare.Read, true, ); // 2. 把临时数据库的所有内容作为块定义插入到目标数据库 blockId destDb.Insert(blockName, srcDb, true); } // 3. 在模型空间中创建一个块引用摆放到指定位置 using (Transaction tr destDb.TransactionManager.StartTransaction()) { BlockTable bt (BlockTable)tr.GetObject(destDb.BlockTableId, OpenMode.ForRead); BlockTableRecord ms (BlockTableRecord)tr.GetObject(bt[BlockTableRecord.ModelSpace], OpenMode.ForWrite); BlockReference bref new BlockReference(position, blockId); ms.AppendEntity(bref); tr.AddNewlyCreatedDBObject(bref, true); tr.Commit(); } return blockId; }这段代码有两个关键点。第一Database.Insert插入的是“块定义”而不是“实体”。真正画在总图里的是BlockReference它只是块定义的一个引用实例。理解了这个模型你才能理解为什么合并 DWG 后源文件里的图元不是平铺在模型空间里而是装在了一个块里。如果你希望合并后能够自由编辑各个图元得在插入后再对块引用执行“炸开”或者插入时考虑用Application.DocumentManager的方式复制实体。但现实项目里“保留各专业作为一个块”往往比“炸开平铺”更合理因为总图上有颜色、隐藏、整体移动等需求。第二块名冲突问题。多个专业图纸里极大概率都有“设备”“标注”“标题栏”这类通用块名。Insert遇到同名块时会返回既有块定义导致后插入的图纸内容不全或张冠李戴。我的处理惯例插入前先检查目标数据库块表里是否已存在该块名存在则给新块名加前缀或序号比如MECH_EQUIP_01、ELEV_EQUIP_02using (Transaction tr destDb.TransactionManager.StartTransaction()) { BlockTable bt (BlockTable)tr.GetObject(destDb.BlockTableId, OpenMode.ForRead); if (bt.Has(blockName)) { blockName ${prefix}_{blockName}_{DateTime.Now.Ticks % 1000}; } tr.Commit(); }这个方法不完善但已经能躲开 90% 的重名坑。剩下 10% 还真需要更复杂的“局部插入 符号表重命名”策略建议等项目真遇到了再深入不要一开始就把方案设计得太重。5.2 遍历块引用把设备编码和型号属性全导出来合并完图纸通常紧接着就是提取块属性。制造业和设计院习惯把“设备编号”“型号”“安装位置”“备注”写成块的属性Attribute而不是普通文字。上位机要从图里拿到这些结构化数据就得遍历块引用和它的属性集合。这里给一段在插件里提取所有块引用属性的代码并把结果输出到 CSVusing Autodesk.AutoCAD.DatabaseServices; using System.IO; using System.Text; public void ExportBlockAttributes(string csvPath) { Document doc Application.DocumentManager.MdiActiveDocument; Database db doc.Database; StringBuilder sb new StringBuilder(); sb.AppendLine(BlockName,X,Y,Tag,Value); using (Transaction tr db.TransactionManager.StartTransaction()) { BlockTable bt (BlockTable)tr.GetObject(db.BlockTableId, OpenMode.ForRead); BlockTableRecord ms (BlockTableRecord)tr.GetObject(bt[BlockTableRecord.ModelSpace], OpenMode.ForRead); foreach (ObjectId id in ms) { Entity ent (Entity)tr.GetObject(id, OpenMode.ForRead); if (ent is BlockReference br) { string blockName br.GetEffectiveName(); if (string.IsNullOrEmpty(blockName)) continue; // ResetAttributes 用于确保块引用上的属性值与块定义一致 br.ResetAttributes(); AttributeCollection atts br.AttributeCollection; // 如果没有属性至少记录块名和坐标 if (atts.Count 0) { sb.AppendLine(${blockName},{br.Position.X},{br.Position.Y},); continue; } foreach (ObjectId attId in atts) { AttributeReference att (AttributeReference)tr.GetObject(attId, OpenMode.ForRead); sb.AppendLine(${blockName},{br.Position.X},{br.Position.Y},{att.Tag},{att.TextString}); } } } tr.Commit(); } File.WriteAllText(csvPath, sb.ToString(), Encoding.UTF8); }这个例子用了GetEffectiveName()而不是直接取Name原因是动态块的实例名通常是动态块名加随机后缀而业务上你要统计的是“原始块定义”的名称。这个细节我在一个自动化仓库项目里吃过亏统计时所有动态块的块名长得都不一样导致数量永远对不上。属性读取这里还有一个隐藏的问题某些图纸里的块属性可能被二次修改过但属性标签顺序不一致。如果你要按固定表头导出建议先遍历一遍所有块引用收集标签的并集再生成 CSV 表头而不是硬编码列顺序。我们在一个出图系统里就是这么做的第一版固化了四列结果遇到一张有“供应商”属性的图纸整行全部错位后来改成动态列才解决。另外ResetAttributes()在图纸很大、块引用很多时是有性能开销的不是必需就别对这个方法形成路径依赖。我的实践是如果块属性和块定义一致没有做属性覆盖可以不加这一行直接读AttributeCollection只有当你怀疑某些块实例属性被单独改过、或者之前用 LISP 批量改过属性才需要强制刷新。6. 直连 CAD 开发中防不胜防的环境兼容问题6.1 CAD 本体没装好后面一切白搭做 C# 直连 CAD第一步其实不是写代码而是确认机器的 CAD 环境是健康的。热搜里那些“cad 安装”“cad 卸载工具”“cad 显示已经安装了但是不见软件”看着是普通用户的问题但我在开发过程中同样被环境问题坑过。最典型的是 COM 直连时报“检索 COM 类工厂中 CLSID 为 ... 的组件失败”。这时候如果去翻代码永远查不出原因因为问题出在 AutoCAD 的 COM 注册表信息损坏。排查思路是先在 Windows 的“程序和功能”里看 AutoCAD 是否完整安装用 AutoCAD 安装包自带的“修复”功能跑一遍它会把 COM 组件、注册表项重新注册如果修复后仍不行把 CAD 卸载干净清理残留目录和注册表项再重新安装安装时务必关掉杀毒软件二次开发时杀软拦截 DLL 加载也是常见问题。记住安装 CAD 是不适合用网上那些“一键卸载工具”的。很多卸载工具会把某些公共 C 运行库一并卸载搞挂系统里一堆软件。最稳妥的卸载方式始终是官方卸载程序或系统的“程序和功能”卸载完成后手动删除安装目录和%AppData%\Autodesk下的残留即可。6.2 CAD 版本、.NET 框架版本、位数必须三头对齐插件版和 COM 版对版本要求有很大差异。COM 方式用dynamic时只要你安装的是 2013 以后的 64 位 CAD基本问题不大但插件版讲究很多我整理了一张我自己项目里的对照表CAD 版本支持的 .NET 框架插件编译建议AutoCAD 2014 ~ 2019.NET Framework 4.0 ~ 4.7编译目标选 .NET Framework 4.5 或 4.7AutoCAD 2020 ~ 2024.NET Framework 4.7 / 4.8编译目标选 .NET Framework 4.7.2 以上AutoCAD 2025支持 .NET 8官方逐步推进新项目可尝试 net8.0-windows还有一条被反复问的“为什么我编译成 AnyCPUNETLOAD 提示无法加载”因为 AutoACD 2020 及以后的几乎全是 64 位进程插件如果按 AnyCPU 编译在 x64 进程里加载 i386 兼容层经常出问题。直接把解决方案平台设为 x64一劳永逸。另外如果在 32 位旧版 CAD 上做插件开发2013 之前还可能遇到那插件也要编译成 x86。反正就一个原则插件位数跟随 CAD 进程位数。6.3 上位机 UI 卡死问题线程模型和 COM 的恩怨热词里有个“c# 控件多致 winform 卡”这个我在做 CAD 直连上位机时深有体会。很多人把 COM 调用直接丢到主线程执行CAD 一但慢界面全卡住看起来就像 WinForm 控件太多导致的。其实控件再多只要不频繁重绘都不至于卡死真正的元凶是你在 UI 线程做了跨进程的同步 COM 调用。正确的做法是所有 COM 相关操作放到后台线程执行用Invoke或await把结果回传 UI。但这里又有一个隐藏的线程坑AutoCAD COM 的线程模型是 STA 的你在后台线程如果需要启动新的 COM 实例必须让线程标记为 STA。Thread t new Thread(() { CadComConnector con new CadComConnector(); con.Connect(); // 这里做 CAD 操作 }); t.SetApartmentState(ApartmentState.STA); t.Start();不设 STA 的话在部分 CAD 版本上 COM 调用会静默失败或者抛异常。这个排查方向很容易被忽略因为普通 COM 组件没这么讲究。如果你还是嫌 COM 线程管理麻烦建议多花点时间把业务下沉到插件里用命名管道或 HTTP 通信。上位机那个进程就不碰 CAD COM 了UI 卡顿问题直接从根上消失。6.4 中望 CAD 作为替代接口兼容但别拿细节当不变契约这些年不少项目因为授权或国产化要求把 AutoCAD 换成了中望 CAD。中望的 .NET API 在很多基本类型和命名空间上跟 AutoCAD 保持兼容比如Autodesk.AutoCAD.DatabaseServices这些命名空间很多代码可以直接编译加载。我试过把自己写的 AutoCAD 插件拿到中望 CAD 里 netload大部分命令能跑。但是不要因为“基本兼容”就在两个平台之间无脑复用。我实际遇到过几个差异点中望 CAD 的某些 API 在事件触发时机上和 AutoCAD 不同比如数据库保存前的事件在大量图元修改时表现有差异动态块相关 API 的支持没有 AutoCAD 完整尤其是动态块属性自定义部分点选交互、选中集过滤这类界面交互 API虽然签名一致但某些参数的中文提示和默认行为略有区别。如果你的客户既要 AutoCAD 又要中望 CAD项目里一定要在前期做一个“双平台冒烟测试”加载插件、画几条线、读属性、保存图纸。别等开发完成后再去适配那时候改造成本就很难受了。7. 一点额外的工程体会说到这儿我觉得最值得分享的一条个人体会是做 C# 直连 CAD80% 的问题出在环境而不是代码。版本、位数、COM 注册、.NET 框架、授权任何一个环节不对程序写得再漂亮也白搭。所以我现在的习惯是不管接到什么新项目先花半天时间把开发机整理干净CAD 用正版授权一次性安装到位组件用官方修复工具检查插件编译平台统一 x64。别在这种事上省钱后面省下的都是调试时间。第二个体会是关于“批量”的门槛。很多人一上来就写一个函数处理一个文件夹下的所有 DWG结果跑到第 37 张图崩了。我的方法是先跑通一张图再跑通三张图最后全量跑。一张图能成功代表代码逻辑没问题三张图能成功代表你已经处理了大部分重名、字体缺失、版本不统一的问题全量跑还崩溃那通常就是极个别图纸的数据特殊单独标记出来人工处理就可以了。这听起来很笨但确实能让你少掉不少头发。最后一个实用收尾技巧调试插件时别老盯着 CAD 窗口看,可以在插件里用File.AppendAllText写一个运行日志把每次进入命令、处理到第几个对象、结果是什么都记下来。遇到批量处理崩溃时日志能让你快速定位到底是哪张图、哪一个对象触发了异常。这个土办法比任何高级调试器都管用在不少产线上陪我熬过了深夜。