兔子313做了几年工控上位机，踩过无数坑之后，我最大的一点体会是：仿真类工具的价值，不在于把界面做得有多炫，而在于它能不能在真实设备动作之前，把问题暴露出来。今天要聊的这个项目就是这么个方向 —— 基于 .NET 8 和 WPF 打造一套数控机床仿真平台。它解决的核心问题很朴素：在没有实际机床的情况下，完成 G代码校验、刀具路径预览、机床运动模拟和加工状态监控，让工艺人员能在电脑前提前确认程序是否安全、路径是否合理、参数是否合适。
这个平台对三类人特别有用。第一类是工控软件开发者，想了解用 .NET 8 + WPF 这类技术栈怎么做设备仿真和数字孪生；第二类是工艺工程师或数控编程人员，需要在离线环境下快速验证刀路；第三类是机械专业的教学场景，用软件模拟代替真实机床，节省成本也避免安全事故。我这次会把从架构设计、MVVM 落地、G代码解析、插补仿真，到 DataGrid 实战细节、LiveCharts2 图表联动、以及各种常见坑的排查过程完整拆开，把我实际开发中踩过的坑和解决思路都讲清楚，希望能给同样在做类似项目的人一些可抄作业的思路。
1. 为什么用 .NET 8 + WPF 做这套数控机床仿真平台
1.1 选型时我考虑过哪些方案
说实话，这套系统在动手之前，我也犹豫过到底用什么技术栈。市面上常见的方案无非三类：第一类是基于 Web 技术，比如 Three.js、Babylon.js 做浏览器端三维仿真，优点是部署方便、跨平台，但缺点是浏览器沙箱对串口通信、底层硬件访问、大文件本地解析这些工控场景不太友好；第二类是直接用 C++ 配合 OpenGL / VTK 这类重型渲染库，性能上限高，但开发效率低，团队培养成本高，中小项目根本玩不起；第三类就是 C# + WPF，Windows 生态下做桌面级工控软件的老牌组合。
我最后选择 .NET 8 + WPF，核心原因有三个。一是团队对 C# 技术栈更熟，代码维护成本可控；二是 WPF 的绑定、模板、样式体系对做复杂界面太友好了，数控仿真平台这种信息密度极高的应用，用 WinForms 写界面会崩溃到怀疑人生，用 WPF 的 MVVM 结构则可以把界面逻辑和数据逻辑彻底解耦；三是 .NET 8 是长期支持版本，对工控这种要求稳定性的场景，LTS 的意义是实打实的，你不想每两年被迫升一次级。
1.2 .NET 8 到底带来了什么红利
聊到 .NET 8，很多人的印象就是"性能又提高了",但对我们做仿真平台的人来说，真正有用的是几个具体的点。首先是自包含发布模式的成熟度，.NET 8 可以把整个运行时打包进 exe，目标机器不用装 .NET 环境也能跑，这在部署到客户车间那台常年不更新的工控机时太重要了。其次是新增的 System.Text.Json 源生成器，在做 G代码参数配置、加工数据集导入导出时，反序列化性能比反射模式提升明显，而且 AOT 友好，虽然 WPF 暂时不能 AOT，但底层库用源生成器也能减少启动时的 JIT 压力。
还有一个细节是 .NET 8 对 Linux 的支持进一步加强，虽然 WPF 本身是 Windows-only，但如果你把仿真引擎核心部分抽象成类库，后续将解析器和插补算法迁移到服务器端做批量仿真校验，这个路是通的。我实际测试过，在纯计算场景下，.NET 8 的 JIT 改进让 G代码解析性能和 .NET Framework 4.8 相比提升在 20% 左右，对大批量刀路文件预处理来说体感很明显。
1.3 为什么 WPF 在工控场景下仍是优选，而不是 WinForms
网上一搜"工控 WPF 为何替代不了 WinForm"，能看到一大堆讨论。我的观点比较直接：如果你的界面只是摆几个按钮、十几个文本框、几排指示灯，那 WinForms 和 WPF 没什么区别，WinForms 甚至更轻快；但如果你的界面有复杂的实时状态视图、坐标监控、参数表、刀路图形预览、报警信息聚合，那 WinForms 在布局美观度、数据绑定灵活性、UI 复杂度管理上确实力不从心。
WPF 真正碾压性的地方在于数据绑定和模板机制。比如我的坐标显示区域，需要跟随仿真位置每秒刷新几十次，WinForms 的做法是每个 Label 手动赋文本，或者用 BindingSource 做一层封装，控件一多就显得零散；WPF 里直接把坐标属性绑定到 TextBlock，借助 INotifyPropertyChanged 自动更新，代码量至少减少一半。另一个重要因素是样式和模板。WinForms 的控件外观是硬编码在系统绘制里的，深色主题做起来非常痛苦；而 WPF 的样式系统允许你把整站主题抽成 ResourceDictionary，皮肤切换就是换个资源字典的事。工控软件现在也越来越注重界面质感，一个操作台上摆着深色高对比的加工监控界面，和十个灰底白框窗体摞在一起，完全是两种体验。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数控机床仿真平台的架构设计与模块划分
2.1 核心需求拆解，别一上来就写代码
我做这个项目的第一步，是把所有需求写在白板上，然后一条条拆分。数控机床仿真平台的核心需求大致有六块：G代码程序解析、刀具路径与机床运动模拟、坐标状态实时监控、加工参数设置和管理、程序校验与报警提示、数据记录与回放。这几个需求彼此独立，但又有数据流联系。如果你一开始就把所有逻辑塞进 MainWindow.xaml.cs，那后面会陷入无尽的 bug 和混乱。
我采用的分层思路是：界面层（WPF + MVVM）-> 应用服务层（加工任务管理、仿真控制、数据服务）-> 领域核心层（G代码解析器、插补引擎、运动学模型、碰撞检测）-> 基础工具层（日志、配置文件、通用扩展方法）。领域核心层完全不引用任何 WPF 相关程序集，所有类型都是 POCO 或者纯算法类，这样不但方便单元测试，以后即便要把核心算法复用给 Web API 或者服务端批量校验，也毫无障碍。
2.2 整体模块结构：六个核心模块的设计思路
第一个模块是 G代码解析器。它的职责是把一行行 NC 程序拆成标准指令对象，比如 G00、G01、G02、G03、G04、M03、M05、S1500、F800 等，并且允许设置工件坐标系偏移。第二步是刀具路径生成器，基于解析结果逐行做几何计算，输出离散的刀位点序列。第三步是插补引擎，这是仿真的心脏，负责把刀具路径点按插补周期细分成运动步。第四步是机床运动学模型，针对三轴立式加工中心最常见，X/Y/Z 三轴直接做直线映射即可，但如果要做五轴机床，就需要做旋转轴变换和 RTCP 计算，我先从三轴做起保证落地。第五步是碰撞与行程检测，判断刀路是否超出行程或与夹具干涉。第六步是渲染展现层，在 Viewport3D 中实时更新机床模型位姿并绘制刀路轨迹。
有人会问，为什么非要把模块分得这么细？我用一个实例说明。假设客户要求增加"自动换刀时间模拟"功能，如果解析器、插补引擎和状态显示全部耦合在一起，你可能要改十几处代码；但按模块拆分后，只需要在解析器里增加换刀指令事件，在插补引擎里定义换刀状态，在界面层加一个动画提示即可，改动范围完全可控。
2.3 G代码解析的底层实现逻辑
G代码解析看着简单，实际坑不少。每一行 NC 代码可能是这样的："N10 G01 X100.5 Y-30.2 Z5.0 F800 M08"。你需要把行号、G指令、坐标字、进给速度、辅助功能全部拆开，并且要考虑老式程序里可能有的跳段符 "/"、注释括号、小数点省略（比如 X100 代表 X100.0 而不是 X0.1）。我实现的时候，用正则表达式按指令类型分词，然后逐个匹配到字典里。核心是不要解析成字符串堆，而是直接构建一个 Command 对象列表，后续插补引擎遍历这个列表。
还有一个容易被忽视的地方：模态指令。G01 一旦指定，后续行如果只写坐标不写 G01，默认还是执行直线插补。所以解析阶段必须维护一个模态状态机，记录当前 G 组状态、当前坐标系偏移、当前刀具长度补偿等。如果不处理模态指令，你解析出来一串断断续续的运动指令，仿真轨迹完全是错的。
2.4 插补引擎与运动学模型
插补是数控系统最核心的概念，仿真的插补和真实数控系统的插补目标是类似的：把一条直线或圆弧路径细分成很多微小线段，每个插补周期输出一个位置增量。仿真平台并不需要精确到微秒级的实时控制，但至少要做到按设定进给速度均匀推进，否则刀路预览的速度感是失真的。
我做的做法是建立一个仿真时钟，用一个定时器驱动，每 10 毫秒 tick 一次。每次 tick，根据当前进给速度 F（单位是 mm/min）和插补周期计算本次移动距离，然后把目标位置从当前点推进到下一位置。直线插补 G01 简单，直接线性映射；圆弧插补 G02/G03 需要先通过起点、终点和圆心计算圆弧角度范围，然后按角度增量做插补，最后再把 XY 平面上的结果映射到三轴坐标。三轴运动学模型最简单，就是直接把插补结果作为 X/Y/Z 轴坐标。如果以后扩展五轴，才需要在运动学里做矩阵变换和反向求解，这部分可以留作架构扩展点。
2.5 渲染展现层：WPF 3D 与刀路轨迹的可视化
WPF 的 Viewport3D 做机床仿真是够用的。我的做法是用一个 ModelVisual3D 作为场景根节点，把机床的床身、工作台、主轴头等部件用 BoxMesh、CylinderMesh 等基础几何体组合出来，或者加载第三方 3D 模型（通过 HelixToolkit 的 ObjReader 可以导入 OBJ 格式）。机床部件不是静态的，主轴头、工作台在仿真中需要移动，所以每个部件节点绑定位移变换，通过 MVVM 属性更新 Transform3D。
刀路轨迹线的显示同样重要。我维护一个 Point3DCollection，插补引擎每推进一个点就追加到集合中，然后用 ScreenSpaceLines3D 或者简单用 LineGeometry3D 绘制。注意一个坑：如果每帧都重建整个线段集合，UI 线程容易被拖垮。优化方案是分块追加，比如每 200 个点刷新一次，或者将轨迹渲染放到独立的 DrawingVisual 上，避免频繁构建 DependencyObject。实际做下来，几万行 G代码的刀路轨迹完全撑得住，视觉上也足够顺滑。
3. MVVM 落地与界面开发实战
3.1 项目骨架：Prism 还是纯 MVVM
这个项目要不要上 Prism，我评估过。如果只是单窗口小工具，用 CommunityToolkit.Mvvm 就够了，轻量、无侵入、源生成器让代码也很简洁。但数控仿真平台这种模块多、功能复杂的系统，我最终还是用了 Prism，原因在于它提供了现成的 Region 导航、模块化机制和 DialogService。例如我把"程序编辑""加工监控""轨迹回放"做成三个独立功能模块，通过导航方式切换，模块之间互不依赖，这比在 ViewModel 里堆各种状态标志位干净得多。
用 Prism 有一个上手门槛，但值得投入。你只需要定义一个 App 类继承 PrismApplication，在 RegisterTypes 里注册服务，在 CreateShell 里创建主窗体，然后各个 View 通过 RegionName 注册到主界面的区域即可。模块化带来的好处在后期维护时极其明显，新增加密授权功能时，我只需要加一个模块，不需要动主窗体的任何逻辑。
3.2 数据驱动界面的核心：INotifyPropertyChanged 与命令绑定
MVVM 的核心不是用了 Prism，而是真正理解数据流怎么走。我的 ViewModel 里几乎不写任何 UI 操作代码，所有界面状态都可以被测试。一个典型的例子是"开始仿真"按钮的可用性控制：只有加载了有效的 G代码文件且当前没有在仿真中，按钮才可点击。这个逻辑用属性 IsCanStart 表示，在加载文件和仿真状态变化时通过 SetProperty 触发 OnPropertyChanged，然后按钮的 Command 绑定 StartCommand，Command 内部判断并执行，界面更新完全由绑定系统自动完成。
在实际操作中，我最想提醒的一点是：属性通知不是越多越好，而是要在正确的位置触发。很多人把每一条坐标轴位置都做成独立属性，每个都触发通知，导致界面高频刷新卡顿。我的方案是把位置状态打包成一个 MachiningState 类，用一条属性承载所有变化，界面通过 OneWay 绑定读取子属性，只在关键节点（如每完成一个插补周期）触发一次通知，性能和效果都很好。
3.3 操作台界面：坐标面板、程序面板与状态栏布局
数控操作台的界面布局是有行业习惯的。我参考了常见数控系统的布局思路：左侧是程序编辑和文件树，中间是 3D 刀路预览和状态图形，右侧是坐标监控、主轴转速、进给倍率等实时数据，底部是报警信息列表和操作按钮。用 WPF 实现时，主 XAML 用 Grid 分列，中间区域放 Viewport3D，右侧坐标面板用 ItemsControl 绑定坐标集合，底部报警用 DataGrid 或 ListBox，整体是深色主题，用统一的资源字典定义背景色和前景色。
一个容易踩的坑是 DPI 缩放。工控机分辨率通常不高，但客户可能会把显示缩放调成 125% 或 150%，如果 WPF 程序没有做 PerMonitorV2 DPI 处理，界面模糊不说，布局也会被截断。解决方案是在 app.manifest 里声明 PerMonitorV2 支持，并设置相关的 DPI 值，另外尽量用 Grid 布局而不是固定 Pixel，这样不同分辨率下都能自适应。
3.4 DataGrid 实战：选中、复选框、按钮删除等常见需求
DataGrid 是 WPF 里最常用的表格控件，也是最让人头疼的控件之一。我在项目里主要用它展示 G代码列表、刀具参数表和报警记录。这里把几个最常见的需求和解决方案一次性讲透。
第一，DataGrid 的某一行复选框选中后点击按钮删除。这个需求要理解 DataGrid 的选中机制：通过设置 SelectionMode="Single" 和 IsSelected 绑定到行数据模型的属性，然后按钮的 CommandParameter 绑定 SelectedItem，在 ViewModel 里拿到选中项即可删除。如果你的需求是"行内复选框勾选后单独标记"，不要在 DataGridCheckBoxColumn 里直接绑定业务属性，而是新建一个包装属性 IsChecked，这样才能避免 UI 状态和业务数据混在一起。
第二，DataGrid 点击单元格时默认选中背景颜色不均匀。这个问题很常见，默认情况下点击单元格会高亮该单元格，而整行选中可能只有行头有颜色。解决方案是给 DataGridRow 设置 Style，通过触发器在 IsSelected 为 True 时统一设置背景色，同时设置 CellStyle 在选中时保持透明，把视觉焦点完全交给 Row。这样看起来才像正常的"整行选中"效果。
第三，DataGrid 内大量数据加载卡顿。如果加载几千行 G代码，每行又有多个列，默认的 DataGrid 会为每个单元格创建大量元素。建议启用虚拟化：设置 EnableRowVirtualization="True"、EnableColumnVirtualization="True"，并且不要让 DataGrid 放在 ScrollViewer 中，否则虚拟化会失效。还有一个技巧是关闭不必要的列自动生成，用固定列模板，减少运行时布局计算量。
3.5 界面细节：ComboBox 空白项、TextBlock 换行与大量 Button
在开发中，我遇到过几个看起来很不起眼但真实运行时会烦人的界面问题，一并记录下来。
ComboBox 下拉框末尾出现空白项。这个问题通常是因为绑定集合的元素被意外添加了一个 null 项，或者 ItemTemplate 的 DataTemplate 在绑定值为 null 时渲染成空白。排查思路很简单：在 ItemsSource 绑定前先打印集合长度和每一项的值，如果你用的是可观察集合，还要检查是否有异步添加数据时越界操作。另一个常见原因是 ComboBox 的 SelectedItem 绑定到一个不存在的值，下拉框会显示空白，此时要么把 SelectedItem 改为绑定到相同列表中的具体对象，要么设置 SelectedValuePath 和 DisplayMemberPath。
StackPanel 里的 TextBlock 需要自动换行。新手最容易踩的坑是给 StackPanel 设置宽度，但 TextBlock 默认 TextWrapping="NoWrap"，而且 StackPanel 对子元素的测量是无限宽度，TextBlock 就会一直向右延伸。正确的做法是给 TextBlock 设置 TextWrapping="Wrap"，并且给 StackPanel 设置 MaxWidth 或者改用 DockPanel/Grid 布局限定可用宽度，否则 Wrap 也不会起作用。
动态创建大量 Button。比如说机床软键盘或者 M 指令快捷按钮区，如果循环 new Button 再逐个设置事件，性能差且代码极难维护。推荐的方式是把按钮数据放到一个 ObservableCollection，用 ItemsControl + DataTemplate 批量渲染，每个按钮的文本、命令、参数都通过数据模板绑定。这样不但代码简洁，而且可以利用容器的虚拟化能力，实测创建几百个按钮也毫无压力。我在项目里实现了 M 指令快捷输入面板，就是基于这个方案，客户反馈交互流畅，后续加新指令只需要改数据源，不用改界面代码。
3.6 状态曲线与实时监控：LiveCharts2 使用心得
机床状态除了数字显示，曲线趋势图也很重要，比如主轴负载、进给速度、位置误差曲线。早期我用的是 LiveCharts（老版本），后来升级到 LiveCharts2。LiveCharts2 最大的变化是 API 更模块化、更符合 MVVM 流程，数据更新也更快。以位置曲线为例，我定义了一个 CartesianChart，Series 绑定到一个 ObservableCollection 的 LineSeries
实际用下来有一个坑：LiveCharts2 性能虽好，但如果每帧都更新所有点，UI 还是可能卡。我的处理方法是限制曲线的数据点窗口，比如只保留最近 500 个点，超出后移除最旧的点，这样既能看到实时趋势，又不会无限制增长。另外在后台线程刷新数据时，务必使用 Dispatcher.InvokeAsync 将集合更新切回 UI 线程或者使用 LiveCharts2 提供的 LiveObservablePoint 等支持自动跨线程通知的类型，否则跨线程异常会时不时跳出来。
4. 仿真核心难点与性能打磨
4.1 UI 不卡顿的线程模型设计
数控机床仿真是典型的需要后台计算、前台展示的场景。如果把插补计算直接放在 UI 线程，一两千行 G代码跑起来后，界面会僵住甚至无响应。我的方案是把仿真计算放到独立的 Task.Run 线程中，每完成一个插补周期，把最新状态发布到一个阻塞队列或者直接用 Channel
这里有一个很重要的设计思想：后台线程只负责产生数据，UI 线程只负责消费和显示，两边用 Channel 解耦，避免了锁竞争和跨线程异常。如果还想要暂停、继续、停止等控制，可以用 CancellationTokenSource 和 SemaphoreSlim 配合实现。这个模式我已经在多个工控项目中验证过，稳定性和清晰度都很好。
4.2 刀路轨迹渲染的性能优化
刀路轨迹几万甚至十几万个点，如果全部用一个 GeometryModel3D 渲染，刷新时会很吃力。我做了分块处理：按 G代码的程序段分段，每一段轨迹用一个独立的线几何体渲染，只有当前执行的段才高频更新。历史轨迹用一个静态 Geometry 绘制一次，不再变化；当前活动轨迹单独一个比较细的 MeshGeometry3D，每帧只更新这个 Mesh 的 Positions，效率会好很多。
还有一个我比较推荐的技巧：把轨迹线做成两层，一层粗线半透明表示包络范围，一层细线高亮表示精确路径。乍一听会增加渲染负载，但因为半透明层是静态的，不做高频更新，所以对性能影响很小，视觉上却非常直观，操作人员一眼就能看出刀路范围有没有超出夹具或毛坯面。
4.3 大量实时数据的 UI 刷新优化
坐标监控、主轴转速、进给速度这些数据，理论上每个插补周期都在变，但如果照单全收并立即刷新 UI，性能必然受影响。我在实践中总结出一套"节流 + 批量更新"的策略：后台计算产生的所有状态变化先放进一个状态缓冲区，UI 侧每 100 毫秒统一读取一次最新快照并更新界面。这样即使后台每 10 毫秒产生一条数据，界面刷新频率也只有 10 次/秒，肉眼完全足够平滑，CPU 占用率也大幅下降。
另外，字符串拼接是高频刷新场景的隐形杀手。每帧都做 string.Format 来显示坐标值，会产生大量临时字符串，触发 GC 压力。更好的做法是使用固定长度的字符数组或者复用 StringBuilder，我通常在数据模型里预留足够的字符空间，刷新时直接写入，避免分配。这个话题虽然很细，但在长时间运行的工控软件里，GC 导致的周期性卡顿就是这么一小点一小点积累出来的。
4.4 .NET 8 发布与部署的实战经验
仿真平台最终要部署到客户现场，我采用的是 .NET 8 自包含发布模式。命令很简单：dotnet publish -c Release -r win-x64 --self-contained true -p:PublishSingleFile=true，发布出来是一个大 exe，免安装，拷到目标机器直接跑。但有一个坑：PublishSingleFile 模式下，某些原生库（比如 SQLite）的加载路径会有问题，需要在代码里设置 NativeLibraryResolver。如果不涉及原生库，这个是没问题的。
另外，工控机不一定装了最新版的显卡驱动，WPF 的硬件加速有时候会异常。建议在部署文档里说明：如果发现界面渲染花屏或掉帧，尝试在 app.config 里关闭硬件加速：
5. 常见问题与排查技巧实录
5.1 WPF 界面高频刷新的跨线程异常处理
后台线程更新 UI 集合时，最常见的异常是"调用线程无法访问此对象，因为另一个线程拥有该对象。"我早期也经常犯这个错。后来形成了一套标准处理方案：要么用 Dispatcher.InvokeAsync 切到 UI 线程再更新集合；要么像前面说的，后台只写 Channel，UI 线程通过订阅消费数据。第二种方式更干净，不容易出现锁死。如果你在用 CommunityToolkit.Mvvm，也可以在 ViewModel 里通过 IObservable 的方式封装数据流，UI 侧订阅并更新，配合 Observables 的异步特性，代码还很简洁。
5.2 DataGrid 自动生成列的问题与列宽处理
DataGrid 的 AutoGenerateColumns 默认开启，当你绑定一个有二十个属性的数据源，它会自动生成二十列，界面瞬间爆炸。我的做法是一律设置 AutoGenerateColumns="False"，然后在 XAML 里显式定义每一列。对列宽，还有一个小技巧：如果列内容长度不固定，单独设置 Width="*" 和 MinWidth 配合，不要用固定像素，这样窗口缩放时表格不会出现横向滚动条错位。
5.3 线程 "8608 已退出" 这类信息是什么意思
. NET 8 程序运行时，如果开了调试器，Output 窗口经常能看到类似"线程 0x21a0 已退出，返回值为 0 (0x0)"这样的信息。新手第一次看到会慌，以为是错误。其实这是完全正常的：后台线程完成工作退出时，调试器都会打印一条退出消息，返回值为 0 表示正常退出。你只要确认程序本身没有抛异常，这些信息完全可以无视。我还见过一种情况，.NET 8 的线程池会时不时创建和销毁工作线程，Output 里就会不断出现这类消息，这同样不是程序问题。真正需要注意的，是"线程 0x... 已退出，返回值为 -1 (0xffffffff)"这种非零返回值，那才可能代表某个线程异常终止了。
5.4 Web API 项目运行后没打开网页
这个问题虽然和 WPF 仿真平台不直接相关，但很多 .NET 8 开发者在调试 Web API 时都遇到过。VS2026 或 VS2022 里启动 ASP.NET Core Web API 项目，控制台明明启动了，浏览器却没自动打开。常见原因有三：一是 launchSettings.json 里没有配置 launchBrowser 或者 launchUrl 为空；二是项目设置了不使用 IIS Express，而是用控制台直接跑，但启动配置里没指定打开浏览器；三是防火墙或代理拦截了 localhost 访问。处理办法很直接，检查 Properties/launchSettings.json，确保有 "launchBrowser": { "enabled": true } 并且 "launchUrl": "swagger" 或 "api/values"。如果还不行，手动在浏览器打开 https://localhost:端口/swagger 试试，多半能通。
5.5 程序加密与运行时授权
仿真平台作为交付软件，免不了要处理授权问题。.NET 程序本身很容易被反编译，如果只是防君子不防小人，可以做一个简单的 License 机制：程序启动时读取本机 CPU 序列号或 MAC 地址，生成机器码，然后用 RSA 或 AES 算法对授权文件做签名验证。具体做法是：在程序里嵌入公钥，用私钥在离线环境给客户生成授权文件，程序加载授权文件后校验签名和机器码匹配，不匹配则进入演示模式。
要注意的是，这个方案只能防普通复制，拦不住专业破解，如果你有更高安全需求，建议配合商业混淆工具或者把关键算法放到服务端校验。但不管哪种方案，我都建议在早设计阶段就留好授权接口，不要在开发完成后才硬塞进去。WPF 里做这个并不复杂，一般是在 App.OnStartup 里做校验，如果校验失败弹窗提示并 Shutdown，同时把主窗体的创建延后到校验通过之后。
6. 项目落地过程中的体会与建议
6.1 从零到一的路线图，如果要复刻这个项目
如果你想复刻这个仿真平台，我建议按下面这个顺序推进。第一步先做 G代码解析器，写好单元测试，确保各种格式的代码都能正确解析。第二步实现刀路轨迹计算，在二维平面上把 G01/G02/G03 的路径画出来，这一步不用涉及 3D，先验证算法正确性。第三步加入插补引擎，让刀路按时间和速度自动推进，并把当前坐标显示出来。第四步加入三轴运动学模型，把刀路映射到机床坐标。第五步做 WPF 3D 场景，搭建简单的机床模型，把运动学数据绑定到模型变换。第六步再完善界面，包括 DataGrid、LiveCharts2、MVVM 结构和 Prism 模块化。第七步做性能优化、异常处理和发布部署。
这个过程走下来，你基本就掌握了从算法到界面到部署的完整链路。不要一上来就想着做五轴 RTCP、碰撞检测这些高级功能，三轴能稳定跑通已经是很好的基石了。
6.2 我踩过最值得分享的坑
如果让我只分享一个最深刻的教训，那就是"不要在 UI 线程里做任何仿真计算"。早期版本我把插补计算直接放在 DispatcherTimer 里，代码看起来简单，但一旦 G代码复杂，仿真就开始卡顿，偶尔还会界面假死。后来花了整整两天把线程模型彻底重构为生产消费模式，哪怕是在低配工控机上，连续执行几万行程序也不再卡了。这个结构看似多写了一点代码，但换来的稳定性提升是非线性级的。
还有一个小技巧，关于坐标显示的颜色区分。工控现场操作人员习惯遵循"红黄绿"来区分状态：正常运动显示绿色，接近行程极限显示黄色，超程或报警显示红色。这个看似简单的需求，在 WPF 里只需要一个基于状态的触发器就能实现，但在极大程度上提升了操作员的判断效率，客户评价非常高。做工业软件，功能固然重要，但这些贴合人的操作习惯的小细节，才是区分"能用"和"好用"的关键。
这个项目目前还有很多可以扩展的方向，比如加上五轴 RTCP 算法、接入真实数控系统的通信协议做采集、把仿真引擎封装成服务给其他系统调用。每一步都是独立的技术方向，但底层这套 .NET 8 + WPF 的框架已经足够稳健。希望我踩过的这些坑和总结出来的经验，能帮你少走一些弯路。