WPF 组态软件踩坑记(四):数据流与工程化,四层联动的取舍

同一个值，四条路能改。

上篇结尾说，画布之外还有一类坑，跟渲染无关，纯粹是数据和状态：模型、ViewModel、属性面板、命令行四条路改同一个值，谁先谁后、谁覆盖谁。这篇把它们一次说清。

数据流的坑和前几篇都不一样。绑定是「不报错」，事件路由是「没反应」，渲染是「看着不对」，数据流是「改一处，崩三处」：你修好一条路，另一条路悄悄漏掉，等用户从那条路进来，问题才暴露。我们的组态软件里，每个控件属性的值都有好几条入口：属性面板、CLI 命令、AI 指令、撤销重做。它们共享同一个模型，却各有各的同步逻辑，坑就长在缝隙里。

坑一：加一个属性，要过四道门

给控件加属性（比如字体），最朴素的改法是：模型加字段，面板加输入框，绑定一下，完事。错。我们第一版就这么干的，结果 UI 里能改的字体，CLI 命令改不了，两边功能不对称，用户从命令行进来就懵了。

规则是：新增或删除一个模型属性，必须同步检查四个地方：

1. 模型：字段 + 序列化编号（编号递增，删除的属性留空洞、不复用，避免老工程反序列化错位）
2. VM：属性 + 转发 case 分支
3. 面板：编辑控件 + 绑定
4. CLI：set_property 分支

四条路里最容易漏的是 CLI。而且 CLI 在我们项目里还是两套：独立命令行程序和软件内置的控制台，共享同一个命令层，参数映射却各自实现。有次给事件命令加参数，独立命令行有完整映射，GUI 内置控制台走的是通用映射表，缺了 event 到 event_type 的映射，一执行直接抛 KeyNotFound 崩溃，同一命令在独立命令行里却跑得好好的。修复是给内置控制台补上显式分支，和独立命令行对齐。

比漏第四层更隐蔽的是反向同步：属性从面板改，走正向（面板→VM→模型）；从 CLI、AI、撤销改，走反向（模型→VM→面板回显）。我们新增列表控件属性时，正向四层全齐了，唯独漏了反向同步的 case，结果 CLI 改完属性，属性面板的下拉框纹丝不动，用户以为没生效。规则补一条：新增属性时检查三处：正向同步 case、反向同步 case、面板绑定。

坑二：钳制不能只看自己

属性面板里输入控件的坐标和尺寸，设计要求是「不能拖出画布」。实现时给 X 和 W 各自做了范围钳制：X 在 0 到画布宽之间，W 在 1 到画布宽之间。看起来没毛病，结果 X=100、W=100 的控件，把 W 改成 800，放行了，X+W=900，右边 100 像素跑到画布外。

根因是钳制只看单个属性，没看属性之间的联动。修复：

// X: 0 ≤ X ≤ 画布宽 - 控件宽value = Math.Max(0, Math.Min(value, CanvasWidth - _selectedWidget.Width));// W: 1 ≤ W ≤ 画布宽 - X（保证 X+W 不超画布）double maxW = Math.Max(1, CanvasWidth - _selectedWidget.X);value = Math.Max(1, Math.Min(value, maxW));

X 的上限要减去控件宽，W 的上限要减去当前 X。还有三个细节：钳制必须用模型里的当前值，不能用 VM 缓存的旧值；加 double.IsFinite(value) 拦截 NaN 和 Infinity（外部数据源可能送来非法值）；画布尺寸变化时要重新计算钳制上限，否则窗口改大改小后钳制范围还是老的。

坑三：输入框的确认时机，也是数据流设计

坐标输入框最初用 UpdateSourceTrigger=PropertyChanged，每次击键实时写模型、实时钳制。用户输 "-" 想输负数，字符还没输完就被钳制成 0；输超大值，中间态直接被压回上限。体验很差，而且这个「实时」本身没意义，没人需要每敲一个键就改一次模型。

修复是编辑型数值框改 LostFocus + Enter 确认：

private void PropNumberBox_KeyDown(object sender, KeyEventArgs e){    if (e.Key == Key.Enter)    {        (sender as FrameworkElement)?.MoveFocus(new TraversalRequest(FocusNavigationDirection.Next));        e.Handled = true;    }}

失焦或回车时才把值应用进模型，然后钳制，再把钳制结果回显到输入框；转换失败的非法输入保持旧值。这一条还牵扯出 DataGrid 里的同类时序坑：表格单元格绑定 LostFocus，CellEditEnding 事件却发生在绑定更新之前，事件里读到的还是旧值，校验时灵时不灵。修复是提交分支里先手动 UpdateSource() 再读；但 Esc 取消也会触发该事件，不能无条件更新，否则按 Esc 也被写回。DataGrid 提交后还会对同一绑定再更新一次，setter 如果不做同值短路，会推入一个多余的撤销快照，撤销按一下没反应、按两下才恢复。

坑四：脏标记，收口到模型层

文件修改检测（标题栏加星号、关闭时提醒未保存）只覆盖了拖拽、增删控件，属性面板改属性不标脏。用户改完坐标直接关软件，改动悄悄丢了，没有提醒。

修复是把脏标记收口到模型层统一订阅：当前画面的所有控件都订阅 PropertyChanged，集合变化也订阅，任何属性变化统一标脏。两个细节：瞬态属性（比如「是否选中」）要排除，不能点一下控件就标脏；自动属性不触发通知，直接写模型的路径必须走带通知的 setter，否则订阅失效，改了不标脏。这又是一条「改一处漏一处」的缝隙。

坑五：撤销路由，先问清语义

Ctrl+Z 应该撤销什么？我们的第一个版本是全窗口一条时间线，后来又试过「窗口级优先」，都不对。用户真正的语义是：撤销当前页面。切到用户管理页，Ctrl+Z 撤用户操作，不用先点表格；画面上的操作绝不撤用户；两套操作各自成栈，不合并。

这个需求第一次提的时候，我们直接按直觉做了统一时间线，被否；改成窗口级优先，又被否；最后问清楚是「页面级 + 分栈」才落地。教训是：撤销语义要先问「页面级 / 焦点级 / 时间线级」，别默认。后面世界地图、变量基准值也各自建了独立栈，撤销路由按激活域分派，跨域操作一次 Ctrl+Z 只能撤当前域。还有一个撤销相关的经典陷阱：setter 里推撤销快照如果不做同值短路，一次编辑会推两个快照，撤销就要按两下，这个在坑三里已经说过了。

坑六：0000 年不是合法日期

日期时间控件绑定一个 DATETIME 类型的变量，变量的「默认值」设计成全零：0000:00:00 00:00:00，意思是「还没设置」。这个值在 C# 里 DateTime.TryParse 直接失败，0000 年根本不存在。

最初全零值没有专门处理，控件格式一改，显示就停住，不再实时更新。修复是：解析失败时不做时间解析，直接按控件显示格式做字面替换生成全零字符串，年份补 0000、月份补 00，分隔符跟控件格式走；控件绑定了变量就显示变量的全零基准值，没绑定就实时显示当前时间。这样「未设置」状态在全项目里表现一致，也扛得住格式切换。这条的教训是：默认值要先问一句「它合法吗」，用一个解析器都过不去的值当默认值，等于在每个用到它的地方埋雷。

架构决策，让 bug 无处藏身

六个坑聊完，背后是同一条线：数据流的问题从来不是一个函数写错，而是多条路径没有对齐。沉淀的打法：

1. 加属性过四道门：模型、VM、面板、CLI 同步检查，正向同步和反向同步都要补 case。
2. 钳制看联动：一个属性的合法范围由别的属性决定时，钳制必须用模型现值联算，防 NaN 用 IsFinite。
3. 确认时机定数据流：编辑型输入框用 LostFocus + Enter 确认；事件里读绑定值前先确认绑定的提交时序。
4. 通知收口到模型层：脏标记、刷新统一订阅模型事件，直接写模型的路径必须走带通知的入口。
5. 撤销先问语义：页面级还是焦点级还是时间线级，问清楚再设计分栈和路由。
6. 默认值先问合法性：全零、极大值这类「边界默认值」，先验证解析器认不认。

有人说数据流的 bug 多打断点跟一遍不就定位了吗？断点能定位「哪一步写错了值」，但定位不了「还有哪条路漏了同步」。这类 bug 的特点是：修好一条路，另一条路在等下一次用户操作才暴露。所以排查的第一步不是找断点，是数清楚这个值有几条入口、每条入口的同步逻辑有没有对齐。

回想第三篇说的「别跟渲染管线的魔法搏斗」，数据流的版本是：别跟多入口的同步搏斗，让架构替你把每一层都对齐。四篇写完，从绑定、事件、渲染到数据流，其实都是同一件事：WPF 里的坑九成不报错，剩下的功夫全花在让系统的每一层都按同一条规则走。