串口读取传感器数据常出乱码，主因是波特率、数据位、停止位、校验位等参数未与硬件完全一致，且GND未共地或TX/RX反接。
直接读串口或走 Modbus TCP 是最常用、最稳的两种方式，其他方案要先看设备手册支持什么协议，别一上来就写 TcpClient。
串口读取传感器数据（SerialPort）为什么常出乱码？
乱码不是代码写错了，八成是参数没对齐。DHT22、SHT30、自研 STM32 模块都可能用串口，但波特率、停止位、校验位必须和硬件完全一致。
-
BaudRate常见值有 9600、115200，查传感器文档确认，别猜 -
Parity多数是Parity.None，但有些工业模块要求Parity.Even -
DataBits=8和StopBits.One是默认，但某些老设备要StopBits.Two - 接线时 GND 必须共地，TX/RX 别反接——这是烧板子前最后的警告
示例中用 ReadExisting() 看似简单，但实际项目里建议改用 ReadLine() 或带缓冲区的 Read()，否则遇到无换行符的二进制帧会粘包。
Modbus TCP 读寄存器总超时？先检查这三件事
超时不是 C# 代码问题，而是网络层或设备配置卡住了。
- 设备 IP 和端口（默认
502）必须能从 PCping通，且防火墙放行该端口 - 站号（
Station）必须和设备设置一致，常见是1，但有些网关设为255 - 寄存器地址从 0 还是 1 开始？
ReadHoldingRegisters(0, 10)读的是地址 40001–40010，但设备手册常标“40001 起”，得换算
用 ModbusPoll 先连上设备验证读写，再贴 C# 代码。别跳过这步——70% 的“连不上”问题在 ModbusPoll 里就能暴露。
用 HSLCommunication 库省事，但别忽略异常捕获点
HSL 的 ModbusTcpNet 封装确实干净，但它的 ConnectServer() 和 ReadHoldingRegisters() 返回的是 OperateResult<ushort></ushort>，不是原生 bool 或数组。
- 必须检查
IsSuccess == false，否则直接解包会抛NullReferenceException -
Message字段里常含关键线索，比如 “Connection refused” 是端口错，“No response” 是站号或地址错 - 生产环境务必加重试逻辑，单次失败就停采？工业现场网络抖动太常见
别把 modbus.ConnectServer() 放在 Main() 开头就完事，它应该包裹在定时重连或连接状态管理里。
USB/蓝牙/WiFi 传感器看似方便，实则解析成本最高
这类设备对外暴露的往往不是标准协议，而是厂商私有格式。你拿到的可能是一串 JSON、一段十六进制字节，或带帧头帧尾的二进制流。
- USB 设备多数映射为虚拟串口（VCOM），仍走
SerialPort，但协议解析要自己写 - 蓝牙需用
BluetoothClient或第三方库（如 32feet.NET），配对、服务发现、特征读取步骤多，Win11 对经典蓝牙支持反而变弱 - WiFi 传感器若提供 HTTP 接口，用
HttpClient最简单；但若走 UDP 或自定义 TCP 协议，就得手动处理粘包、心跳、断线重连
真正省事的从来不是通信方式，而是设备是否公开完整协议文档。没文档的 WiFi 传感器，比 Modbus RTU 更难搞定。
