VB串口读取条码DataReceived事件重复扫描数据拆分问题咨询

核心问题出在.NET SerialPort的DataReceived事件设计逻辑上：这个事件根本不会判断业务层面的“完整一条数据”有没有传完，它的触发规则只和串口内核驱动的接收缓冲区挂钩——只要缓冲区收到了字节、达到驱动设置的最小触发阈值，就会从线程池拉个线程触发事件，和整条条码有没有发完没有任何关联。

两种代码表现差异的具体原因 #

不加休眠的代码为什么会随机截断 #

• 串口是逐字节传输数据的，拿最常用的9600波特率、8N1参数算，传一个字节就要1ms左右，测试用的14位条码从头到尾传完至少要14ms。
• 第二次扫描时，缓冲区刚收到前8、9个字节，就够到事件触发门槛了，DataReceived直接执行。这时候调用ReadExisting()，这个方法不会等待后续字节到达，上来就把当前缓冲区里存着的所有字节全读走，自然只能拿到半截数据。
• 剩下还在传输链路、芯片缓存里没进到SerialPort接收缓冲区的后半段条码，等全部到齐之后会再触发一次DataReceived，就输出了剩下的半截内容。截断位置不固定的原因也很简单：完全取决于调用ReadExisting那个瞬间硬件刚好收了多少字节，系统线程调度、串口中断优先级出现波动，截断位置就会变化，没有固定规律。
• 第一次扫描能输出完整结果只是概率巧合，连续测试几十次，第一次扫描同样会出现截断问题。

加1ms休眠的代码为什么看起来正常 #

加的那行Threading.Thread.Sleep(1)本质是硬等1ms，给硬件留了点时间把剩下的字节传到缓冲区。等休眠结束再读的时候，刚好14个字节全部进入缓冲区，自然能一次读全。

注意：这种写法纯靠碰运气，生产环境绝对不能用。要是换了更低的波特率、扫描更长的条码、或者系统当时出现线程调度卡顿，1ms根本等不到所有数据到齐，该截断还是会截断，出问题都很难复现。

可靠的实现方案 #

别靠加固定延时赌数据到齐，在应用层做缓存和帧边界判断就能彻底解决问题，逻辑非常简单：

• 定义一个类级别的全局缓存（字符串或者字节数组都行），专门存储每次DataReceived触发时读到的零散数据
• 确认条码枪的配置规则，绝大多数扫码枪扫完码都会自动加后缀作为结束标记，最常见的是回车\r或者回车换行\r\n
• 每次DataReceived触发时，先把这次读到的内容全部追加到全局缓存末尾，再检查缓存里有没有约定好的帧尾标记
• 如果检测到帧尾，就把帧尾前面的内容提取出来作为一条完整条码处理，剩下没凑够一帧的内容留在缓存里，等下次事件触发时继续拼接

内容的提问来源于stack exchange，提问作者user17611369