C#串口16进制收发工具：SerialPort线程边界与帧解析实践

简介：这份C#串口16进制收发程序源码面向需要与硬件设备通信的开发者、电子工程师及嵌入式学习者，重点解决串口调试中十六进制数据收发与显示的问题。压缩包共21个文件、约37KB，包含6个cs源码文件、3个exe可执行文件及sln解决方案、csproj项目文件、resx/resources资源和pdb调试文件等，既有可运行程序也保留完整工程结构，便于直接体验或二次修改。已有1800人学习下载，说明其在串口通信入门与调试场景中具有一定参考价值。源码围绕串口控件封装了端口打开关闭、波特率与校验位等参数设置、数据接收发送事件处理，以及字节数据与十六进制字符串之间的相互转换，并配有输入输出界面。读者可据此理解C#中SerialPort的调用方式、异步收发流程和低层协议数据处理思路，适合用作课程实验、设备联调或项目开发的基础样例。

1. 台架上只有一台笔记本时，这个工具的价值就出来了

上个月去一个设备调试现场，厂家给的上位机软件装在三年前的笔记本上，打开就报缺库，重装又要走流程。现场情况是：设备每 100ms 吐一帧十六进制数据，帧头固定0xAA 0x55，我需要确认它到底发没发、发的内容对不对。手边只有一台装了 Visual Studio 的机器，于是花了半小时写了个 C# 串口控件的小工具——选串口、选波特率、十六进制发送、十六进制接收、加时间戳。这份「C#写的串口16进制收发程序」源码就是这类东西的完整形态：它不解决业务问题，但它是所有串口业务问题的第一现场。适合谁？刚接触 C# 串口控件、需要快速验证硬件通不通的嵌入式/工控方向开发者，以及要在这套壳子上继续长出一个协议解析工具的人。它最大的价值不是功能多，是把「打开端口、发字节、收字节、看字节」这条链路的坑都摆在明面上了。

2. 工程骨架与 SerialPort 选型：一个单窗体工程怎么分层

2.1 目录结构里藏着的设计取向

这类工具的源码包解开之后，结构通常非常朴素，没有分层架构、没有 DI 容器，就是一个 WinForms 工程加几个辅助类。我一般会先扫一遍目录，判断作者是「拖控件一把梭」还是「至少做了点封装」，这两种风格后续改造的成本差很远。

SerialHexTool/ ├── SerialHexTool.sln ├── SerialHexTool/ │ ├── Program.cs # 入口，Application.Run(new MainForm()) │ ├── MainForm.cs # 主窗体：串口配置 + 收发显示 │ ├── MainForm.Designer.cs # 控件声明与布局（工具自动生成） │ ├── MainForm.resx # 窗体资源 │ ├── Core/ │ │ ├── HexConverter.cs # 字符串 <-> 字节数组 互转 │ │ ├── FrameParser.cs # 帧头帧尾定位、粘包拆分 │ │ └── PortManager.cs # 串口打开/关闭/发送的薄封装 │ ├── Models/ │ │ └── SerialConfig.cs # 端口参数快照，便于保存配置 │ └── Properties/ │ └── Settings.settings # 上次使用的端口、波特率记忆 └── README.md

Core目录是关键。如果收发逻辑全挤在MainForm.cs里，那这个工程的定位就是「临时调试脚本的图形化版本」，改起来能改，但每加一条协议规则都得在事件回调里插代码。反过来，HexConverter和FrameParser被单独抽出来的话，这两块是可以直接搬到上位机项目里复用的——单元测试也好写，不需要起窗体。

我一般判断一个串口 Demo 值不值得接着做，就看两件事：转换逻辑有没有独立成类，串口对象是不是在窗体关闭时被正确释放。前者决定可维护性，后者决定它会不会在客户现场蓝屏重启。

2.2 控件拖拽和 new SerialPort 的差别

Visual Studio 工具箱里有个SerialPort组件，拖到窗体上就会生成一个components容器托管的实例，Designer.cs里会自动补一行this.serialPort1 = new System.IO.Ports.SerialPort(this.components);。很多入门教程都这么教，源码包里也常见这种写法。它能用，但有两个后果：一是串口对象生命周期跟随窗体，窗体 Dispose 时它会跟着 Dispose，顺序不可控；二是参数只能在属性面板里写死，运行时切换端口要写代码改属性。

我更倾向手写new SerialPort()，放进PortManager里显式管理。区别如下：

新手照着跑通，两种都行；要二次开发，第二个更省心。

2.3 端口参数：六个必填项和三个常被忽略的开关

串口通信对不上，九成是参数不匹配。这份源码里暴露的配置项基本是标准六件套，我按实际调试顺序列一下：

后面三个在教程里经常被跳过，但你一旦碰到「一打开串口设备就重启」或者「设备死活不发数据」，多半是 DTR/RTS 电平的问题。这个属于玄学范畴，抓包抓不到，只能靠试。

2.4 DataReceived 跑在哪条线程上

这是整套代码里最容易被误解的一点。SerialPort.DataReceived事件不是在 UI 线程触发的，它跑在ThreadPool的工作线程上。也就是说，事件处理函数里直接写textBox1.AppendText(...)在调试时可能看着没事，跑久了就会抛InvalidOperationException: 线程间操作无效。

它的触发时机也不是「每收到一个字节触发一次」。内部逻辑是：串口驱动收到数据后，累积到ReceivedBytesThreshold（默认 1）个字节，或者经过一个极短的内部超时，才往线程池投递一次事件。所以在高波特率下，一次事件里BytesToRead可能是 1，也可能是 200，完全取决于调度。

// 典型的事件注册与触发边界 private void OpenPort(SerialConfig cfg) { _port = new SerialPort(cfg.PortName, cfg.BaudRate, cfg.Parity, cfg.DataBits, cfg.StopBits); _port.Handshake = cfg.Handshake; _port.ReadTimeout = 1000; _port.WriteTimeout = 1000; // 阈值设为 1，保证有数据就尽快通知；设大了会人为增加延迟 _port.ReceivedBytesThreshold = 1; _port.DataReceived += OnDataReceived; // 注意：此回调在线程池线程执行 _port.Open(); }

参数说明：ReceivedBytesThreshold设大能减少事件触发次数、降低 CPU 占用，但会增加端到端延迟。做实时性要求高的采集时保持 1；做低频日志抓取时可以调到 64 甚至更大。ReadTimeout只对同步Read/ReadByte生效，用事件模型时它基本是摆设，设了不亏但不解决问题。

3. 十六进制收发的核心链路：从输入框到字节数组的往返

3.1 把 "AA 55 01 0F" 变成 byte[]

用户输入十六进制的方式五花八门：有人敲空格分隔，有人连写AA55010F，有人习惯带0x前缀，从别的工具复制过来还可能夹着逗号或者换行。转换函数要足够宽容，但对非法字符必须明确报错——静默丢掉一个字符，最后发出去的帧就少一个字节，排查起来能耗掉半天。

public static class HexConverter { /// <summary> /// 将十六进制字符串解析为字节数组。 /// 支持 "AA 55 01"、"AA5501"、"0xAA,0x55"、换行等多种写法。 /// </summary> public static byte[] Parse(string input) { if (string.IsNullOrWhiteSpace(input)) return Array.Empty<byte>(); // 1. 统一分隔符：把逗号、分号、制表符、换行都当作空白 var sb = new StringBuilder(input.Length); foreach (char c in input) { if (char.IsWhiteSpace(c) || c == ',' || c == ';' || c == '|') continue; sb.Append(c); } string s = sb.ToString(); // 2. 去掉可能存在的 0x / 0X 前缀（连续写时可能出现多个） s = s.Replace("0x", "", StringComparison.OrdinalIgnoreCase) .Replace("0X", ""); // 3. 长度必须是偶数，奇数说明用户少打或多打了一位 if (s.Length % 2 != 0) throw new FormatException($"十六进制长度为奇数({s.Length})，请检查输入：{input}"); var result = new byte[s.Length / 2]; for (int i = 0; i < result.Length; i++) { string pair = s.Substring(i * 2, 2); // 4. 用 TryParse 而不是 Convert.ToByte，抛出更清晰的错误 if (!byte.TryParse(pair, NumberStyles.HexNumber, CultureInfo.InvariantCulture, out byte b)) throw new FormatException($"非法十六进制字符：\"{pair}\"（第 {i + 1} 个字节）"); result[i] = b; } return result; } /// <summary> /// 字节数组转回带空格的大写十六进制字符串，用于接收区显示。 /// </summary> public static string ToHex(byte[] data, int offset, int count) { var sb = new StringBuilder(count * 3); for (int i = 0; i < count; i++) { sb.Append(data[offset + i].ToString("X2")).Append(' '); } return sb.ToString().TrimEnd(); } }

逻辑上分四步：合并分隔符、剥离前缀、奇偶校验、逐字节转换。第 3 步的奇偶校验是必须的，因为"AA5"这种输入如果不拦，Substring会直接抛ArgumentOutOfRangeException，错误信息对用户毫无意义。第 4 步用byte.TryParse而不是Convert.ToByte，是为了在报错里带上「第几个字节」的定位信息——十六进制串长了以后，人眼数位置很容易错，有下标能省很多时间。

ToHex的offset/count两个参数是为环形缓冲准备的：接收缓冲区可能是固定长度数组循环使用，每次只把有效区间转成字符串，不做整体拷贝。

3.2 发送端为什么必须用 Write(byte[]) 而不是 WriteLine

SerialPort提供了Write(string)、WriteLine(string)、Write(byte[], int, int)三套接口。前两个走Encoding编码，把字符串按默认编码（通常是 ASCII 或工程配置的编码）转成字节。你要发0xAA 0x55，用Write("\xAA\x55")在某些编码下会被转成多字节的 UTF-8 序列，或者被Encoding.ASCII把 0xAA 变成?。血泪经验：十六进制发送一律走字节数组接口，字符串接口只留给真正的文本协议。

/// <summary> /// 发送一帧数据。发送前检查端口状态，避免对已关闭端口写入。 /// </summary> public bool Send(byte[] frame) { if (_port == null || !_port.IsOpen) { RaiseError("串口未打开，发送取消"); return false; } if (frame == null || frame.Length == 0) return false; try { // Write(byte[], int, int) 是同步阻塞的， // 数据量小于发送缓冲区时会立刻返回，不代表已到达对端 _port.Write(frame, 0, frame.Length); AppendLog("TX", frame, frame.Length); return true; } catch (TimeoutException) { RaiseError("发送超时，检查波特率与流控设置"); return false; } catch (IOException ex) { // 拔线、端口被占用、USB 转串口掉驱动都会走到这里 RaiseError("发送失败：" + ex.Message); return false; } catch (InvalidOperationException) { RaiseError("端口已被关闭"); return false; } }

Write同步返回只代表数据进了操作系统和驱动层的发送缓冲区，不代表对面收到了。如果你需要确认对端真的处理了，那得靠应用层的应答帧，串口本身没有这个保证。三个catch分别对应三种现场故障：超时、IO 异常（拔线）、端口状态异常（并发关闭）。把这三类分开报，日志里看一眼就知道是硬件问题还是代码问题。

3.3 接收端：一次 DataReceived 不等于一帧

设备发一帧 20 字节，你的DataReceived可能被触发 1 次、3 次甚至 20 次，也可能两次触发之间夹了两帧。协议层如果按「一次事件 = 一帧」来写，短帧偶尔能跑，长帧必炸。

常见做法是维护一个累积缓冲区，每次事件把BytesToRead读干净追加进去，然后跑一遍帧解析，把完整的帧切出来，剩余的半帧留在缓冲区里等下次。缓冲区用List<byte>还是环形数组看数据量——每秒几十 KB 以内，List<byte>完全够用。

private readonly List<byte> _rxBuffer = new List<byte>(4096); private void OnDataReceived(object sender, SerialDataReceivedEventArgs e) { // 事件可能重入，用锁保护缓冲区 lock (_rxLock) { try { int n = _port.BytesToRead; if (n <= 0) return; byte[] tmp = new byte[n]; int read = _port.Read(tmp, 0, n); // 返回值可能小于 n for (int i = 0; i < read; i++) _rxBuffer.Add(tmp[i]); } catch (Exception ex) { RaiseError("接收异常：" + ex.Message); return; } } // 解析放在锁外，避免长时间持有锁阻塞下一次事件 DispatchBufferedFrames(); }

参数与细节说明：BytesToRead是驱动缓冲区里的字节数，读取前要先判空，否则Read会阻塞到超时。Read的返回值理论上等于n，但保险起见用返回值来循环，避免驱动层出现短读。lock只包住缓冲区操作，解析逻辑放外面——DispatchBufferedFrames里可能要做 UI 更新，持锁期间更新 UI 是典型的死锁温床。

3.4 十六进制显示：为什么要加时间戳和方向

接收区如果只是堆一串不断滚动的十六进制，出问题时你根本分不清哪一段是哪一次交互。把 TX / RX 方向和时间戳带上，日志就从「能看」变成「能用」。

private void AppendLog(string dir, byte[] data, int count) { // HH:mm:ss.fff 精确到毫秒，足够定位串口交互顺序 string line = $"[{DateTime.Now:HH:mm:ss.fff}] {dir} ({count}B) {HexConverter.ToHex(data, 0, count)}"; AppendLineToUi(line); } /// <summary> /// 从累积缓冲区里按协议切帧，没有完整帧就原样保留。 /// 这里以 帧头 AA 55 + 长度字节 为例，实际项目按协议替换。 /// </summary> private void DispatchBufferedFrames() { while (true) { byte[] frame; lock (_rxLock) { // 找帧头 int start = -1; for (int i = 0; i < _rxBuffer.Count - 1; i++) { if (_rxBuffer[i] == 0xAA && _rxBuffer[i + 1] == 0x55) { start = i; break; } } if (start < 0) break; // 没有帧头，等后续数据 if (start > 0) _rxBuffer.RemoveRange(0, start); // 丢弃帧头前的噪声 if (_rxBuffer.Count < 3) break; // 连长度字节都不够 int payloadLen = _rxBuffer[2]; int total = 3 + payloadLen + 1; // 头2 + 长度1 + 载荷 + 校验1 if (_rxBuffer.Count < total) break; // 半包，等 frame = _rxBuffer.GetRange(0, total).ToArray(); _rxBuffer.RemoveRange(0, total); } AppendLog("RX", frame, frame.Length); // 这里可以继续做校验、分发、应答 } }

这段解析的关键是「循环 + break」的结构：每次循环只处理一个完整帧，不完整就break退出，把残余留在缓冲区。丢噪声的方式是找到帧头后把前面的字节整段删掉，而不是逐字节丢——如果一次事件里带了三帧，逐字节丢会退化成 O(n²)。total的算法要看实际协议，3 + payloadLen + 1只是示意，真正做的时候长度字段是否包含帧头、校验位占几字节，都要跟设备文档对一遍。

4. 界面落地：跨线程更新、组帧与日志持久化

4.1 InvokeRequired 的正确用法和闭包陷阱

接收线程要往TextBox或RichTextBox里追加内容，就必须切回 UI 线程。标准写法是判断InvokeRequired后调BeginInvoke。这里有两个坑：一是在BeginInvoke里用 lambda 捕获循环变量或可变引用，投递出去的委托执行时数据已经变了；二是窗体已经 Dispose 但仍有点击事件投递进来，抛ObjectDisposedException。

private void AppendLineToUi(string text) { // 窗体已销毁或句柄未创建时直接丢弃，避免关闭瞬间崩溃 if (IsDisposed || !IsHandleCreated) return; if (InvokeRequired) { // 用 BeginInvoke 异步投递，绝不能用 Invoke： // 同步 Invoke 在串口关闭时可能和 Close() 形成互等死锁 BeginInvoke(new Action<string>(AppendLineToUi), text); return; } // 限制行数，避免 UI 里堆几十万行导致卡死 if (txtLog.Lines.Length > 5000) { txtLog.Clear(); txtLog.AppendText("[日志已清空，保留最近记录]\r\n"); } txtLog.AppendText(text + Environment.NewLine); txtLog.SelectionStart = txtLog.TextLength; txtLog.ScrollToCaret(); }

IsDisposed和IsHandleCreated两道判断顺序不能反：句柄还没创建时IsDisposed仍是 false，但BeginInvoke已经会抛异常。传参用new Action<string>(AppendLineToUi), text而不是 lambda 捕获this之外的变量，是为了让委托带的参数是值拷贝，执行时不会读到更新后的数据。日志条数上限是必须的，TextBox在文本超过几十万字符后追加性能会断崖式下跌，表现出来就是「串口一忙程序就假死」。

4.2 定时组帧：为什么需要「攒够时间再发」

有些设备对命令之间的间隔敏感，连发两条会丢弃第二条。界面上如果支持「多条命令轮询」，就得在发送侧加节流。常见做法是用System.Windows.Forms.Timer或System.Threading.Timer做一个发送队列，按固定间隔滴出一条。

private readonly Queue<byte[]> _txQueue = new Queue<byte[]>(); private readonly System.Windows.Forms.Timer _txTimer = new System.Windows.Forms.Timer(); private void InitSender() { // 50ms 一条，按设备手册调整；太快对方处理不过来，太慢影响效率 _txTimer.Interval = 50; _txTimer.Tick += (s, e) => { lock (_txQueue) { if (_txQueue.Count == 0) return; var frame = _txQueue.Dequeue(); // Timer 的 Tick 本身在 UI 线程，可以安全调 UI AppendLog("TX", frame, frame.Length); try { _port.Write(frame, 0, frame.Length); } catch (Exception ex) { RaiseError("轮询发送失败：" + ex.Message); } } }; _txTimer.Start(); }

Interval的取值依据是设备手册里约定的最小命令间隔，工控设备常见 20~100ms。Timer用 WinForms 版本而不是Threading.Timer，是因为前者回调保证在 UI 线程执行，往TextBox写日志不用再切线程，代码少一层。代价是它精度只有 15ms 左右，对定时要求严格的场景要换成Stopwatch自旋或者高精度定时器——不过串口轮询这种场景，15ms 抖动完全无所谓。

4.3 日志落盘：崩溃现场要靠它复盘

界面上能看到的是实时数据，程序关了或者崩了就没痕迹了。加一个按天滚动的文本日志，出问题时至少能回溯。不需要上日志框架，StreamWriter够用。

private readonly object _logLock = new object(); private void WriteFileLog(string line) { try { lock (_logLock) { string dir = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "logs"); Directory.CreateDirectory(dir); // 按天切分，避免单文件无限增长 string path = Path.Combine(dir, $"{DateTime.Now:yyyyMMdd}.log"); File.AppendAllText(path, line + Environment.NewLine, Encoding.UTF8); } } catch { // 日志写失败绝不能影响主流程，这里吞掉异常是合理的 } }

AppDomain.CurrentDomain.BaseDirectory比Environment.CurrentDirectory可靠，后者会被「打开文件对话框」之类的操作悄悄改掉，导致日志写到莫名其妙的目录。用File.AppendAllText每次重开文件句柄，性能一般但胜在不会出现「文件被占用删不掉」的尴尬，串口工具日志量不大，这么写完全扛得住。

5. 避坑排查：串口程序最容易翻车的几个地方

5.1 现象：打开串口报「拒绝访问」，重装程序也没用

原因：上一次运行的进程没退干净，端口句柄还挂在那里；或者另一个串口助手正开着同一个端口。Windows 对 COM 口是独占的，第二个进程Open()直接抛UnauthorizedAccessException。

解决：先在设备管理器里看端口是否还在，再用任务管理器找残留进程。代码层面要保证Open()失败时不留下半开的对象，try/catch里调Dispose()，别指望 GC。

public bool TryOpen(SerialConfig cfg, out string error) { error = null; try { _port = new SerialPort(cfg.PortName, cfg.BaudRate, cfg.Parity, cfg.DataBits, cfg.StopBits); _port.Open(); _port.DataReceived += OnDataReceived; return true; } catch (UnauthorizedAccessException) { error = $"{cfg.PortName} 被占用，检查是否已有其他程序打开"; } catch (IOException ex) { error = $"端口不存在或驱动异常：{ex.Message}"; } catch (ArgumentException ex) { error = $"端口名非法：{ex.Message}"; } _port?.Dispose(); // 关键：失败路径也要释放 _port = null; return false; }

5.2 现象：拔掉 USB 转串口线，程序直接闪退

原因：DataReceived回调里抛出的异常没人接。事件是在线程池线程上触发的，异常逃出去会直接把进程干掉，连Application.ThreadException都拦不住。

解决：OnDataReceived整个函数体包try/catch，任何异常都转成界面提示。同时监听ErrorReceived事件，驱动的错误码从那里出来。

5.3 现象：点关闭窗口后程序卡住，进程残留

原因：DataReceived里用了同步Invoke更新 UI，而 UI 线程此刻正在执行SerialPort.Close()。Close()内部会等待事件处理线程结束，事件线程又在等 UI 线程返回，互等。这是这个领域最经典的死锁，没有之一。

解决：更新 UI 一律BeginInvoke；关闭时先把标志位置为「停止接收」，解绑DataReceived，Thread.Sleep(50)给在途回调一点时间，再Close()和Dispose()。

private volatile bool _closing = false; private void FormClosing_(object sender, FormClosingEventArgs e) { _closing = true; if (_port != null) { _port.DataReceived -= OnDataReceived; // 先解绑 if (_port.IsOpen) { try { _port.DiscardInBuffer(); _port.DiscardOutBuffer(); } catch { } Thread.Sleep(50); // 给在途回调让路 _port.Close(); } _port.Dispose(); _port = null; } }

回调开头加一句if (_closing) return;，双保险。

5.4 现象：接收区显示的中文全是乱码

原因：用了十六进制模式却混进了文本解析，或者文本模式下Encoding选错。设备发的是 GBK 中文，程序用 UTF-8 解，必乱。

解决：十六进制和文本两种显示模式在界面上互斥，别混着来。文本模式下提供编码下拉框（UTF-8 / GBK），让用户自己选。判断依据很简单：收到的字节能被Encoding.GetEncoding("GBK").GetString()解成可读中文，就是 GBK。

5.5 现象：115200 以上波特率时丢数据

原因：DataReceived里做了耗时操作（写文件、复杂解析、Thread.Sleep），事件处理线程被占住，驱动缓冲区溢出。另一种可能是ReceivedBytesThreshold设得太大，人为把事件压后。

解决：事件回调里只做「读出来塞进缓冲区」这一件事，解析和落盘放到单独线程。给_rxBuffer设一个上限（比如 1MB），超了就丢最老的数据并记一条告警，别让内存无限涨。

6. 二次开发：从调试工具到协议采集端

拿到这套源码，多数人不会停在「能发能收」这一步，最终目标是接上具体协议、自动应答、把数据存下来。改造顺序我一般这么排：先把HexConverter和FrameParser剥出来补单元测试，再在FrameParser里把帧格式参数化，最后把「收到帧之后干什么」抽成一个接口。

帧格式参数化最直接的做法是抽一个配置类，把帧头、长度字段位置、校验方式做成数据。这样换一个设备只需要改配置，不用改代码。

校验这一块单独说。累加和几行代码就够，CRC16 建议直接查表，别在接收回调里跑逐位算法——115200 下每帧都算一遍，CPU 占用看得见。

public interface IChecksum { byte Compute(byte[] data, int offset, int count); int Length { get; } // 校验字段占几个字节，解析时要用 } public sealed class Sum8Checksum : IChecksum { public int Length => 1; public byte Compute(byte[] data, int offset, int count) { int sum = 0; for (int i = 0; i < count; i++) sum += data[offset + i]; return (byte)(sum & 0xFF); // 只取低 8 位 } }

改完之后验证方法很简单：拿一台设备或者一个虚拟串口对（成对的两个虚拟 COM 口互连），用脚本按协议造帧灌进去，看解析结果和统计量。别指望人工点界面验证，那个覆盖率太低。虚拟串口对还有个好处，可以把 5.5 那条高波特率丢数据的场景复现出来。

再往后就是把它做成采集端的形态：界面最小化到托盘、配置存 JSON、数据写 SQLite 或 CSV、加个「自动应答」规则表。到这一步，最初的收发代码只占整个工程的百分之几，但没有那一层把字节流跑通、把线程边界划清，后面全是空中楼阁。

我踩过最狠的一次是给客户现场的工具加了日志落盘，没做失败兜底，结果磁盘满的时候整个接收线程被IOException带崩，界面还在，数据全停，现场排查了两个小时才发现是日志目录写在了一个只剩几十兆的分区上。从那以后我每次给串口工具加任何「附带功能」，不管是日志、数据库还是上报，都强制走一遍「把它干掉会发生什么」的路径测试——拔盘、断网、磁盘满、权限不足，四种情况挨个试一遍。串口程序的主链路太脆弱，任何旁路功能都不配拥有让主链路崩溃的资格。

这套代码的价值不在于它现在能干什么，而在于它把该暴露的边界都暴露出来了：字节和字符串的边界、UI 线程和 IO 线程的边界、一次事件和一帧数据的边界。把这三条边界守住了，往上叠什么协议都不虚。源码已经整理好，按第 2 章的目录结构对一遍，先把Core里的两个类单独跑通，再回来看窗体代码，会顺很多。希望帮到你。

本文还有配套的精品资源，点击获取