简介：这是一份面向 SolidWorks 二次开发入门与进阶者的参数化建模实战工程包，重点解决在 VC++ 环境下调用 SolidWorks API、组织零件与对话框模块并生成可注册插件等问题。压缩包共 95 个文件，约 4.33MB，包含 16 个 .h、13 个 .cpp 及 3 个 .c 源码，另有 dll、tlb、idl、rgs、def 等 COM 组件与注册脚本，bmp 位图资源，以及 dsp/dsw 等 VC6 工程文件和若干编译中间文件，便于还原项目结构、对照接口声明与调试构建流程。已有 624 人学习下载，适合具备 C++ 基础、希望理解 SolidWorks 参数化建模实现思路与插件开发框架的读者参考。包内工程涉及零件、属性页、对话框、工具条等模块，并带有 SolidWorks API 类型库头文件与资源注册配置，可用于梳理二次开发项目的组织方式、类型库引用和资源加载关系，也能帮助读者对照源码理解参数驱动模型、界面交互与插件注册的实现脉络，从中提炼 API 调用和工程配置经验。
1. 从「改一个尺寸」到参数化建模：SolidWorks 二次开发到底替你干了什么
改一个孔距，草图、拉伸、阵列、工程图标注、装配体配合全得跟着动一遍；改完忘了重建，第二天打开发现工程图还是旧的。这类活在 SolidWorks 里重复三年，就该交给代码了。SolidWorks 二次开发本质上是在调用它的 COM API，把「点鼠标」换成「传参数」；而参数化建模是其中最值钱的一块：尺寸、方程式、配置、自定义属性全部变成外部可写的变量，模型按参数表自己长成需要的样子。这份资源面向的是已经会用 SolidWorks 建模、但没碰过 API 的人，包含一套能跑通的最小源码骨架、一批可直接改的参数化脚本，以及只有真跑过批量任务才会遇到的那些坑。
2. 先让 API 连上：三种入口与一条最小闭环
在讨论架构之前，先让一行代码真的改掉一个尺寸。这一步跑不通，后面所有选型都是纸上谈兵。下面这套东西不依赖任何第三方封装，全部走原生 COM 接口，好处是版本兼容性最好，坏处是每一处释放都得自己管。
2.1 宏、独立 EXE、Add-in：按「谁触发」来选，不按「谁高级」选
新手最容易犯的错是先纠结语言，C# 还是 VB.NET，WinForm 还是 WPF。其实第一刀应该切在触发方式上，因为它决定了后面所有的工程结构。
| 入口 | 触发方式 | 适合的场景 | 明显短板 |
|---|---|---|---|
| VBA 宏（.swp） | 人在软件里点一下 | 一次性批量改尺寸、验证思路、写个临时工具 | 没有版本管理，参数只能改代码 |
| 独立 EXE（控制台或 WinForm） | 计划任务、外部系统调用 | 夜间批量出图、和物料系统对接 | 自己管进程、管释放、管异常 |
| Add-in 插件 | 常驻菜单和工具栏 | 团队日常高频操作、给不会写代码的同事用 | 注册、升级、多版本并存都更麻烦 |
我一般的顺序是：先用宏把业务流程跑通，把每一步对应的 API 调用记下来，再把宏里的代码一行行搬到独立工程里。宏录制器会老实记录你做的每一个动作，包括那些你以为是「界面刷新」其实没必要的调用，正好当作 API 词典用。但要注意，录制出来的代码里大量使用Part.Extension.SelectByID2这种按名字选中的写法，一旦模型改名就全废，搬到正式工程时得换成按特征或按尺寸名定位。
Add-in 的门槛不在写代码，而在部署：它需要在注册表里登记自己的标识和加载行为，客户机上一旦有多个版本共存，很容易出现「菜单出来了但按钮没反应」。如果只是内部几个人用，独立 EXE 配上快捷方式，性价比高得多。
2.2 最小闭环：打开 → 改尺寸 → 重建 → 存盘
C# 控制台工程，引用两个互操作程序集（SolidWorks.Interop.sldworks.dll和SolidWorks.Interop.swconst.dll，就在安装目录下）。这四个动作串起来，就是后面所有自动化任务的原子操作。
// 引用：SolidWorks.Interop.sldworks.dll / SolidWorks.Interop.swconst.dll using SolidWorks.Interop.sldworks; using SolidWorks.Interop.swconst; using System; class Program { static void Main() { // 启动一个实例；如果已经有实例在跑，这里会接管它 SldWorks swApp = new SldWorks(); swApp.Visible = true; // 告诉宿主"有外部程序在驱动"，能明显减少界面刷新带来的开销 swApp.CommandInProgress = true; int err = 0, warn = 0; string path = @"D:\demo\bracket.SLDPRT"; ModelDoc2 swModel = swApp.OpenDoc6( path, (int)swDocumentTypes_e.swDocPART, // 文档类型：零件 (int)swOpenDocOptions_e.swOpenDocOptions_Silent, // 静默打开，不弹轻化提示 "", // 指定配置，空表示当前配置 ref err, ref warn); if (swModel == null) { Console.WriteLine($"打开失败 err={err} warn={warn}"); return; } // 尺寸全名 = 尺寸名@所属草图或特征名 Dimension dim = (Dimension)swModel.Parameter("D1@Sketch1"); if (dim != null) { dim.SystemValue = 0.035; // 单位是米，不是毫米 } swModel.EditRebuild3(); // 重建，返回 false 表示有特征失败 swModel.Save3((int)swSaveAsOptions_e.swSaveAsOptions_Silent, ref err, ref warn); swApp.CloseDoc(path); swApp.CommandInProgress = false; } }几个参数值得单独说清楚。OpenDoc6的第三个参数是打开选项，静默模式和轻化模式会直接改变你后面读到的模型状态，批量任务里建议显式打开轻化，处理前再按需还原，否则大型装配体打开一次要几十秒。err和warn是 out 参数，很多人图省事传两个局部变量进去就不看了，实际上打开失败、存盘失败的原因全在这两个码里。
EditRebuild3的返回值必须看。它返回 false 不代表抛异常，模型会保持在一个「改了一半」的状态继续往下跑，后面存盘存进去的就是脏数据。参数化建模最怕的不是报错，是静默地存了一个错的版本。
Save3的选项位是可组合的，静默保存只是其中一个；如果目标文件被占用或只读，它同样会返回 false 而不是抛异常。
2.3 单位与坐标系：API 里没有「毫米」这回事
这一条不吃透，参数化建模基本没法做。界面上你填 35，模型里存的是 0.035。
| 量 | 界面单位 | API 单位 | 换算 |
|---|---|---|---|
| 长度、尺寸、坐标 | mm | m | 除以 1000 |
| 角度 | 度 | rad | 乘以 π/180 |
| 质量 | g 或 kg | kg | 看文档单位设置 |
| 工程图视图位置 | mm | m | 图纸左下角为原点 |
写参数表的时候，我习惯让业务侧继续填毫米，进代码的第一件事统一除以 1000，绝不在中间过程来回换。曾经有个项目因为一处漏了换算，模型整体放大一千倍，装配体直接爆内存。
坐标系也要留意：工程图里插入视图的坐标是相对图纸左下角的，而且 Y 轴向上；零件草图里的坐标是相对草图原点的。同一个0.15，在两个上下文里含义完全不同。
2.4 COM 释放：别让进程在后台越堆越多
.NET 调用 COM 走的是运行时可调用包装，垃圾回收器并不知道那些非托管对象有多贵。一个循环里打开两百个零件不释放，内存会一路涨到进程被杀。
SldWorks swApp = null; ModelDoc2 swModel = null; try { swApp = (SldWorks)Activator.CreateInstance(Type.GetTypeFromProgID("SldWorks.Application")); swApp.Visible = false; int err = 0, warn = 0; swModel = swApp.OpenDoc6(@"D:\demo\a.SLDPRT", (int)swDocumentTypes_e.swDocPART, 1, "", ref err, ref warn); // ...业务处理 } finally { // 顺序很重要：先放文档，再放应用对象 if (swModel != null) System.Runtime.InteropServices.Marshal.ReleaseComObject(swModel); if (swApp != null) System.Runtime.InteropServices.Marshal.ReleaseComObject(swApp); }用Activator.CreateInstance加 ProgID 属于迟绑定，好处是不用引具体版本的互操作库，坏处是所有调用都靠字符串，编译期查不出错。团队内部工具我倾向早绑定，能拿到智能提示和编译检查；对外分发给不同版本的客户机时，迟绑定反而更稳。
还有一个隐蔽的点：SolidWorks 的集合很多是 1 基索引，而且用foreach遍历时产生的枚举器对象往往不会被释放。遍历特征树、遍历配置这类操作，老老实实写for循环配GetNextFeature()，比foreach稳。
3. 参数化建模的骨架：把「能改」变成「可控地改」
能改一个尺寸只是起点。真正的参数化建模要解决的是：参数从哪来、改哪些、改完怎么验证、失败了怎么退回去。这一章讲的是骨架，代码量不大，但决定了这套东西三个月后还能不能维护。
3.1 先改命名：D1@草图1这种地址没法维护
API 定位尺寸靠的是全名，格式是「尺寸名@所属草图或特征名」。默认命名是D1@Sketch1，只要有人在界面上重画一次草图，编号就可能变。所以在动手写代码之前，我会先在模型里把关键尺寸和草图重命名成有语义的名字。
| 类型 | 默认名 | 建议改成 | 原因 |
|---|---|---|---|
| 草图 | Sketch1 | SK_底板轮廓 | 重画后编号会漂移 |
| 尺寸 | D1@Sketch1 | D_孔距@SK_底板轮廓 | 一眼看出业务含义 |
| 全局变量 | 无 | L_总长 / W_板宽 | 方程式和外部参数都引用它 |
| 配置 | 默认 | STD / L1200 | 和参数表里的行一一对应 |
改完名字，代码里就不再出现D1这种神秘编号。为了让改名的活儿能批量做，可以写个自检脚本把当前模型里所有尺寸的全名和值打出来，当作参数表的第一版草稿。
// 遍历特征，打印所有可命名的尺寸全名与当前值，用于生成参数表 Feature feat = (Feature)swModel.FirstFeature(); while (feat != null) { DisplayDimension dispDim = (DisplayDimension)feat.GetFirstDisplayDimension(); while (dispDim != null) { Dimension d = dispDim.GetDimension2(0); // 0 表示取当前配置下的值 Console.WriteLine($"{d.FullName}\t{d.SystemValue * 1000:F3}"); dispDim = (DisplayDimension)feat.GetNextDisplayDimension(dispDim); } feat = (Feature)feat.GetNextFeature(); }GetDimension2(0)里的参数是配置索引，传 0 取当前激活配置。如果你有多配置，这里传错就会拿到别的配置的值，是排查「明明改了却没生效」的高频原因。
3.2 方程式与全局变量：先算完再写，别一边写一边算
模型内部有依赖关系时，用方程式比在代码里手算靠谱。总长变了，板宽自动跟着变，这种关系应该固化在模型里，而不是散落在脚本中。
EquationMgr eqMgr = swModel.GetEquationMgr(); // 找已有的全局变量行，找不到再追加 int idx = -1; for (int i = 0; i < eqMgr.GetCount; i++) { if (eqMgr.Equation[i].Contains("\"L_总长\"")) { idx = i; break; } } if (idx >= 0) { eqMgr.Equation[idx] = "\"L_总长\" = 1200"; // 单位跟随文档单位 } else { eqMgr.Add(-1, "\"L_总长\" = 1200", true); // -1 表示追加到末尾 } swModel.EditRebuild3();Add的第三个参数表示是否立即求解，批量写入时可以先全部设 false，最后统一重建一次，性能差别在小模型上看不出来，上百个尺寸时很明显。索引 -1 是追加，指定索引是插入，插入会顺移后面所有行，如果你按索引缓存过位置，插入之后缓存就全错了。
方程式的字符串必须严格符合语法：全局变量带引号，等号两边有空格，函数名区分大小写。写错了不会抛异常，只会让整行变成无效，重建后模型回到未求解状态。
3.3 配置派生：一份骨架模型长出一整族零件
同一系列不同规格，正确做法是一个模型多个配置，而不是复制一堆文件。配置之间只差几个尺寸值，维护成本天差地别。
// 建配置：名称、备注、备用名、选项、父配置、描述、是否立即重建 Configuration cfg = swModel.AddConfiguration2( "L1200", "", "", (int)swConfigurationOptions2_e.swConfigOption_None, "默认", "总长 1200 规格", true); swModel.ShowConfiguration2("L1200"); // 激活该配置 Dimension d = (Dimension)swModel.Parameter("D_总长@SK_底板轮廓"); if (d != null) d.SystemValue = 1.200; // 米 swModel.EditRebuild3(); // 需要单独出图时再另存为独立文件 int err = 0, warn = 0; swModel.SaveAs3(@"D:\out\bracket_L1200.SLDPRT", 0, (int)swSaveAsOptions_e.swSaveAsOptions_Silent);AddConfiguration2的父配置参数决定继承关系，传空字符串就是从默认配置继承。选项里可以控制是否隐藏、是否派生自父配置；如果配置要被外部系统引用，建议关掉「派生」，让每个配置都是完整的独立定义，避免改父配置时整族一起变。
SaveAs3在不同版本上签名会有细微差别，多一两个 out 参数很常见，编译报错时按提示补上err/warn就能过。存盘前记得确认目标目录存在，API 不会帮你建目录。
配置级和文件级的自定义属性是两套东西。配置级属性写在不同配置上，做明细表时能区分规格；文件级属性全局唯一。写属性时如果不指定配置名，写进去的是当前激活配置的属性，跑批量任务时这个「当前激活」很容易和你以为的不一样。
3.4 参数源用 CSV：读取、校验、失败就回滚
参数表放在外部，业务侧改一行就生成一个规格，这才叫参数化建模闭环。格式用 CSV 最省事，不用装任何东西，也不涉及任何互操作组件。
foreach (string line in File.ReadLines(@"D:\param\spec.csv").Skip(1)) // 跳过表头 { string[] cols = line.Split(','); if (cols.Length < 3) { Log($"列数不足，跳过：{line}"); continue; } string config = cols[0].Trim(); if (!double.TryParse(cols[1], NumberStyles.Float, CultureInfo.InvariantCulture, out double lenMm)) { Log($"长度不是数字，跳过：{line}"); // 宁可跳过，也不要猜 continue; } if (lenMm < 100 || lenMm > 3000) { Log($"长度超范围，跳过：{config} = {lenMm}"); continue; } // 换算成米后再写进模型 ApplyToModel(swModel, config, lenMm / 1000.0); }CultureInfo.InvariantCulture这行不是可选项。某些区域设置下小数点是逗号，double.Parse会把1.5解析成 15，而且不报错。这个坑我在两个项目上各踩过一次。
校验逻辑要前置到写模型之前。范围、空值、重复配置名，全部在内存里判掉，别指望 SolidWorks 帮你兜底，它对非法参数的反应通常是「不生效」，而不是「报错」。
回滚策略按成本从低到高：跑之前把源文件复制一份到备份目录；单文件失败就跳过并记录，不要整个批次中断；批次结束再统一报告哪些行没成功。
4. 出图与交付：工程图自动化最容易翻车的三处
模型改完只是半成品，交付物是图纸和明细表。工程图这块的 API 比零件复杂得多，因为多了「版面」这个二维概念，位置、比例、模板、图纸格式全都互相牵连。
4.1 模板与图纸格式：路径、单位、比例都固化在模板里
新建工程图的第一件事是选模板，模板决定了图框、标题栏、单位和默认比例。模板路径必须是绝对路径，而且不能指望 API 帮你找默认位置。
| 文件类型 | 扩展名 | 作用 | 注意 |
|---|---|---|---|
| 工程图模板 | .drwdot | 图纸大小、标题栏、图层、单位 | 单位设错，整张图尺寸全错 |
| 图纸格式 | .slddrt | 图框和标题栏的图形本身 | 可以后期替换，模板也可以 |
| 零件模板 | .prtdot | 默认单位和材料 | 批量建模时统一从这里起 |
| 明细表模板 | .sldbomtbt | BOM 表列定义 | 列顺序改一次，解析代码就得改 |
内部的模板目录我一般固定放在共享盘上，代码里读配置而不是硬编码路径。硬编码路径的程序，换台机器就得重新编译，是最没必要的维护成本。
// 第二个参数是图纸大小枚举，后两个是自定义宽高（用标准图幅时传 0） ModelDoc2 swDraw = swApp.NewDocument( @"\\share\templates\A1.drwdot", (int)swDwgPaperSizes_e.swDwgPaperA1size, 0, 0); if (swDraw == null) { Log("模板打不开，检查路径和权限"); return; }模板打不开时NewDocument返回 null，原因通常是路径错、被占用、或模板本身是更高版本存的。这种情况不会抛异常，只会静默失败，日志里必须记下来。
4.2 视图插入：坐标原点是图纸左下角
插入视图的坐标单位是米，原点在图纸左下角，Y 轴向上。这三个事实凑一起，第一次写的人基本都要调半天。
DrawingDoc drw = (DrawingDoc)swDraw; // 模型路径、视图方向、X、Y、Z（Z 一般为 0） View front = (View)drw.CreateDrawViewFromModelView3( @"D:\demo\bracket.SLDPRT", "*Front", 0.15, 0.20, 0); if (front == null) { Log("视图创建失败，方向名可能不对"); return; } front.UseSheetScale = 0; // 0：不使用图纸比例 front.ScaleRatio = new double[] { 1, 2 }; // 1:2 front.Position = new double[] { 0.15, 0.20, 0 }; // 微调位置方向名用的是视图定向的名称，*Front、*Isometric这类带星号的是标准视图，自定义视图名不带星号。名字写错不会报错，返回 null 而已，所以每一步都要判空。
UseSheetScale设成 0 之后，视图才受自身比例控制；不设的话，你改ScaleRatio完全没效果，这是最典型的「代码跑了但没变化」。
视图之间会互相避让，你设了位置它也可能被自动挪开。批量出图时我一般先插入全部视图，再统一设一次位置，最后才标注。
4.3 明细表与自定义属性：先写属性，再插 BOM
明细表读的是模型的自定义属性，属性没写对，表里就是空的。顺序必须是先写属性、再插表，反过来就得手动更新。
// 1. 写自定义属性（文件级，配置名传空字符串表示作用于所有配置） CustomPropertyManager cpm = swModel.Extension.CustomPropertyManager(""); cpm.Add3("物料编码", (int)swCustomInfoType_e.swCustomInfoText, "BR-001", (int)swCustomPropertyAddOption_e.swCustomPropertyReplaceValue); cpm.Add3("规格", (int)swCustomInfoType_e.swCustomInfoText, "L1200", (int)swCustomPropertyAddOption_e.swCustomPropertyReplaceValue); // 2. 在图纸上插明细表，锚点、坐标、模板、配置、BOM 类型按帮助里的顺序填 BomTable bom = (BomTable)front.InsertBomTable4( true, 0.02, 0.28, (int)swBOMConfigurationAnchorType_e.swBOMConfigurationAnchor_BottomLeft, @"\\share\templates\bom.sldbomtbt", "默认", (int)swBomType_e.swBomType_TopLevelOnly, 0); // 3. 读单元格回填校验 if (bom != null) { for (int r = 0; r < bom.GetRowCount(); r++) { string code = bom.Text[r, 0]; if (string.IsNullOrWhiteSpace(code)) Log($"第 {r} 行物料编码为空"); } }InsertBomTable4的签名很长，不同版本参数个数还会变，写之前先在本机 API 帮助里对着看一下，别照抄。锚点类型决定表格从哪个角开始长，坐标是锚点位置，两者配合不好表就跑到图框外面去了。
读单元格用Text[行, 列]，行列都从 0 开始。表格的行数和「有多少零件」不是一回事，明细表可能有标题行、合计行，解析时要按模板的固定结构来偏移。
最后再强调一次属性作用域：配置级属性和文件级属性是两个独立的存储，明细表默认读的是配置级。只写了文件级属性却发现表里空的，多半就是这个原因。
5. 避坑与排查：五个让我反复返工的问题
下面这几条都是实际跑批量任务时撞出来的，不是什么理论风险。每条按现象、原因、解决写，遇到同类症状可以直接对号入座。
5.1Parameter返回 null：名字对了，配置没对
现象：脚本里swModel.Parameter("D_孔距@SK_底板轮廓")一直返回 null，但打开模型手动找，这个名字明明存在。
原因：尺寸全名是「配置相关」的。同一个尺寸在不同配置下可能有不同的名字，或者当前激活的配置里根本不存在这个尺寸。另一种情况是模型里存在同名但属于不同草图的两个尺寸，全名在界面上看起来一样。
解决：先用第 3.1 节的遍历脚本把当前激活配置下的所有全名打出来，和代码里的字符串逐字比对，注意空格和全角半角。确认名字无误后，再检查ShowConfiguration2是否切到了目标配置。定位问题时加一句日志把swModel.ConfigurationManager.ActiveConfiguration.Name记下来，比盯着代码猜快得多。
5.2 尺寸改了模型没变：重建被跳过
现象：SystemValue赋了值，日志里也没报错，但存盘后的模型尺寸还是旧的。
原因：三种可能。一是没调EditRebuild3，或者调了但返回值被忽略；二是文档处于轻化状态，特征数据没真正加载；三是上级装配把该零件设成了压缩状态，改值本身生效了，但装配里看不到。
解决：赋值之后强制EditRebuild3()并检查返回值；打开文档时明确指定是否轻化，处理前用还原接口把轻化解除；装配场景先确认组件的压缩状态，再谈尺寸。
bool ok = swModel.EditRebuild3(); if (!ok) { // 重建失败通常是上游草图约束冲突，先把错误信息捞出来 Log($"重建失败：{swModel.Extension.GetWhatsWrongCount()} 处问题"); }5.3 批量跑到第 N 个文件崩：文档没关，对象没放
现象：循环处理几十个文件时，前期一切正常，某一次开始内存飙升，最后抛出「内存不足」或者进程直接消失。
原因：OpenDoc6打开一个就常驻一个，ReleaseComObject只是减引用计数，文档本身还在宿主里。累积到几百个之后，宿主自己就撑不住了。
解决：每个文件处理完显式CloseDoc，并把ModelDoc2释放掉。别依赖垃圾回收，它的节奏你控制不了。另外用try/finally保证异常路径也能走到关闭逻辑，否则一个坏文件就能让后面全部卡住。
5.4 弹出对话框，脚本卡死
现象：无人值守跑了一夜，早上发现进度条停在第 17 个文件，屏幕上挂着一个「是否重建」的确认框。
原因：某些操作在特定条件下会触发模态窗口，比如文件被占用时的另存为、引用丢失时的查找、单位不一致时的提示。脚本在等你点按钮。
解决：打开和保存都显式带静默选项；关闭「保存时提示」这类用户偏好；更彻底的办法是跑之前用文件副本，避免目标被占用。如果业务允许，可以在关键步骤前加一个文件存在性检查，把问题挡在弹窗之前。
5.5 出图越来越慢：每次都重新开模板
现象：第一批 20 张图纸用了 2 分钟，第二批用了 6 分钟，越往后越慢。
原因：每张图都NewDocument一次模板，模板里的图框、图层、字体每次都要重新加载；加上旧图纸没关，内存里堆着一堆打开的文档。
解决：单张出完立刻关闭释放；能复用的场景改成「打开一张已有图纸，删视图重插」，省掉模板初始化；文件名冲突检查放到循环外，一次性算出所有目标路径。经验上这几条改完，批量出图的总耗时能压掉一半以上。
6. 把脚本变成工具链：三个我必加的自检
脚本能跑通和能交付是两码事。中间差的是三样东西：干跑、快照、日志。
第一是干跑。正式写模型之前，先用同一份参数表跑一遍纯校验：列数够不够、数字能不能解析、范围合不合理、配置名有没有重复。这一步不碰任何模型，纯粹在内存里做，失败就直接退出，一个文件都不动。我现在的习惯是参数表先过一次校验脚本，攒下来的错误信息一次返回给填表的人，比自己一条条猜省事得多。
第二是快照。每个文件处理前复制一份到backup目录，文件名带上时间戳。这不算优雅，但它是唯一在改错参数、存错路径、覆盖了正确版本之后还能救回来的手段。成本是磁盘，收益是一晚上的返工。
第三是日志，而且要带上下文：文件名、配置名、改了哪个尺寸、改前改后、重建结果、耗时。光记「成功」「失败」没有意义，出问题时你需要的是能直接定位到某一行参数。
| 自检项 | 检查时机 | 失败后的动作 |
|---|---|---|
| 参数表校验 | 循环开始前，一次性 | 整批中止，返回错误清单 |
| 文件快照 | 每个文件处理前 | 复制失败则该文件跳过 |
| 逐文件日志 | 每一步关键操作后 | 记录并继续，末尾汇总 |
| 结果回读 | 存盘后重新打开读一次值 | 与期望不符则标记异常 |
第四项是最容易被省掉的：存盘之后重新打开，把关键尺寸读回来和期望值比对。多花的时间大约是总耗时的两成，但能挡住「明明改了却没生效」这一类最恶心的问题——它们不会报错，只会在装配现场暴露。
有一个细节我一直保留：所有写模型的操作都放在一个统一的ApplyToModel方法里，任何直接改尺寸的代码都不允许出现在这个函数外面。这个约束看起来有点教条，但它保证了每一处修改都能被日志和回读覆盖到。早些年我在一个循环里图快，直接写了一行赋值，结果那一路的日志和校验全绕过去了，出了问题查了整整两天。从那以后我每次新增一个改模型的入口，都强制走一遍校验、快照、回读这三步，宁可慢一点，也不留查不出来的黑匣子。希望帮到你。
本文还有配套的精品资源，点击获取
