做AutoCAD .NET二次开发的人，绕不开的第一个知识点就是CommandMethod。它看起来只是一行特性声明，但背后其实是AutoCAD命令注册机制从C++时代的命令表到.NET反射机制的一次大转变。我见过不少刚入门的开发者，在这个特性上栽跟头：命令加载了却找不到、中文版命令名不生效、命令执行到一半卡死、撤销行为混乱……这些问题追根溯源，基本都是对CommandMethod的工作原理和细节理解不够。
这篇文章我打算从一个踩过不少坑的开发者的角度，把CommandMethod的底层机制、常用写法、CommandFlags的用法，以及它和事务、选择集、多文档环境怎么配合，完整梳理一遍。最后还会附上我整理过的常见问题排查表，方便你直接对照处理。内容同时适合刚接触AutoCAD .NET二次开发的新手，也想给已经写了不少命令但偶尔被奇怪问题缠住的老手提供一份体检查漏单。
1. CommandMethod到底是什么：一次“声明式”命令注册革命
1.1 回忆一下ObjectARX时代的命令注册方式
在.NET托管API出现之前，用C++写ObjectARX程序时，注册命令是一个相当繁琐的工作。你要在AcRx应用初始化时，从acedRegCmds这个全局命令管理器里调用addCommand，传入命令组名、全局命令名、本地化命令名，以及一个函数指针作为回调。代码大概长这样：
static void myAppGroupMyCommand() { // 命令实际执行的逻辑 } static void initCommands() { acedRegCmds->addCommand( L"MYGROUP", // 命令组名 L"MYCMD", // 全局命令名 L"我的命令", // 本地化名称 ACRX_CMD_MODAL, // 命令工作模式 myAppGroupMyCommand ); }这种方法本质上是在程序运行时，手动把命令名和一个函数地址挂到AutoCAD的命令表里。每次新增命令，都要同时写回调函数和注册代码，然后还要记得在卸载时removeGroup清理。如果命令一多，这些模板代码非常占地方，而且一旦注册顺序或返回值处理不对，会直接影响命令的可用性。更麻烦的是，C++那边一个函数指针暴露给AutoCAD后，如果DLL卸载时没有撤销注册，很容易让CAD进程崩溃——这种崩溃通常还没有任何日志，排查难度直接拉满。
所以早年做CAD二次开发，光是“让一个命令能跑起来”这一件事，就要做很多环境级别的准备工作，对新手确实不太友好。
1.2 CommandMethod的底层原理：反射+命令表
到了托管API普及之后，AutoCAD提供了CommandMethodAttribute，也就是我们现在最常用的[CommandMethod]特性。你可以把它理解成一种“声明式注册”：你只需要在普通的方法上贴一个特性，AutoCAD在加载程序集时，会通过反射扫描所有公开类型，找到带这个特性的方法，然后自动帮你完成命令表的注册。
using Autodesk.AutoCAD.Runtime; namespace MyCadTools { public class MyCommands { [CommandMethod("HELLO")] public static void HelloWorld() { Autodesk.AutoCAD.ApplicationServices.Core.Application.DocumentManager .MdiActiveDocument.Editor.WriteMessage("\nHello from .NET command!"); } } }这个转变的意义不只是“少写了几行代码”，而是把命令注册从“命令式的指令操作”变成了“声明式的元数据标注”。你在源代码里看到[CommandMethod("HELLO")]，就能立刻知道这个方法是给AutoCAD命令行用的入口，不需要再去全局注册表里翻名称和回调地址的对应关系。
AutoCAD内部拿到这些反射信息后，会把它翻译成传统命令表中的一行记录，包括命令组、全局名、本地名和执行标志。所以从AutoCAD引擎的视角来看，.NET命令最终和C++命令没有本质区别，只是用了不同的注册路径。而在开发者视角里，维护成本却低了一大截。
这里插一句，实际编码时，我习惯在public class MyCommands上面再放一个[CommandClass(typeof(MyCommands))]特性。虽然很多情况下AutoCAD能自动发现命令方法，但显式声明命令类能减少一些边界环境下的扫描问题，也让代码意图更明确。
1.3 为什么说它降低的是“可持续维护”的门槛
初学的时候你可能会觉得，CommandMethod特性不就是一个固定的写法吗？命令能跑不就行了？但真正做过大型插件的人会明白，一个插件里几十上百个命令时，命令命名规范、命令分组、本地化名称管理、标志位设置，这些都直接影响后续的交付。
举个例子，我见过某个项目里所有命令都用[CommandMethod("DOTEST")]这种泛泛的名字注册，结果插件装到甲方机器上，和另一个CAD插件撞了命令名，两个命令互相覆盖，最后谁后加载谁生效，问题非常难查。如果从一开始就规划好命令组、全局名统一加项目前缀，就不会出现这种尴尬。
CommandMethod特性还让批量审视命令变得容易。你打开一个类文件，扫一眼所有的方法签名和特性参数，就能看出这个插件暴露了哪些能力、每个命令受什么限制、是否有重名风险。这种“一眼可见”的效果，是传统命令表注册方式很难提供的。
2. 写命令前，先理清这几个基本概念
2.1 全局名称、本地化名称和命令组名
CommandMethod最简单的用法是只传一个命令名。但从AutoCAD命令系统的完整设计来看，一个命令其实涉及三个层面的名称：
| 名称类型 | 作用 | 典型示例 |
|---|---|---|
| 全局命令名 | 跨语言环境通用的规范名称，脚本、菜单宏、LISP调用时最稳定 | CIRCSTATS |
| 本地化名称 | 面向当前语言环境显示的中文或本地语言名称，方便中文版用户在命令行直接输入 | 圆统计 |
| 命令组名 | 用于对一组命令进行分类管理，某些场景下可用“组名.命令名”形式调用 | MYCADTOOLS |
我刚接触的时候，一直以为中文版CAD里只要写了英文全局名，用户就无法使用中文命令。后来才发现，通过多参数构造函数，可以把全局名和本地化名称同时注册进去。比如：
[CommandMethod("MYCADTOOLS", "CIRCSTATS", "圆统计", CommandFlags.Modal)] public static void CircleStats() { }这里第一个参数是命令组名，第二个是全局命令名，第三个是本地化名称，第四个是命令标志。注意，不同CAD版本的SDK对这个重载的签名细节略有差异，如果你编译时发现某个构造函数不存在，最好以当前版本IntelliSense提示为准。
那到底该用全局名还是本地名？我的建议是：全局名用英文且带项目前缀，本地化名称用中文；凡是脚本、菜单、外部程序调用，一律用全局名。因为全局名在不同语言版本的CAD中稳定不变，而本地化名称在不同语言环境里可能不一样。比如中文版里你注册了“圆统计”，到了英文版CAD环境，这个中文命令名就可能失效，但CIRCSTATS在任何语言版本都能被识别。
2.2 CommandFlags常见标志逐个拆解
CommandFlags枚举控制着命令的执行模式，这部分是最容易“凭感觉写”但实际影响很大的地方。我挑几个日常开发里频率最高的标志说一下：
CommandFlags.Modal：默认值，表示模态命令，命令执行期间用户不能同时执行其他AutoCAD命令，直到当前命令返回。大多数常规命令都适用。CommandFlags.Transparent：透明命令，允许用户在另一个命令执行过程中调用它，类似AutoCAD自带的'PAN、'ZOOM。比如你自己做了一个实时缩放窗口的小工具，就要用这个标志。不过透明命令里有严格限制，不能修改数据库，否则容易出现不可预期的状态。CommandFlags.UsePickSet：允许命令使用当前选择集。如果你写了一个“批量改图层”命令，希望在用户先框选对象后直接执行命令，而不弹出再次选择提示，这个标志就很关键。CommandFlags.Session：表示命令可以在没有打开任何文档时执行。配合Application.DocumentManager.MdiActiveDocument可能为null的情况，适合做环境初始化、配置读写这类不依赖具体图纸的操作。CommandFlags.NoPaperSpace、CommandFlags.NoTileMode：分别限制命令在图纸空间和模型空间中的使用。有些命令只对模型空间有意义（比如全图统计），在图纸空间跑容易出错，加上限制反而能减少误用。CommandFlags.NoBlockEditor：禁止在块编辑器中执行该命令。CommandFlags.Redefine：允许重新定义一个AutoCAD内置命令。这个比较危险，除非你确实要覆盖某个原生命令的行为，否则不要乱加。
多个标志可以用按位或组合，比如：
[CommandMethod("BATCHLAYER", CommandFlags.UsePickSet | CommandFlags.NoPaperSpace)] public static void BatchChangeLayer() { }这条命令就允许使用当前选择集，同时限定不能在图纸空间使用。实际项目里，“批量处理类”命令经常这么设计。
2.3 一个方法注册多个命令，以及命令名冲突规避
有些场景下，两个命令名本质指向同一套逻辑，只是可能面向不同调用习惯。比如一个命令既想给中文用户用，又想保留英文全局名。这时除了用多参数构造函数的本地化名称，还可以直接在一个方法上叠加多个[CommandMethod]特性：
[CommandMethod("MY_LENGTH")] [CommandMethod("我的长度")] public static void ShowLength() { // 同一个命令逻辑，两种调用入口 }这种写法在C#里依赖特性是否允许重复标记。CommandMethodAttribute默认是可以多次使用的，我实际验证过，同一个方法标记两个命令名没有任何问题。但要注意一个隐藏风险：如果两个命令名和别人插件里的命令撞了，AutoCAD默认是“后加载者覆盖先加载者”，这种覆盖有时是提示性的，有时是静默的，很容易导致现场环境行为不一致。
所以我个人经验是，所有命令名尽量带一个两到四个字符的项目前缀，比如公司缩写。这跟命名空间隔离是一个道理。只要在命令行输入MY_LENGTH，就知道是你这个插件提供的，找问题也有方向。
另外，命令名还有一些硬性限制：不能包含空格，不能包含/、\、;、.等特殊符号，长度建议控制在31个字符以内。如果命令名不合法，AutoCAD在加载时可能会直接跳过注册，还不会给你明确报错，这一点很多人容易忽略。
3. 从零实现一个可用命令：完整实操流程
3.1 环境准备：SDK、引用和框架版本
开始写代码之前，先把环境和引用安排好。AutoCAD .NET API的主要程序集是acdbmgd.dll、acmgd.dll和accoremgd.dll。不同版本CAD对应的.NET Framework版本不同，比如AutoCAD 2021到2024主流还停留在.NET Framework 4.7/4.8，2025开始才逐步面向.NET 8迁移。这个差异直接影响你能用哪些API。
我的建议是，在Visual Studio里建一个类库项目，目标框架先对齐你当前主要交付的CAD版本，然后通过NuGet引入AutoCAD.NET相关的包，比如AutoCAD.NET.Core和AutoCAD.NET.Helpers，而不是直接手动浏览DLL引用。这样升级版本时方便管理。
引用放置好之后，记得把项目中三个核心DLL的属性设置为“复制本地=False”，避免生成目录里带一堆冗余DLL。实际加载时，AutoCAD会从自身安装目录加载同名程序集。
3.2 用“HELLO”验证你的命令链路
万事开头难，但命令链路验证其实很简单。我每次新建一个插件项目，第一件事就是写一个最简命令：
using Autodesk.AutoCAD.ApplicationServices; using Autodesk.AutoCAD.EditorInput; using Autodesk.AutoCAD.Runtime; namespace MyCadTools.Commands { public class DemoCommands { [CommandMethod("MY_HELLO", "你好CAD", CommandFlags.Modal)] public static void Hello() { Document doc = Application.DocumentManager.MdiActiveDocument; Editor ed = doc.Editor; ed.WriteMessage("\n命令链路正常，当前图纸：{0}", doc.Name); } } }编译后，在AutoCAD命令行执行NETLOAD命令，选择生成的DLL。如果加载成功，再输入MY_HELLO或中文命令“你好CAD”，命令行应该会输出那句提示。这一步跑通，说明你的开发环境、程序集版本、命令注册链路都没问题。
可能有人会问，NETLOAD不是每次都要手动执行吗？正式交付时当然要做注册表加载或启动时自动加载，但开发期用NETLOAD最快。某些安全策略严格的环境里，NETLOAD可能被禁用，那就要先检查SECURELOAD系统变量和可信路径设置。这不是本文重点，但遇到加载失败时优先排查这两个点。
3.3 一个真实场景：统计图纸中圆的数量与总周长
理论讲再多，不如直接跑一个有用的小工具。我们来实现一个“统计圆的数量和总周长”的命令，核心是用选择集让用户挑圆，然后遍历数据库对象计算数据。
using Autodesk.AutoCAD.ApplicationServices; using Autodesk.AutoCAD.DatabaseServices; using Autodesk.AutoCAD.EditorInput; using Autodesk.AutoCAD.Runtime; namespace MyCadTools.Commands { public class CircleStatsCommands { [CommandMethod("MY_CIRCSTATS", "圆统计", CommandFlags.UsePickSet)] public static void CircleStats() { Document doc = Application.DocumentManager.MdiActiveDocument; Database db = doc.Database; Editor ed = doc.Editor; // 构造选择提示 PromptSelectionOptions opts = new PromptSelectionOptions { MessageForAdding = "\n选择要统计的圆: " }; PromptSelectionResult selRes = ed.GetSelection(opts); if (selRes.Status != PromptStatus.OK) { return; } int count = 0; double totalLength = 0.0; // 所有数据库对象的读写都要放在事务里 using (Transaction tr = db.TransactionManager.StartTransaction()) { foreach (ObjectId id in selRes.Value.GetObjectIds()) { Circle circle = tr.GetObject(id, OpenMode.ForRead) as Circle; if (circle == null) { continue; } count++; totalLength += circle.Circumference; } tr.Commit(); } ed.WriteMessage("\n选中的圆：{0} 个，总周长：{1:F2}", count, totalLength); } } }这段代码有几个关键点。第一，GetSelection之前可以加PromptSelectionOptions，但无论是否加选项，命令执行前用户都可以先框选对象，因为命令带上了UsePickSet标志。第二，遍历实体时用tr.GetObject而不是直接id.GetObject()，这是一种更安全的获取数据库对象的方式，能够正确解析已擦除或状态特殊的对象。第三，事务一定要Commit，否则你对数据库的所有修改都会在事务被Dispose时回滚。
这个命令在真实图纸里跑的时候，我遇到过一个问题：用户选择集里混入了大量直线和多段线，虽然代码里通过as Circle做了类型过滤，但如果图纸中圆非常多，遍历几万条记录时还是会有些慢。此时可以先用ed.SelectAll配合SelectionFilter，只选中圆形对象，效率会好很多。
3.4 和用户交互：GetEntity和GetSelection的取舍
很多命令不只是“让用户选择一批对象”，而是要让用户逐个拾取实体。比如“计算一条直线长度并标注”这类命令，就需要用GetEntity。
[CommandMethod("MY_LINELEN", "直线长度", CommandFlags.Modal)] public static void ShowLineLength() { Document doc = Application.DocumentManager.MdiActiveDocument; Database db = doc.Database; Editor ed = doc.Editor; PromptEntityOptions opt = new PromptEntityOptions("\n选择一条直线: "); opt.SetRejectMessage("\n只能选择LINE对象。"); opt.AddAllowedClass(typeof(Line), true); PromptEntityResult res = ed.GetEntity(opt); if (res.Status != PromptStatus.OK) { return; } using (Transaction tr = db.TransactionManager.StartTransaction()) { Line line = tr.GetObject(res.ObjectId, OpenMode.ForRead) as Line; if (line != null) { ed.WriteMessage("\n直线长度: {0:F2}", line.Length); } tr.Commit(); } }这里AddAllowedClass的第二个参数表示是否包含子类。如果你只允许线段，不允许多段线，传true会影响继承类的判断，具体要看你的需求。
我自己的习惯是：如果命令只需要用户选一次，优先GetEntity；如果命令是“批量处理”，优先GetSelection，并且配合UsePickSet让用户可以先框选再执行命令。两种交互方式获取到的ObjectId，后续都要放到事务里读。
4. 事务与文档环境：命令方法里最容易翻车的两件事
4.1 为什么说事务“开完必须Commit或Dispose”
AutoCAD .NET API里，数据库操作默认是基于事务模型的。事务的意义在于：一组数据库读写操作要么全部成功，要么全部回滚，保证数据库状态一致。很多新手只记得StartTransaction，却忘记Commit，结果改动没写进图纸，或者更糟——事务对象一直没释放，导致数据库对象被锁定。
这里给一个明确的规范：任何Transaction对象都必须放进using块，并且在正常分支里调用tr.Commit()。如果命令在中途因为用户点Esc取消、或者发生异常，事务会随using块自动Dispose，所有未提交的修改自动回滚。这恰好是AutoCAD保证安全的方式，不需要你自己费心处理回滚逻辑。
但有一种情况要特别注意：如果你在事务里已经打开了一个对象进行写操作，然后中途等待用户输入，比如调用ed.GetString()，这时候事务处于悬空状态，数据库修改被挂起，可能导致界面卡死或者对象被锁。我见过一个真实案例，某插件在事务中弹出输入框让用户填参数，结果用户切到别的图纸看了一眼，再回来就发现AutoCAD处于“等待用户输入+事务未提交”的状态，整个界面僵在那里。解决办法是，把所有用户交互都放在事务开启之前完成，拿到参数后再开事务修改数据库。
4.2 文档锁到底要不要自己加
很多初学者看过一些老代码，习惯在命令方法里写doc.LockDocument()，然后包一个using块。其实在普通的模态命令里，AutoCAD会在命令执行期间自动获得当前文档锁，你根本不需要手动加锁。真正需要手动LockDocument()的场景，是你在一个命令里要修改另一个文档的对象，或者通过后台线程操作数据库时。
比如你正在运行MY_CIRCSTATS命令，中间需要打开另一个dwg文件并把统计结果写进去，这时那个目标文档并没有被当前命令锁定，就必须用doc2.LockDocument()。不锁的话，轻则提示“文档忙”，重则造成文档对象状态损坏。
加锁时还有一个细节：锁对象最好也用using包裹，确保在命令结束时释放。不要在一个命令方法里反复LockDocument()，第一次已经锁住了，再次加锁如果没有正确配对，很容易造成死锁。这里的原则是：命令作用于当前文档时不用锁，跨文档操作时按文档维度统一锁，不重复不遗漏。
4.3 交互式命令中事务的生命周期
有些命令需要多轮交互。比如“批量修改文字高度”，先让用户选择文字对象，再输入新高度，最后批量修改。在这个过程里，最稳妥的流程是：
- 用
GetSelection获取ObjectId集合； - 用
GetString或GetDouble获取新参数； - 开启事务，遍历集合进行修改，Commit；
- 结束命令。
千万不能在第一步就开事务，然后一边等用户输入一边持有事务。原因前面说过：用户输入期间命令挂起，如果事务还持有某些对象的写锁，会直接影响用户在AutoCAD界面上的其他操作。尤其在大型图纸里，这种锁会积累成难以定位的性能问题。
如果业务流程确实需要“边选择边检查”，那就分成多个短事务，选择阶段的数据读完之后立刻提交或释放，等所有交互都结束，再开一个写事务做最终修改。这样既保证数据一致性，也不会让用户感到CAD“变卡了”。
5. 当命令遇到“外部世界”：多文档、LISP、其它命令
5.1 用SendStringToExecute调用其它命令
有时候，你的命令需要自动执行AutoCAD原生命令，比如画一条直线或缩放视图。最简单的方式是给文档发送命令行字符串：
Document doc = Application.DocumentManager.MdiActiveDocument; doc.SendStringToExecute("ZOOM\nE\n", true, false, false);但注意，SendStringToExecute是异步的，调用后命令不会立刻执行，而是等当前命令结束后进入命令行队列。如果你的后续逻辑依赖这条命令执行完的结果，那就不能用这个方式，而应该在代码里直接用相关API，或者通过Editor.Command方法同步执行。
如果你的.NET命令想调用另一个.NET命令，也可以直接用ed.Command("MY_OTHER_CMD")。这种方式对于拆分复杂命令非常有用：你可以在一个总命令里依次调用几个子命令，每个子命令负责一个独立环节，职责清晰。
5.2 LISP中调用.NET命令与命令行转义
很多老项目是LISP为主，.NET插件作为补充。这种情况下，LISP里用最常见的方式调用.NET命令即可：
(command "MY_CIRCSTATS") (vl-cmdf "MY_CIRCSTATS")这里有个细节：如果.NET命令注册了本地化中文名称，LISP脚本里最好统一使用全局英文命令名。原因还是那句话，全局名跨语言版本稳定。另一个细节是，LISP里调用命令名时，字符串内不要带多余空格，否则AutoCAD可能把空格当成命令输入结束，导致命令解析异常。
如果要把参数传给.NET命令，常用的做法不是给CommandMethod方法加参数，而是让.NET命令内部通过ed.GetString或ed.GetDouble向命令行读取参数，LISP端在命令名后追加参数文本。这其实是AutoCAD命令系统的通用交互方式，和命令具体实现无关。
5.3 CommandFlags.Session与无文档环境的处理
有些命令不依赖任何打开的图纸，比如“读取配置文件”、“弹出一个启动面板”。这种命令标记为CommandFlags.Session后，即使在AutoCAD启动完成、尚未打开图纸的状态下，也能通过命令行或启动宏触发。
使用Session标志时，代码里不能再假设Application.DocumentManager.MdiActiveDocument一定存在。我实际写过一个环境检测命令，一开始没注意，在没有任何文档时直接访问MdiActiveDocument，结果抛了空引用异常。所以Session命令里的第一步应该是判断当前文档是否为null：
[CommandMethod("MY_ENVCHECK", CommandFlags.Session)] public static void EnvCheck() { Document doc = Application.DocumentManager.MdiActiveDocument; if (doc == null) { // 无文档状态下的处理逻辑 } else { // 有文档时的处理逻辑 } }Session命令还有一个特点：由于不锁定任何文档，它适合做一些轻量的初始化工作。如果你在Session命令里试图修改当前图纸数据库，多半会遇到问题，因为此时根本没有可用的活动文档上下文。
6. 常见问题与排查技巧实录
6.1 命令输入后提示“未知命令”
这是新手最常遇到的问题。命令明明写在代码里，编译也没报错，但NETLOAD加载后在命令行输入命令名，AutoCAD提示未知命令。排查思路其实很固定：
- 先确认DLL是否已加载，
NETLOAD成功后命令行会有提示，如果没提示说明加载失败； - 再确认方法是否是
public，CommandMethod特性是否真的贴在方法上； - 然后检查类是否公开，如果类是
internal，反射扫描时可能扫不到； - 最后确认命令名里没有非法字符、没有多余空格。
还有一个容易忽略的点是：如果Visual Studio生成时DLL被AutoCAD锁定，你重新编译可能会提示文件被占用，于是程序集还是旧的。这种问题建议把AutoCAD里的NETLOAD对应的DLL先卸载，或者直接关掉AutoCAD再编译。
另外，不要同时加载两个都定义了同名命令的插件。AutoCAD对重复命令名有时不报错，而是静默采用后加载者。这种问题特别难排查，我一般会在命令名里加项目前缀，从源头降低撞名概率。
6.2 中文版和英文版命令名不通用的根源
明明我在代码里注册了中文命令名，拿到英文版CAD上怎么就不能用了？这背后的原因并不神秘。AutoCAD的命令存储在命令表里时，主要识别全局命令名，本地化名称只是面向语言环境的一个翻译映射。中文命令名在中文版环境里能直接输入，但换到英文版，词表里没有这个本地化名称的位置，自然无法解析。
所以我也要再强调一次：如果你要交付给跨语言版本的客户，脚本、菜单、LISP调用中一律使用全局英文命令名。本地化中文名称可以保留，用于中文版用户聊天式的命令行输入体验，但不要把它当成程序间交互的约定。
如果你在中文版里输入英文全局名，理论上也能执行。比如注册了[CommandMethod("MY_HELLO", "你好CAD")]，在中文版里同时输入MY_HELLO或“你好CAD”都应该有效。如果只有英文名有效、中文名无效，那多半是本地化名称注册失败，可以检查SDK版本或尝试换一种构造函数写法。
6.3 命令运行到一半卡住或无法撤销
命令卡住，最常见的原因是事务未提交导致对象被锁，以及文档锁没有正确释放。如果命令在主线程里正常执行，一般不会卡住；但如果命令内启动了后台线程，并且后台线程试图操作当前数据库，就必须回到主线程通过Document.Invoke等方式执行，否则AutoCAD会直接爆出“调用被拒绝”或者干脆卡死。
撤销方面，AutoCAD默认对.NET命令提供撤销支持，只要你在事务里的修改是标准的数据库写入操作，就可以通过UNDO一次撤销。但如果你在命令里用SendStringToExecute调用了其他原生命令，撤销栈可能被这些内嵌命令打乱，导致一次撤销会分很多步。要解决这个问题，可以在命令开始时用doc.Editor.Command("UNDO", "BE")标记撤销组起点，结束前用UNDO的E选项标记终点，把整个命令作为一个撤销单元。这个技巧在老项目里非常实用。
6.4 异常处理：让崩溃变成可控提示
CommandMethod方法里抛出的异常，AutoCAD通常会在命令行显示一段红色的错误信息，然后继续运行。如果是未处理的异常，还可能导致当前命令被强制中止，但数据库状态是否安全就要看事务了。
我个人的做法是：每个命令方法的最外层都包一个try-catch，在catch里用ed.WriteMessage输出友好的错误提示，并且记录日志。注意，大型处理里不要用空的catch吞掉所有异常，至少要Debug.WriteLine记录现场信息，方便复现时排查。
try { // 命令核心逻辑 } catch (System.Exception ex) { ed.WriteMessage("\n命令执行出错: {0}", ex.Message); // 输出更详细的现场信息到日志文件 }有一点要特别说明：如果你在事务里开了写事务，并且中途抛了异常，一定要确保事务被Dispose。用using包裹事务就能保证这一点。否则异常的修改可能残留在内存事务里，状态非常诡异。
6.5 常见问题速查表
| 现象 | 主要原因 | 处理思路 |
|---|---|---|
| 输入命令显示未知命令 | 程序集未加载、方法非public、命令名非法 | 检查NETLOAD结果和命令名，确认类与方法的访问级别 |
| 命令只在中文版可用 | 用了本地化命令名作为唯一入口 | 脚本和菜单统一使用全局英文名 |
| 命令执行后图纸没变化 | 忘记调用tr.Commit()，事务被回滚 | 在正常分支末尾调用tr.Commit() |
| 命令执行时CAD卡死 | 事务悬空、文档锁未释放、后台线程操作数据库 | 避免交互期间持有写事务，跨线程操作使用Document.Invoke |
| 一次撤销多步 | 命令内部调用了多个内嵌命令，撤销栈被打乱 | 使用UNDO BE和UNDO E合并撤销组 |
| 加载时崩溃 | 程序集版本和CAD内置DLL版本不匹配 | 确认目标框架与引用的acdbmgd.dll版本一致，NuGet包版本对齐 |
| 命令无法在块编辑器里使用 | 未加NoBlockEditor但命令本身不适合块编辑 | 明确需求后加上CommandFlags.NoBlockEditor限制 |
7. 一些实战心得和补充建议
写到这里，如果你是从头看到尾，应该已经对CommandMethod有了一个比较完整的认识。最后再说几个我在真实项目里沉淀下来的小经验，不一定写在官方文档里，但都很实用。
第一，强烈建议把所有命令名统一定义到一个常量类里，不要在方法特性里直接手写魔法字符串。比如：
public static class CommandNames { public const string CircleStats = "MY_CIRCSTATS"; public const string LineLength = "MY_LINELEN"; }这样无论是菜单、LISP脚本还是代码内部调用，都引用同一个常量，减少拼写错误和改名遗漏。
第二，命令命名要有统一规范。我自己的规范是“项目缩写_功能名”，比如MY_CIRCSTATS，全部大写，下划线分隔。这个规范一旦定了，就不要随意改，因为菜单、脚本、代码很多地方都引用命令名，牵一发而动全身。
第三，无论命令简单还是复杂，尽量在一开始就写好命令类的注释模板，说明这个命令的用途、依赖环境、是否透明、是否需要当前文档、支持哪些标志。等到项目交接的时候，这份注释就是最好的文档。
第四，不要害怕把复杂的命令拆成多个小的CommandMethod方法。一个命令只干一件事，命令行提示清晰，调试和排查问题都会轻松很多。反而一个巨型命令内部塞满各种分支，后期改一行代码都提心吊胆。
CommandMethod这个特性，说到底只是AutoCAD .NET二次开发的入口。真正决定项目质量的，是你对事务模型、文档环境、交互流程和异常处理的理解深度。希望这篇文章能帮你在入口处少踩几个坑，把更多的精力放到业务逻辑本身去。
