SerialPort 类需严格配置参数、管理资源和线程安全。PortName、BaudRate等必须构造或Open前设全，Parity等须与设备一致；ReadTimeout/WriteTimeout必设；DataReceived中禁用ReadLine()，改用ReadExisting()解析；ReadByte()返回int需判-1；Close后需DiscardBuffer并try/catch异常；重连需实测验证端口可用性。
SerialPort 类不是“配好参数就能跑通”的玩具，它对配置一致性、资源生命周期和线程安全极度敏感。多数通信失败不是代码写错了，而是端口状态没判准、超时没设、事件里乱读缓冲区。
SerialPort 构造与参数必须一次性配齐
不能先 new 再逐个赋值——PortName 和 BaudRate 必须在构造时或 Open() 前全部设好，否则调用 Open() 会抛 InvalidOperationException。尤其注意：Parity、DataBits、StopBits 这三项若与设备不一致，大概率收不到有效数据，且无明确报错。
-
PortName要严格匹配系统识别名（Windows 是"COM3"，Linux 是"/dev/ttyUSB0"），大小写敏感 -
BaudRate必须与硬件固件设定完全相同，115200 和 115200.0 不等价，整数即可 - 推荐显式设置
Handshake = Handshake.None，避免默认值引发意外流控行为 - 务必设置
ReadTimeout和WriteTimeout（如500），否则ReadLine()或Write()可能永久阻塞
DataReceived 事件里不能直接调用 ReadLine()
DataReceived 是由串口驱动在后台线程触发的，而 ReadLine() 依赖换行符（\r\n 或 \n）做边界判断。如果设备发的是二进制帧或无规律分隔符，ReadLine() 会一直等、超时、丢数据，甚至把多帧粘成一行。
- 改用
ReadExisting()拿到当前所有缓存字节，再按协议解析（比如找帧头0x55 0xAA） - 若必须用文本协议，确保设备端每条消息末尾都发送
\n，且ReceivedBytesThreshold = 1（默认是 1，但显式设更稳妥） - 事件处理函数内避免耗时操作（如 UI 更新、文件写入），应转到主线程或队列中处理
ReadByte() 和 Read() 的缓冲区陷阱
ReadByte() 看似简单，但它返回 int，读到末尾时返回 -1，不是 byte；而 Read(byte[], int, int) 返回实际读取长度，可能小于请求长度——这两者混用极易导致逻辑错乱或死循环。
- 不要在 while 循环里无条件调
ReadByte()：它可能阻塞、超时、或返回 -1，需检查返回值 - 用
BytesToRead判断有无数据可读，但注意：该值反映的是 SerialPort 缓冲区字节数，不是底层BaseStream的可用字节数，二者不一致是正常现象 - 大块数据传输前，建议调大缓冲区：
ReadBufferSize = 2 * 1024 * 1024，否则高频小包可能溢出丢帧
端口关闭与异常恢复必须手动兜底
Close() 不等于资源释放完毕，未处理的异步读写可能仍在后台运行；而设备热拔插、驱动崩溃、权限丢失等场景下，IsOpen 可能仍为 true，但后续任何操作都会抛异常。
- 关闭前务必调
DiscardInBuffer()和DiscardOutBuffer()清空残留数据 - 每次读写都套
try/catch，捕获IOException、UnauthorizedAccessException、TimeoutException - 重连逻辑不能只靠
GetPortNames()，要对每个候选端口尝试new SerialPort(name).Open()+Close()验证可用性
真正难的从来不是“怎么发一个字节”，而是设备掉线后 3 秒内自动重连、连续 10 小时不丢帧、不同厂家传感器共用同一套收发逻辑——这些都卡在参数校验、缓冲区管理、异常分支覆盖上，而不是语法本身。
