简介这是一套面向C#桌面开发者的WinForm实例源码合集适合初学者入门练手也适合有经验的开发者查阅参考。内容覆盖窗体设计、控件布局、图像处理、报表打印、系统信息获取、文件读写、网络通信、数据库访问、加密解密以及硬件读写等十余个方向每个实例都是可独立运行调试的小型项目便于理解C#语法与WinForm框架的实际运用。压缩包共收录5058个文件以cs源码、exe可执行程序、resx与resources资源文件、csproj与sln工程文件为主另含dll、mdb数据库、rpt报表、ico与bmp图像等配套素材整体约40.66MB工程结构完整可直接用Visual Studio打开学习。目前已有10280人学习下载无论是想快速查找某类功能的实现思路还是系统梳理WinForm开发技巧都能从中获得可复用的代码范例与排错参考。1. 198个经典C# WinForm实例源码从能跑到能改的距离很多人第一次接触 WinForm 项目案例都是从一份打包好的源码合集开始的。198 个经典 C# WinForm 实例源码这类资源价值不在于数字本身而在于它把控件用法、事件模型、界面布局、串口通信、DataGridView 绑定这些零散知识点压缩成了可以直接 F5 运行的最小工程。你打开一个实例能看到窗体设计器里的控件树能看到按钮点击后走了哪条分支这比看文档快得多。但问题也在这里能跑通不等于能改。多数人卡在把实例里的按钮换成自己的业务逻辑、把写死的路径换成配置、把单窗体 demo 拆成可维护结构这一步。这篇笔记就按这个路径走先讲清这类源码合集到底该怎么读再落到几个高频场景的改造方法最后把踩过的坑摊开说。适合已经会拖控件、但一改就报错、一重构就崩的 WinForm 开发者。2. 读源码合集的正确姿势先分类再动手拿到 198 个实例最忌讳从第一个文件夹顺序往下点。这些实例通常按功能散落有的讲控件有的讲文件有的讲硬件通信难度和依赖完全不同。先花半小时做分类后面能省掉大量无效编译。2.1 按依赖类型把实例分成四类我一般会先看每个实例的引用和 using把它们分成四类。第一类是纯 UI 控件演示只依赖 System.Windows.Forms 和 System.Drawing比如自定义圆弧文本框、仪表盘控件、窗体背景图。第二类是数据与文件操作涉及 DataGridView、ListView、CSV 读写、文档书签替换。第三类是硬件与通信包括串口收发、TCP 多客户端、OPC 连接、LED 屏显示。第四类是框架与进阶比如委托与事件、Task 用法、上位机通用框架。分类的意义在于第一类可以随便改改坏了也不影响运行环境第二类要注意文件路径和编码第三类必须有对应硬件或模拟器才能验证第四类改动面最大容易牵一发动全身。新手建议从第一类入手先建立“改一处、看一处”的手感。2.2 用最小改动法验证一个实例是否可复用选定一个实例后不要急着加功能。先做一次最小改动把窗体标题改掉把某个按钮的 Text 改掉运行看是否正常。这一步是在确认工程本身没有隐藏的绝对路径或缺失依赖。// 在 Form1 的构造函数里InitializeComponent 之后加一行 public Form1() { InitializeComponent(); this.Text 改造验证 - 温度监控; // 改标题验证工程可编译可运行 btnStart.Text 启动采集; // 改按钮文字验证设计器与代码同步 }这段代码的作用是确认设计器生成的代码和手写代码没有冲突。参数说明this.Text改的是窗体标题栏btnStart.Text改的是控件显示文字两者都不涉及业务逻辑属于安全改动。如果这一步就报错说明工程缺少引用或目标框架不匹配先解决环境问题再往下走。2.3 把写死的路径和端口抽成配置实例里最常见的坏味道是写死路径比如D:\data\test.csv或者写死串口号COM3。直接改成自己的路径能跑但换台机器就崩。正确做法是抽到App.config或一个简单的配置类。// App.config 里加 // appSettings // add keyDataPath valuedata\record.csv/ // add keyPortName valueCOM3/ // /appSettings using System.Configuration; string dataPath ConfigurationManager.AppSettings[DataPath]; string portName ConfigurationManager.AppSettings[PortName]; // 路径做一次存在性检查避免第一次运行就抛异常 string fullPath Path.Combine(AppDomain.CurrentDomain.BaseDirectory, dataPath); string dir Path.GetDirectoryName(fullPath); if (!Directory.Exists(dir)) { Directory.CreateDirectory(dir); }逻辑说明ConfigurationManager读取的是配置文件改配置不用重新编译。AppDomain.CurrentDomain.BaseDirectory拿到的是程序运行目录比写死盘符可靠。参数说明DataPath用相对路径PortName留给现场调试时改。这一步做完实例才算从“演示”变成“能部署”。3. 高频场景改造DataGridView、串口与委托分类之后真正花时间的是几个高频场景。198 个实例里DataGridView 绑定、串口收发、委托跨线程更新 UI 这三类出现频率最高也最容易翻车。下面按“先讲为什么再给可抄代码”的顺序展开。3.1 DataGridView 把 List 的 0/1 列显示成 CheckBox这是搜索里很典型的需求数据源是一个ListT其中某列是 int 类型的 0 和 1但界面上要显示成复选框。直接绑定会显示数字因为 DataGridView 默认按数据类型选列样式。正确做法是手动添加DataGridViewCheckBoxColumn并用CellFormatting或CellValueChanged做转换。下面给一个完整可抄的写法。public class Device { public string Name { get; set; } public int Enabled { get; set; } // 0 或 1 } // 绑定阶段 var list new ListDevice { new Device { Name 泵1, Enabled 1 }, new Device { Name 泵2, Enabled 0 } }; var table new DataTable(); table.Columns.Add(Name, typeof(string)); table.Columns.Add(Enabled, typeof(bool)); // 关键列类型设为 bool foreach (var d in list) { table.Rows.Add(d.Name, d.Enabled 1); } dataGridView1.AutoGenerateColumns true; dataGridView1.DataSource table;逻辑说明不直接把ListDevice绑上去而是转成DataTable并把Enabled列声明为bool。这样 DataGridView 会自动生成 CheckBox 列。参数说明AutoGenerateColumns true让列自动生成如果实例里已经手动定义了列就把DataGridViewCheckBoxColumn的DataPropertyName设为Enabled。回写时注意bool转回int别直接赋给原对象。3.2 串口收发别在 DataReceived 里直接碰控件串口实例几乎都会踩这个坑SerialPort.DataReceived是在后台线程触发的直接在里面更新 TextBox 会抛跨线程异常。正确做法是用Invoke或BeginInvoke切回 UI 线程。private void SerialPort_DataReceived(object sender, SerialDataReceivedEventArgs e) { int count serialPort1.BytesToRead; byte[] buffer new byte[count]; serialPort1.Read(buffer, 0, count); string text BitConverter.ToString(buffer); // 简单展示十六进制 // 切回 UI 线程再更新控件 this.BeginInvoke(new Action(() { txtRecv.AppendText(text Environment.NewLine); })); }逻辑说明BytesToRead先取当前缓冲区长度再Read到字节数组避免读多或读少。BeginInvoke把更新操作排到 UI 消息队列不阻塞串口线程。参数说明BitConverter.ToString输出的是带连字符的十六进制如果要按文本协议解析换成Encoding.ASCII.GetString或对应编码。注意串口打开前要设好BaudRate、DataBits、StopBits、Parity这些参数必须和现场设备一致否则收到的全是乱码。3.3 委托与事件把窗体间的耦合拆开实例里常见一个窗体直接调用另一个窗体的控件改起来很痛苦。用委托和事件可以把“谁通知谁”这件事解耦。下面是一个子窗体通知主窗体的最小写法。// 子窗体定义事件 public partial class ChildForm : Form { public event Actionstring DataSubmitted; private void btnOk_Click(object sender, EventArgs e) { DataSubmitted?.Invoke(txtInput.Text); this.Close(); } } // 主窗体订阅 private void btnOpenChild_Click(object sender, EventArgs e) { var child new ChildForm(); child.DataSubmitted (value) { txtMain.Text value; // 主窗体自己决定怎么处理 }; child.Show(); }逻辑说明子窗体只负责“我提交了数据”不关心谁接收。主窗体通过订阅事件拿到数据自己更新自己的控件。参数说明Actionstring表示无返回值、带一个 string 参数的委托如果要多参数就换成自定义委托或EventHandlerT。这样改完子窗体可以复用到别的父窗体不用改内部代码。4. 避坑与排查那些让实例跑不起来的细节实例源码在别人机器上能跑到你这里报错八成是下面几个原因。这一章按“现象 → 原因 → 解决”写都是实际改代码时反复遇到的。4.1 现象编译报错“找不到类型或命名空间”原因通常是目标框架不匹配。老实例可能基于 .NET Framework 4.0而你用的是 4.7 或 .NET 6。WinForm 在 .NET Core 之后变化较大部分 API 被移除或改名。解决右键项目看目标框架如果是 .NET Framework 项目尽量用 4.7.2 或 4.8 打开如果是 .NET 6注意System.Configuration需要单独装 NuGet 包ConfigurationManager不再默认可用。4.2 现象串口打开报“拒绝访问”原因一般是串口被其他程序占用或者实例里写死的 COM 口号在你机器上不存在。解决先用设备管理器确认实际串口号再改配置。打开前加 try-catch把UnauthorizedAccessException单独捕获提示“串口被占用”。不要反复点打开按钮先关再开。4.3 现象DataGridView 绑定后修改数据不生效原因可能是绑定了ListT而不是BindingListTList不会触发变更通知。解决把数据源换成BindingListT或者像 3.1 那样转成DataTable。如果必须用List就在修改后重新赋值DataSource但这样会丢失选中行体验差。4.4 现象窗体背景图设置后闪烁严重原因是在OnPaintBackground里做了重绘或者背景图太大且没有开启双缓冲。解决设置this.DoubleBuffered true;背景图提前缩放成窗体大小不要每次绘制都拉伸原图。如果实例里用了自定义控件检查是否在Paint事件里反复创建Graphics对象。4.5 现象调用 C 库时报 AccessViolation c0000005原因通常是 P/Invoke 的参数类型或调用约定不匹配比如把char*当成string传或者结构体对齐方式不对。解决先确认 C 导出函数的调用约定是__stdcall还是__cdecl在DllImport里对应写CallingConvention。结构体加[StructLayout(LayoutKind.Sequential)]字符串用MarshalAs(UnmanagedType.LPStr)明确指定。不要凭感觉传参对照头文件逐个核对。5. 从实例到项目把 198 个片段收成一个可维护框架改完几个实例后你会发现真正缺的不是代码而是组织方式。198 个实例是散落的零件要变成能交付的项目得做三件事统一配置、统一日志、统一异常处理。下面给一个最小可用的骨架不依赖第三方库。5.1 用静态类收拢全局配置和日志public static class AppCore { public static string DataDir { get; private set; } public static string LogFile { get; private set; } static AppCore() { DataDir Path.Combine(AppDomain.CurrentDomain.BaseDirectory, data); if (!Directory.Exists(DataDir)) Directory.CreateDirectory(DataDir); LogFile Path.Combine(DataDir, app.log); } public static void Log(string msg) { string line ${DateTime.Now:yyyy-MM-dd HH:mm:ss} {msg}; File.AppendAllText(LogFile, line Environment.NewLine); } }逻辑说明静态构造函数在第一次访问时执行保证目录存在。Log用追加写入避免覆盖。参数说明日志文件放在 data 目录下和业务数据分开。如果并发写入频繁换成带锁的StreamWriter或者用File.AppendAllText加lock。5.2 全局异常捕获别让程序直接消失WinForm 程序未处理异常会直接闪退现场很难排查。在Program.cs里挂三个事件。static void Main() { Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException); Application.ThreadException (s, e) { AppCore.Log(UI异常: e.Exception.Message); MessageBox.Show(发生错误已记录日志); }; AppDomain.CurrentDomain.UnhandledException (s, e) { AppCore.Log(非UI异常: e.ExceptionObject.ToString()); }; Application.EnableVisualStyles(); Application.Run(new MainForm()); }逻辑说明ThreadException捕获 UI 线程异常UnhandledException捕获其他线程异常。参数说明SetUnhandledExceptionMode必须在创建任何窗体之前调用。这样即使某个实例改造后出问题也能留下日志而不是白屏。5.3 验证方法用一个实例走完整流程拿串口温度监控这个场景做验证打开串口、定时读取、DataGridView 显示、异常写日志、关闭时释放串口。跑通一遍再换一个 DataGridView 绑定的实例确认配置和日志都能复用。如果两个实例都能在不改 AppCore 的情况下运行说明骨架立住了。验证项检查内容通过标准配置读取App.config 改路径后是否生效不重新编译也能换目录日志写入异常时是否生成 app.log文件存在且内容带时间戳串口释放关闭窗体后串口是否可再次打开不报“拒绝访问”跨线程更新串口收数据时 UI 是否卡死界面可拖动数据正常追加这套骨架不复杂但能把 198 个实例从“能跑”拉到“能改、能查、能交付”。我自己的习惯是每改一个实例就把配置和日志接进来改到第十个的时候新实例基本十分钟就能并入现有结构。希望帮到你。本文还有配套的精品资源点击获取
198个C# WinForm实例源码改造指南：从能跑到能改的实战技巧
简介这是一套面向C#桌面开发者的WinForm实例源码合集适合初学者入门练手也适合有经验的开发者查阅参考。内容覆盖窗体设计、控件布局、图像处理、报表打印、系统信息获取、文件读写、网络通信、数据库访问、加密解密以及硬件读写等十余个方向每个实例都是可独立运行调试的小型项目便于理解C#语法与WinForm框架的实际运用。压缩包共收录5058个文件以cs源码、exe可执行程序、resx与resources资源文件、csproj与sln工程文件为主另含dll、mdb数据库、rpt报表、ico与bmp图像等配套素材整体约40.66MB工程结构完整可直接用Visual Studio打开学习。目前已有10280人学习下载无论是想快速查找某类功能的实现思路还是系统梳理WinForm开发技巧都能从中获得可复用的代码范例与排错参考。1. 198个经典C# WinForm实例源码从能跑到能改的距离很多人第一次接触 WinForm 项目案例都是从一份打包好的源码合集开始的。198 个经典 C# WinForm 实例源码这类资源价值不在于数字本身而在于它把控件用法、事件模型、界面布局、串口通信、DataGridView 绑定这些零散知识点压缩成了可以直接 F5 运行的最小工程。你打开一个实例能看到窗体设计器里的控件树能看到按钮点击后走了哪条分支这比看文档快得多。但问题也在这里能跑通不等于能改。多数人卡在把实例里的按钮换成自己的业务逻辑、把写死的路径换成配置、把单窗体 demo 拆成可维护结构这一步。这篇笔记就按这个路径走先讲清这类源码合集到底该怎么读再落到几个高频场景的改造方法最后把踩过的坑摊开说。适合已经会拖控件、但一改就报错、一重构就崩的 WinForm 开发者。2. 读源码合集的正确姿势先分类再动手拿到 198 个实例最忌讳从第一个文件夹顺序往下点。这些实例通常按功能散落有的讲控件有的讲文件有的讲硬件通信难度和依赖完全不同。先花半小时做分类后面能省掉大量无效编译。2.1 按依赖类型把实例分成四类我一般会先看每个实例的引用和 using把它们分成四类。第一类是纯 UI 控件演示只依赖 System.Windows.Forms 和 System.Drawing比如自定义圆弧文本框、仪表盘控件、窗体背景图。第二类是数据与文件操作涉及 DataGridView、ListView、CSV 读写、文档书签替换。第三类是硬件与通信包括串口收发、TCP 多客户端、OPC 连接、LED 屏显示。第四类是框架与进阶比如委托与事件、Task 用法、上位机通用框架。分类的意义在于第一类可以随便改改坏了也不影响运行环境第二类要注意文件路径和编码第三类必须有对应硬件或模拟器才能验证第四类改动面最大容易牵一发动全身。新手建议从第一类入手先建立“改一处、看一处”的手感。2.2 用最小改动法验证一个实例是否可复用选定一个实例后不要急着加功能。先做一次最小改动把窗体标题改掉把某个按钮的 Text 改掉运行看是否正常。这一步是在确认工程本身没有隐藏的绝对路径或缺失依赖。// 在 Form1 的构造函数里InitializeComponent 之后加一行 public Form1() { InitializeComponent(); this.Text 改造验证 - 温度监控; // 改标题验证工程可编译可运行 btnStart.Text 启动采集; // 改按钮文字验证设计器与代码同步 }这段代码的作用是确认设计器生成的代码和手写代码没有冲突。参数说明this.Text改的是窗体标题栏btnStart.Text改的是控件显示文字两者都不涉及业务逻辑属于安全改动。如果这一步就报错说明工程缺少引用或目标框架不匹配先解决环境问题再往下走。2.3 把写死的路径和端口抽成配置实例里最常见的坏味道是写死路径比如D:\data\test.csv或者写死串口号COM3。直接改成自己的路径能跑但换台机器就崩。正确做法是抽到App.config或一个简单的配置类。// App.config 里加 // appSettings // add keyDataPath valuedata\record.csv/ // add keyPortName valueCOM3/ // /appSettings using System.Configuration; string dataPath ConfigurationManager.AppSettings[DataPath]; string portName ConfigurationManager.AppSettings[PortName]; // 路径做一次存在性检查避免第一次运行就抛异常 string fullPath Path.Combine(AppDomain.CurrentDomain.BaseDirectory, dataPath); string dir Path.GetDirectoryName(fullPath); if (!Directory.Exists(dir)) { Directory.CreateDirectory(dir); }逻辑说明ConfigurationManager读取的是配置文件改配置不用重新编译。AppDomain.CurrentDomain.BaseDirectory拿到的是程序运行目录比写死盘符可靠。参数说明DataPath用相对路径PortName留给现场调试时改。这一步做完实例才算从“演示”变成“能部署”。3. 高频场景改造DataGridView、串口与委托分类之后真正花时间的是几个高频场景。198 个实例里DataGridView 绑定、串口收发、委托跨线程更新 UI 这三类出现频率最高也最容易翻车。下面按“先讲为什么再给可抄代码”的顺序展开。3.1 DataGridView 把 List 的 0/1 列显示成 CheckBox这是搜索里很典型的需求数据源是一个ListT其中某列是 int 类型的 0 和 1但界面上要显示成复选框。直接绑定会显示数字因为 DataGridView 默认按数据类型选列样式。正确做法是手动添加DataGridViewCheckBoxColumn并用CellFormatting或CellValueChanged做转换。下面给一个完整可抄的写法。public class Device { public string Name { get; set; } public int Enabled { get; set; } // 0 或 1 } // 绑定阶段 var list new ListDevice { new Device { Name 泵1, Enabled 1 }, new Device { Name 泵2, Enabled 0 } }; var table new DataTable(); table.Columns.Add(Name, typeof(string)); table.Columns.Add(Enabled, typeof(bool)); // 关键列类型设为 bool foreach (var d in list) { table.Rows.Add(d.Name, d.Enabled 1); } dataGridView1.AutoGenerateColumns true; dataGridView1.DataSource table;逻辑说明不直接把ListDevice绑上去而是转成DataTable并把Enabled列声明为bool。这样 DataGridView 会自动生成 CheckBox 列。参数说明AutoGenerateColumns true让列自动生成如果实例里已经手动定义了列就把DataGridViewCheckBoxColumn的DataPropertyName设为Enabled。回写时注意bool转回int别直接赋给原对象。3.2 串口收发别在 DataReceived 里直接碰控件串口实例几乎都会踩这个坑SerialPort.DataReceived是在后台线程触发的直接在里面更新 TextBox 会抛跨线程异常。正确做法是用Invoke或BeginInvoke切回 UI 线程。private void SerialPort_DataReceived(object sender, SerialDataReceivedEventArgs e) { int count serialPort1.BytesToRead; byte[] buffer new byte[count]; serialPort1.Read(buffer, 0, count); string text BitConverter.ToString(buffer); // 简单展示十六进制 // 切回 UI 线程再更新控件 this.BeginInvoke(new Action(() { txtRecv.AppendText(text Environment.NewLine); })); }逻辑说明BytesToRead先取当前缓冲区长度再Read到字节数组避免读多或读少。BeginInvoke把更新操作排到 UI 消息队列不阻塞串口线程。参数说明BitConverter.ToString输出的是带连字符的十六进制如果要按文本协议解析换成Encoding.ASCII.GetString或对应编码。注意串口打开前要设好BaudRate、DataBits、StopBits、Parity这些参数必须和现场设备一致否则收到的全是乱码。3.3 委托与事件把窗体间的耦合拆开实例里常见一个窗体直接调用另一个窗体的控件改起来很痛苦。用委托和事件可以把“谁通知谁”这件事解耦。下面是一个子窗体通知主窗体的最小写法。// 子窗体定义事件 public partial class ChildForm : Form { public event Actionstring DataSubmitted; private void btnOk_Click(object sender, EventArgs e) { DataSubmitted?.Invoke(txtInput.Text); this.Close(); } } // 主窗体订阅 private void btnOpenChild_Click(object sender, EventArgs e) { var child new ChildForm(); child.DataSubmitted (value) { txtMain.Text value; // 主窗体自己决定怎么处理 }; child.Show(); }逻辑说明子窗体只负责“我提交了数据”不关心谁接收。主窗体通过订阅事件拿到数据自己更新自己的控件。参数说明Actionstring表示无返回值、带一个 string 参数的委托如果要多参数就换成自定义委托或EventHandlerT。这样改完子窗体可以复用到别的父窗体不用改内部代码。4. 避坑与排查那些让实例跑不起来的细节实例源码在别人机器上能跑到你这里报错八成是下面几个原因。这一章按“现象 → 原因 → 解决”写都是实际改代码时反复遇到的。4.1 现象编译报错“找不到类型或命名空间”原因通常是目标框架不匹配。老实例可能基于 .NET Framework 4.0而你用的是 4.7 或 .NET 6。WinForm 在 .NET Core 之后变化较大部分 API 被移除或改名。解决右键项目看目标框架如果是 .NET Framework 项目尽量用 4.7.2 或 4.8 打开如果是 .NET 6注意System.Configuration需要单独装 NuGet 包ConfigurationManager不再默认可用。4.2 现象串口打开报“拒绝访问”原因一般是串口被其他程序占用或者实例里写死的 COM 口号在你机器上不存在。解决先用设备管理器确认实际串口号再改配置。打开前加 try-catch把UnauthorizedAccessException单独捕获提示“串口被占用”。不要反复点打开按钮先关再开。4.3 现象DataGridView 绑定后修改数据不生效原因可能是绑定了ListT而不是BindingListTList不会触发变更通知。解决把数据源换成BindingListT或者像 3.1 那样转成DataTable。如果必须用List就在修改后重新赋值DataSource但这样会丢失选中行体验差。4.4 现象窗体背景图设置后闪烁严重原因是在OnPaintBackground里做了重绘或者背景图太大且没有开启双缓冲。解决设置this.DoubleBuffered true;背景图提前缩放成窗体大小不要每次绘制都拉伸原图。如果实例里用了自定义控件检查是否在Paint事件里反复创建Graphics对象。4.5 现象调用 C 库时报 AccessViolation c0000005原因通常是 P/Invoke 的参数类型或调用约定不匹配比如把char*当成string传或者结构体对齐方式不对。解决先确认 C 导出函数的调用约定是__stdcall还是__cdecl在DllImport里对应写CallingConvention。结构体加[StructLayout(LayoutKind.Sequential)]字符串用MarshalAs(UnmanagedType.LPStr)明确指定。不要凭感觉传参对照头文件逐个核对。5. 从实例到项目把 198 个片段收成一个可维护框架改完几个实例后你会发现真正缺的不是代码而是组织方式。198 个实例是散落的零件要变成能交付的项目得做三件事统一配置、统一日志、统一异常处理。下面给一个最小可用的骨架不依赖第三方库。5.1 用静态类收拢全局配置和日志public static class AppCore { public static string DataDir { get; private set; } public static string LogFile { get; private set; } static AppCore() { DataDir Path.Combine(AppDomain.CurrentDomain.BaseDirectory, data); if (!Directory.Exists(DataDir)) Directory.CreateDirectory(DataDir); LogFile Path.Combine(DataDir, app.log); } public static void Log(string msg) { string line ${DateTime.Now:yyyy-MM-dd HH:mm:ss} {msg}; File.AppendAllText(LogFile, line Environment.NewLine); } }逻辑说明静态构造函数在第一次访问时执行保证目录存在。Log用追加写入避免覆盖。参数说明日志文件放在 data 目录下和业务数据分开。如果并发写入频繁换成带锁的StreamWriter或者用File.AppendAllText加lock。5.2 全局异常捕获别让程序直接消失WinForm 程序未处理异常会直接闪退现场很难排查。在Program.cs里挂三个事件。static void Main() { Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException); Application.ThreadException (s, e) { AppCore.Log(UI异常: e.Exception.Message); MessageBox.Show(发生错误已记录日志); }; AppDomain.CurrentDomain.UnhandledException (s, e) { AppCore.Log(非UI异常: e.ExceptionObject.ToString()); }; Application.EnableVisualStyles(); Application.Run(new MainForm()); }逻辑说明ThreadException捕获 UI 线程异常UnhandledException捕获其他线程异常。参数说明SetUnhandledExceptionMode必须在创建任何窗体之前调用。这样即使某个实例改造后出问题也能留下日志而不是白屏。5.3 验证方法用一个实例走完整流程拿串口温度监控这个场景做验证打开串口、定时读取、DataGridView 显示、异常写日志、关闭时释放串口。跑通一遍再换一个 DataGridView 绑定的实例确认配置和日志都能复用。如果两个实例都能在不改 AppCore 的情况下运行说明骨架立住了。验证项检查内容通过标准配置读取App.config 改路径后是否生效不重新编译也能换目录日志写入异常时是否生成 app.log文件存在且内容带时间戳串口释放关闭窗体后串口是否可再次打开不报“拒绝访问”跨线程更新串口收数据时 UI 是否卡死界面可拖动数据正常追加这套骨架不复杂但能把 198 个实例从“能跑”拉到“能改、能查、能交付”。我自己的习惯是每改一个实例就把配置和日志接进来改到第十个的时候新实例基本十分钟就能并入现有结构。希望帮到你。本文还有配套的精品资源点击获取
