企业官网建设流程全解析

1. 项目概述：为什么用 Avalonia 做 Modbus TCP 监控面板不是“炫技”，而是真正在解决实际问题

我第一次在客户现场看到那台老式 PLC 控制柜时，心里就咯噔一下——机柜侧面贴着泛黄的胶带纸，上面手写着“2008年投运，西门子 S7-200 SMART + 国产温控模块”。车间主任递来一张A4纸，上面是密密麻麻的手写点表：“3号冷却泵启停、4号压力传感器值、5号电机温度、6号液位报警……总共87个寄存器地址，要实时显示+手动写入+历史曲线+异常弹窗。”他没提任何技术要求，只说了一句：“上一个用 WPF 做的程序，装在工控机上跑三天必蓝屏，重启后数据全丢。”

这就是我们启动这个 Avalonia + Modbus TCP 监控面板项目的起点。它不是为了赶时髦用新框架，而是被现实逼出来的选择：WPF 在老旧工控机（赛扬 J1900、2GB 内存、Windows 10 LTSC）上内存泄漏严重；WinForms 界面太丑，客户拒绝签字验收；Electron 包体太大，U盘拷贝都卡顿；而 Avalonia —— 它编译后是纯 .NET 运行时 + 本地渲染，不依赖 DirectX 或 GDI+，启动快、内存稳、界面可缩放适配各种分辨率工业屏（从 1024×600 的嵌入式 HMI 到 1920×1080 的触摸一体机），最关键的是：它能真正跨平台，未来迁移到 Linux 工控系统（比如树莓派 + Debian）时，代码复用率超过 90%。

标题里的“踩坑记”三个字，不是修辞，是血泪总结。Modbus TCP 协议本身简单得像一张白纸：TCP 连接 + 功能码 + 寄存器地址 + 数据长度。但工业现场不是实验室——网线插在PLC背面的RJ45口上，中间可能串了三层交换机、一个防火墙策略、两台老旧的HUB，还有隔壁电焊机启动时带来的毫秒级网络抖动。Avalonia 的 UI 线程模型和 Modbus 异步通信的生命周期管理一旦没对齐，轻则界面卡死，重则整个进程崩溃退出。我试过 7 种不同的 Modbus 库组合、重写了 4 次连接状态机、重构了 3 次数据绑定逻辑，才把“从点击按钮到 PLC 实际执行”的端到端延迟压到 85ms 以内，且连续运行 72 小时不掉线。这篇文章，就是把这 3 个月里所有掉进去又爬出来的坑，原原本本摊开给你看。如果你正打算用 Avalonia 做工业监控类应用，无论你是刚学完 C# 基础的新手，还是有十年 WinForms 经验的老工程师，这篇内容都能帮你省下至少两周调试时间——因为所有坑，我都替你踩过了。

2. 整体架构设计与核心选型逻辑：为什么不用 NModbus4？为什么必须自己封装通信层？

2.1 架构分层不是为了画图好看，而是为了隔离工业现场的“不可靠性”

很多初学者一上来就想“直接在 ViewModel 里 new ModbusClient()”，这是最典型的致命错误。工业现场的 Modbus TCP 设备，其连接状态是高度动态的：PLC 可能断电重启、网线被工人误拔、交换机端口因风暴流量被自动禁用、甚至 Modbus 服务端（比如某些国产 RTU）会主动关闭空闲连接。如果 UI 层（Avalonia 的MainWindow）和通信层耦合在一起，一次连接超时就会导致整个界面无响应——用户点按钮没反应，以为程序卡死，强行结束进程，结果历史数据全丢。

我们最终采用四层分离架构：

• UI 层（Avalonia XAML + Code-Behind）：只负责呈现、接收用户操作（如按钮点击、滑块拖动），绝不触碰任何 Socket 或 Modbus 协议细节；
• ViewModel 层（ReactiveUI + ReactiveCommand）：定义业务逻辑流，比如“点击启动按钮 → 触发写入命令 → 更新按钮状态 → 订阅返回结果”，但不关心“怎么发”；
• 通信抽象层（IModbusService 接口）：定义统一契约，如Task<bool> WriteCoilAsync(ushort address, bool value)、IObservable<ModbusDataPoint> ObserveHoldingRegistersAsync(ushort startAddress, ushort count)；
• Modbus 实现层（ModbusTcpClientService 类）：真正处理 TCP 连接、重连策略、帧解析、超时控制、线程安全队列。

这个分层的价值，在第一次遭遇“PLC 断电 12 秒后恢复”时就体现出来了。UI 层通过 ReactiveUI 的WhenAnyValue监听IsConnected属性，自动将所有按钮置灰并显示“设备离线”；通信层检测到连接断开后，立即停止发送请求，并在后台以指数退避方式（1s → 2s → 4s → 8s）尝试重连；一旦重连成功，自动重新订阅所有寄存器，UI 层收到新数据后平滑刷新——整个过程用户无感知，没有弹窗、没有报错、没有卡顿。

2.2 为什么坚决弃用 NModbus4？实测数据告诉你真相

NModbus4 是 GitHub 上 Star 数最多的 .NET Modbus 库，文档齐全，示例丰富。但我在第 3 天就把它从项目中移除了，原因很实在：它在 Avalonia 的多线程环境下存在两个硬伤。

第一，连接对象非线程安全。NModbus4 的ModbusIpMaster实例内部维护了一个TcpClient和一个读写锁，但它的ReadHoldingRegistersAsync方法在并发调用时（比如同时读取温度、压力、液位三个寄存器），会触发内部_stream.ReadAsync的竞争条件。我们在压力测试中模拟每秒 20 次并发读取，持续 5 分钟，NModbus4 出现了 17 次IOException: Unable to read data from the transport connection，错误堆栈指向其内部_stream被多个线程同时读取。这不是偶发，是设计缺陷。

第二，缺乏真正的异步取消支持。NModbus4 的所有Async方法都只是Task.Run包裹同步调用，底层TcpClient.GetStream().Read()是阻塞式 IO。当网络抖动导致单次读取卡住 5 秒，你调用CancellationTokenSource.Cancel()，它根本不会中断底层 Socket 操作，只会让 Task 在超时后抛出OperationCanceledException，但此时TcpClient的连接状态已损坏，后续所有请求都会失败。

我们转而采用LibModbus.NET（一个轻量级、纯 C# 实现的 Modbus 库），并做了关键改造：

• 将TcpClient替换为Socket+SocketAsyncEventArgs，实现真正的异步 IO；
• 所有读写方法均接受CancellationToken，并在Socket.ReceiveAsync返回false时主动检查 token 状态；
• 封装一个ModbusRequestQueue，用ConcurrentQueue+SemaphoreSlim控制并发请求数（默认上限 3），避免 PLC 端因请求洪泛而丢帧。

实测对比（同一台工控机 + 同一 PLC）：

这个数据不是理论推演，是我们在三台不同品牌 PLC（西门子、汇川、信捷）上反复验证的结果。选型不是看 Star 数，而是看它能不能扛住车间里电焊机启动那一瞬间的电压跌落。

2.3 Avalonia 的 UI 线程模型如何与 Modbus 通信“和平共处”

Avalonia 的 UI 线程（Dispatcher Thread）和 .NET 的默认线程池（ThreadPool）是两套独立体系。很多开发者习惯在async void Button_Click里直接await client.ReadHoldingRegistersAsync(...)，这会导致两个严重问题：

• UI 线程被 await 后续的 continuation 占用：虽然ReadHoldingRegistersAsync是异步的，但它的 completion callback 默认在SynchronizationContext（即 Avalonia Dispatcher）上执行。如果回调里做复杂计算（比如解析浮点数、更新 ObservableCollection），UI 线程就会卡住，用户无法滚动列表、点击按钮；
• 数据绑定线程不安全：Avalonia 的ObservableCollection<T>不是线程安全的。如果你在后台线程（比如 Modbus 通信的回调线程）里直接.Add()或.Remove()，会触发InvalidOperationException: Collection was modified。

解决方案是明确划分线程职责：

• 通信层永远运行在 ThreadPool：所有ModbusTcpClientService的方法都标记为ConfigureAwait(false)，确保其内部逻辑完全脱离 UI 线程；
• 数据推送使用 Avalonia 的 Dispatcher.InvokeAsync：当 Modbus 收到新数据，不是直接更新 ViewModel 的属性，而是调用Application.Current.Dispatcher.InvokeAsync(() => { viewModel.Temperature = newValue; })；
• ViewModel 层使用 ReactiveUI 的ObservableAsPropertyHelper：它内部已做好线程调度，你只需定义public readonly ObservableAsPropertyHelper<double> Temperature { get; }，然后在构造函数里绑定client.ObserveHoldingRegister(40001).ToProperty(this, x => x.Temperature, out _);，剩下的线程切换由 ReactiveUI 自动完成。

这个设计让 UI 响应速度提升 3 倍。以前点击“清空历史”按钮，要等 200ms 才有反馈（因为要等 Modbus 读取完成再更新界面）；现在按钮点击瞬间就置灰，数据在后台静默更新，用户感觉“秒响应”。

3. 核心细节解析与实操要点：从寄存器映射到 UI 绑定的完整链路

3.1 Modbus 地址映射：别再被“40001”这种编号搞晕，用真实 PLC 点表说话

工业现场的 Modbus 地址命名，是新人最大的认知门槛。“40001”到底对应哪个寄存器？为什么有的文档写“40001”，有的写“0x0000”？这背后是 Modbus 协议的历史包袱。

Modbus 标准定义了四种寄存器类型：

• 线圈（Coil）：1 位，可读可写，地址范围 00001–09999，功能码 01/05/15；
• 离散输入（Discrete Input）：1 位，只读，地址范围 10001–19999，功能码 02；
• 输入寄存器（Input Register）：16 位，只读，地址范围 30001–39999，功能码 04；
• 保持寄存器（Holding Register）：16 位，可读可写，地址范围 40001–49999，功能码 03/06/16。

注意：这些“00001”、“40001”是协议层面的逻辑地址，不是内存偏移。当你用功能码 03 读取“40001”，实际发送的 Modbus 帧里，起始地址字段填的是0x0000（即十进制 0），因为协议规定“4xxxx”系列寄存器的基地址是 0。同理，“30001”对应0x0000，“00001”也对应0x0000——区别只在功能码。

我们客户的点表是这样写的：

| 标签名 | 类型 | 地址 | 数据类型 | 说明 | |--------------|--------|-------|----------|--------------| | 冷却泵启停 | 线圈 | 00001 | BOOL | 0=停，1=启 | | 入口压力 | 输入寄存器 | 30001 | UINT16 | 单位：kPa | | 出口温度 | 保持寄存器 | 40001 | INT16 | 单位：0.1℃ | | 累计流量 | 保持寄存器 | 40010 | UINT32 | 高16位+低16位 |

在代码里，我们建立一个ModbusAddressMap类，把逻辑地址转换成协议地址：

public static class ModbusAddressMap { // 将 "40001" 转换为协议地址 0x0000 public static ushort ToProtocolAddress(string logicalAddress) => logicalAddress switch { var s when s.StartsWith("0") => ushort.Parse(s.Substring(1)) - 1, // 00001 → 0 var s when s.StartsWith("1") => ushort.Parse(s.Substring(1)) - 1, // 10001 → 0 var s when s.StartsWith("3") => ushort.Parse(s.Substring(1)) - 1, // 30001 → 0 var s when s.StartsWith("4") => ushort.Parse(s.Substring(1)) - 1, // 40001 → 0 _ => throw new ArgumentException($"Invalid Modbus address: {logicalAddress}") }; }

提示：永远不要在代码里硬编码0x0000。把地址映射逻辑抽离出来，未来换 PLC 品牌（比如从西门子换成三菱），只需修改配置文件，不用改一行业务代码。

3.2 数据类型解析：16 位寄存器如何拼出 32 位浮点数？实测三种常见排列组合

Modbus 协议只定义 16 位寄存器，但工业现场需要传输 float、double、int32、uint32 等 32 位数据。这就涉及字节序（Endianness）和寄存器顺序（Word Order）两个维度，而不同 PLC 厂商的实现千差万别。

我们实测了三种主流排列方式（以 32 位浮点数3.1415926f为例，其 IEEE 754 十六进制表示为0x40490FDB）：

关键发现：没有“标准”，只有“约定”。必须拿到 PLC 的 Modbus 通讯手册，确认其“32-bit Float Word Order”和“Byte Order”参数。我们为此专门开发了一个小工具ModbusFloatTester：输入任意 float 值，生成四种排列组合的寄存器值，然后用 Modbus Poll 工具写入 PLC，观察 HMI 上显示的数值，反向验证 PLC 的解析规则。

在 Avalonia 项目中，我们把解析逻辑封装成ModbusDataConverter：

public static class ModbusDataConverter { public static float ToFloat16Bit(ushort highWord, ushort lowWord, FloatWordOrder wordOrder, Endianness endianness) { var bytes = wordOrder switch { FloatWordOrder.HighLow => endianness == Endianness.Big ? new[] { (byte)(highWord >> 8), (byte)highWord, (byte)(lowWord >> 8), (byte)lowWord } : new[] { (byte)highWord, (byte)(highWord >> 8), (byte)lowWord, (byte)(lowWord >> 8) }, FloatWordOrder.LowHigh => endianness == Endianness.Big ? new[] { (byte)(lowWord >> 8), (byte)lowWord, (byte)(highWord >> 8), (byte)highWord } : new[] { (byte)lowWord, (byte)(lowWord >> 8), (byte)highWord, (byte)(highWord >> 8) }, _ => throw new NotSupportedException() }; return BitConverter.ToSingle(bytes, 0); } }

注意：BitConverter.ToSingle在 .NET Core/.NET 5+ 中是跨平台安全的，但在 .NET Framework 下需确保BitConverter.IsLittleEndian与 PLC 设置一致。我们强制在Program.cs中添加AppBuilder.UsePlatformDetect();并在启动时校验环境。

3.3 Avalonia 数据绑定实战：如何让 UI 实时响应 Modbus 数据变化，且不卡顿

Avalonia 的数据绑定能力强大，但工业监控场景有特殊要求：高频更新（如每 100ms 读取一次温度）、大数据量（87 个点）、低延迟响应（按钮点击后 50ms 内反馈）。直接用INotifyPropertyChanged+ObservableCollection会迅速拖垮 UI。

我们采用三级缓存 + 延迟刷新策略：

• Level 1：原始数据缓存（Thread-Safe Dictionary）
  ConcurrentDictionary<string, ModbusRawValue>存储每个点的最新原始值（ushort[]或bool），由 Modbus 通信层直接写入，零开销。

• Level 2：计算值缓存（Lazy Computed）
  ViewModel 中定义public double Temperature => _converter.ToFloat16Bit(RawValues["40001"], RawValues["40002"], ...);，每次访问时才解析，避免预解析浪费 CPU。

• Level 3：UI 绑定缓存（Debounced Observable）
  使用 ReactiveUI 的Throttle操作符，将原始数据流限制为每 200ms 最多推送一次到 UI：

  _modbusService.ObserveHoldingRegister(40001) .Throttle(TimeSpan.FromMilliseconds(200)) .Select(x => _converter.ToTemperature(x)) .ToProperty(this, x => x.Temperature, out _);

XAML 绑定极其简洁：

<TextBlock Text="{Binding Temperature, StringFormat='入口温度：{0:F1} ℃'}" /> <ToggleButton IsChecked="{Binding PumpRunning}" Content="冷却泵" />

实测效果：87 个点全部开启 100ms 刷新，UI 线程 CPU 占用率稳定在 3%~5%，滚动列表帧率保持 60FPS。而如果去掉Throttle，CPU 会飙升到 45%，界面明显卡顿。

实操心得：永远不要在INotifyPropertyChanged的 setter 里做耗时操作（如解析浮点数、格式化字符串）。把计算逻辑下沉到数据源层，UI 层只做“展示”，这是 Avalonia 高性能的底层逻辑。

4. 实操过程与核心环节实现：从零搭建可运行的监控面板

4.1 开发环境准备：VS Code + Avalonia for VS Code 扩展，比 Visual Studio 更适合工业项目

我们放弃 Visual Studio，全程使用 VS Code，原因很实际：

• 工业客户常要求“U盘拷贝即用”，VS Code 是绿色版，解压就能运行；
• Avalonia for VS Code 扩展（官方推荐）提供完整的 XAML 智能提示、热重载（Hot Reload）、控件预览；
• 内存占用仅 VS 的 1/3，工控机上编译不卡死。

安装步骤（Windows）：

1. 下载 VS Code（https://code.visualstudio.com/）；
2. 安装扩展：搜索 “Avalonia for VS Code”，安装官方版本（作者：AvaloniaUI）；
3. 安装 .NET SDK 7.0（必须 7.0，6.0 对 Avalonia 11.x 支持不完整）；
4. 创建项目：终端执行dotnet new avalonia.app -n ModbusMonitor；
5. 添加 NuGet 包：LibModbus.NET、ReactiveUI、DynamicData（用于高性能集合绑定）。

注意：.csproj文件中必须添加<UseWpf>false</UseWpf>和<UseWindowsForms>false</UseWindowsForms>，否则 Avalonia 会悄悄引入 WPF 依赖，导致在无桌面环境的 Windows Server Core 上无法运行。

4.2 核心通信服务实现：一个健壮的 ModbusTcpClientService

以下是ModbusTcpClientService的核心骨架（已脱敏，保留关键逻辑）：

public class ModbusTcpClientService : IModbusService, IDisposable { private readonly ILogger<ModbusTcpClientService> _logger; private readonly SemaphoreSlim _requestSemaphore = new(3, 3); // 限流 private readonly ConcurrentDictionary<string, ModbusRawValue> _cache = new(); private readonly Timer _reconnectTimer; private Socket? _socket; private bool _isConnected; public ModbusTcpClientService(ILogger<ModbusTcpClientService> logger) { _logger = logger; _reconnectTimer = new Timer(ReconnectAsync, null, Timeout.Infinite, Timeout.Infinite); } public async Task ConnectAsync(string host, int port, CancellationToken ct = default) { try { _socket?.Dispose(); _socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); _socket.ConnectAsync(host, port).Wait(ct); _socket.ReceiveTimeout = 3000; _socket.SendTimeout = 3000; _isConnected = true; _logger.LogInformation("Connected to {Host}:{Port}", host, port); _reconnectTimer.Change(Timeout.Infinite, Timeout.Infinite); } catch (Exception ex) { _logger.LogError(ex, "Connect failed to {Host}:{Port}", host, port); StartReconnectTimer(); } } public async Task<bool> WriteCoilAsync(ushort address, bool value, CancellationToken ct = default) { await _requestSemaphore.WaitAsync(ct); try { if (!_isConnected) return false; var frame = ModbusFrameBuilder.BuildWriteSingleCoil(address, value); await SendAndReceiveAsync(frame, ct); return true; } finally { _requestSemaphore.Release(); } } private async Task<byte[]> SendAndReceiveAsync(byte[] frame, CancellationToken ct) { var buffer = new byte[1024]; try { await _socket!.SendAsync(new ArraySegment<byte>(frame), SocketFlags.None, ct); var received = await _socket.ReceiveAsync(new ArraySegment<byte>(buffer), SocketFlags.None, ct); return buffer.Take(received).ToArray(); } catch (OperationCanceledException) { _logger.LogWarning("Request cancelled"); throw; } catch (Exception ex) when (ex is SocketException or IOException) { _logger.LogError(ex, "Socket error"); Disconnect(); throw; } } private void Disconnect() { _socket?.Dispose(); _isConnected = false; _reconnectTimer.Change(TimeSpan.FromSeconds(1), Timeout.Infinite); } private void StartReconnectTimer() => _reconnectTimer.Change(TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(1)); private async void ReconnectAsync(object? _) => await ConnectAsync("192.168.1.100", 502); public void Dispose() { _socket?.Dispose(); _reconnectTimer.Dispose(); _requestSemaphore.Dispose(); } }

这个类的关键设计点：

• SemaphoreSlim限流：防止并发请求压垮 PLC；
• Timer而非Task.Delay重连：避免Task.Delay在异常时丢失上下文；
• Socket而非TcpClient：获得底层控制权，可精确设置SendTimeout/ReceiveTimeout；
• ConcurrentDictionary缓存：为 UI 层提供无锁读取。

4.3 主监控界面实现：用 Avalonia 的 DataGrid + Charting 绘制实时曲线

工业监控的核心是“一眼看清趋势”。我们放弃第三方图表库（如 LiveCharts2，体积大、定制难），用 Avalonia 原生Canvas+Polyline实现轻量级实时曲线。

XAML 片段：

<Grid> <Grid.RowDefinitions> <RowDefinition Height="Auto"/> <RowDefinition Height="*"/> </Grid.RowDefinitions> <!-- 控制区 --> <StackPanel Grid.Row="0" Orientation="Horizontal" Spacing="10" Margin="10"> <Button Content="启动泵" Command="{Binding StartPumpCommand}"/> <Button Content="停止泵" Command="{Binding StopPumpCommand}"/> <TextBlock Text="{Binding StatusText}"/> </StackPanel> <!-- 曲线区 --> <Canvas Grid.Row="1" Margin="10"> <Polyline Points="{Binding TemperaturePoints}" Stroke="Red" StrokeThickness="2"/> <Polyline Points="{Binding PressurePoints}" Stroke="Blue" StrokeThickness="2"/> </Canvas> </Grid>

ViewModel 中维护ObservablePointCollection（继承自ObservableCollection<Point>）：

public class ObservablePointCollection : ObservableCollection<Point> { public void AddPoint(double x, double y) { // 只保留最近 500 个点，避免内存爆炸 if (Count > 500) RemoveAt(0); Add(new Point(x, y)); } } // 在构造函数中订阅 Modbus 数据 _modbusService.ObserveHoldingRegister(40001) .Throttle(TimeSpan.FromMilliseconds(200)) .Select((value, index) => new Point(index * 0.2, _converter.ToTemperature(value))) .Subscribe(point => TemperaturePoints.AddPoint(point.X, point.Y));

实操心得：Polyline.Points绑定的是ObservableCollection<Point>，但 Avalonia 的Polyline不监听集合变更。必须手动调用InvalidateVisual()强制重绘。我们在AddPoint方法末尾添加this.InvalidateVisual();，确保曲线实时刷新。

5. 常见问题与排查技巧实录：那些让你抓狂的“玄学”问题，其实都有解

5.1 问题速查表：高频故障现象、根本原因与一键修复方案

5.2 真实踩坑案例：那个消失的“0.1 秒”，让我们调试了 17 小时

最折磨人的问题，往往藏在最不起眼的角落。我们遇到一个诡异现象：程序在开发机（i7-10700K）上一切正常，但部署到客户工控机（赛扬 J1900）后，温度曲线每隔 10 秒就“跳变”一次，数值突增 5℃，持续 0.1 秒后恢复正常。

排查过程：

• 第 1 小时：怀疑 Modbus 读取错误，加日志发现原始寄存器值稳定；
• 第 3 小时：怀疑 UI 绑定问题，用 Snoop 工具监控Temperature属性变更，发现变更事件确实每 10 秒触发一次异常峰值；
• 第 8 小时：怀疑定时器精度，将Timer替换为System.Threading.Timer，问题依旧；
• 第 12 小时：用 Process Monitor 监控文件 IO，发现每 10 秒有一次CreateFile操作，目标是C:\Windows\System32\drivers\etc\hosts；
• 第 15 小时：终于定位：工控机上安装了某国产杀毒软件，其“网络防护”模块会每 10 秒扫描 hosts 文件，触发 .NET 的FileSystemWatcher事件，而 Avalonia 的ResourceLocator内部监听了该事件，导致资源重载，意外触发了 ViewModel 的OnPropertyChanged重绘。

解决方案：在Program.cs中禁用敏感目录监听：

// 在 AppBuilder.Build() 之前添加 AppDomain.CurrentDomain.AssemblyLoad += (s, e) => { // 防止杀软扫描触发误重载 if (e.LoadedAssembly.FullName.Contains("Avalonia")) AvaloniaLocator.CurrentMutable.Bind<IResourceLocator>().ToConstant(new DefaultResourceLocator()); };

这个案例告诉我们：工业环境的“异常”，90% 来自非技术因素。永远先问“这台机器上装了什么别的软件”，而不是立刻怀疑代码。

5.3 部署与运维技巧：如何让客户自己搞定“重启”和“换 IP”

工业客户的技术人员，可能只会“双击图标”和“右键属性改 IP”。我们的部署包必须做到：

• 双击ModbusMonitor.exe直接运行（无需安装 .NET Runtime）；
• IP 地址、端口、点表配置外置为config.json；
• 日志自动归档，保留最近 7 天；
• 崩溃时自动生成crash.dmp并提示“请将此文件发给技术支持”。

实现方式：

• 使用dotnet publish -r win-x64 --self-contained true发布，生成独立可执行文件；
• config.json示例：

  { "Modbus": { "Host": "192.168.1.100", "Port": 502, "ReconnectIntervalSeconds": 1, "TimeoutMilliseconds": 3000 }, "Points": [ { "Tag": "PumpRunning", "Address": "00001", "Type": "Coil" }, { "Tag": "Temperature", "Address": "40001", "Type": "HoldingRegister", "DataType": "Float32", "WordOrder": "HighLow", "Endianness": "Little" } ] }

• 日志使用Serilog+Filesink，按天分割；
• 崩溃处理：在Program.cs中添加AppDomain.CurrentDomain.UnhandledException和TaskScheduler.UnobservedTaskException全局捕获。

最后交付给客户的，是一个压缩包，解压后只有 4 个文件：

• ModbusMonitor.exe（主程序）
• config.json（客户可双击用记事本修改）