C#串口写入无法实现正确时序 偶发多包数据集中突发发送问题

• 问题和物理硬件、kernel32.dll的代码bug无关，本质是Windows串口栈默认面向吞吐量优先设计，根本没考虑毫秒级精准时序需求，才会出现随机攒包批量发送的现象。
• Windows内核确实会对串口传输引入随机延迟，核心来源有三个：
  • 内核态串口驱动默认配置4KB级别的大发送缓冲区，默认开启攒批逻辑：当写入数据量没到阈值、或者驱动调度被抢占时，不会立刻把字节下发到串口控制器，会暂存在内核缓冲里等待批量发送，攒包延迟完全随机，和系统负载正相关。
  • Windows客户端版本默认线程时间片是10_{15ms，哪怕你的多媒体定时器精度达标，只要执行串口写入的线程被更高优先级任务抢占、没拿到CPU时间片，几次定时器触发的写入请求就会排队在内核缓冲区，等线程恢复运行时被批量下发——你观测到3}4条报文挤在一起（3*5ms=15ms），刚好和默认时间片长度完全吻合。
  • 你之前调用的port.BaseStream.Flush()完全没有强制排空内核缓冲的作用：该方法仅会把.NET托管层、用户态的缓存数据提交给Win32写入接口，不会等待内核驱动、串口硬件完成实际发送，调用返回时数据大概率还在内核缓冲区里。com0com虚拟串口场景下问题复现，也刚好验证了问题和物理硬件无关，是内核串口栈的通用逻辑。

按优先级依次实现，即可把发送间隔抖动控制在1ms以内：

1. 关闭内核攒批、缩小发送缓冲区
   打开串口后，通过P/Invoke直接修改串口内核参数，不要用.NET SerialPort的默认配置：
   • 调用SetupComm把串口的内核发送缓冲区大小设为单次发送长度的2倍（你单次发20字节就设为40），避免大缓冲攒包；
   • 配置COMMTIMEOUTS结构，将写超时相关参数全部设为0，关闭驱动的写等待逻辑；
   • 每次写入前调用PurgeComm清空残留的发送缓冲。
2. 替换无效的Flush，实现真实的发送完成等待
   每次同步调用port.Write()之后，不要调用自带的Flush，而是通过P/Invoke循环查询内核发送队列长度，直到队列为空才返回，参考代码：

   [DllImport("kernel32.dll", SetLastError = true)]
   private static extern bool ClearCommError(IntPtr hFile, out uint lpErrors, out COMSTAT lpStat);
   
   [StructLayout(LayoutKind.Sequential)]
   private struct COMSTAT {
       public uint fCtsHold : 1;
       public uint fDsrHold : 1;
       public uint fRlsdHold : 1;
       public uint fXoffHold : 1;
       public uint fXoffSent : 1;
       public uint fEof : 1;
       public uint fTxim : 1;
       public uint fReserved : 25;
       public uint cbInQue;
       public uint cbOutQue;
   }
   
   private void WaitForSendComplete(SerialPort port) {
       COMSTAT stat;
       uint errors;
       do {
           ClearCommError(port.BaseStream.Handle, out errors, out stat);
           Thread.SpinWait(10); // 短自旋等待，不要加长Sleep避免额外延迟
       } while (stat.cbOutQue > 0);
   }
   

3. 提升发送线程优先级，避免调度抢占
   • 调用多媒体定时器前先执行timeBeginPeriod(1)把系统全局定时器分辨率设为1ms；
   • 把执行串口写入的线程优先级设为THREAD_PRIORITY_TIME_CRITICAL（实时级），不要用线程池线程、不要用异步BeginWrite（异步写会走线程池调度，延迟不可控），整个写入+等待发送完成的逻辑直接在高优先级定时器回调里执行；
   • 关闭串口的所有硬件/软件流控，把流控模式设为None，避免流控信号导致的缓冲阻塞。

你之前测试的异步写入方案完全不适合高精度时序场景：BeginWrite会把写入请求排队到.NET线程池，线程池的工作项调度本身就存在1~10ms级别的随机延迟，会进一步放大发送间隔抖动。

内容的提问来源于stack exchange，提问作者Not Really a Master