SerialPort已打开，但读取BytesToRead属性时抛出NullReferenceException

我来帮你拆解这个棘手的问题——你已经确认SerialPort实例不为null，而且IsOpen返回true，但访问BytesToRead时却抛出了NullReferenceException，异常栈还指向了WinSerialStream.get_BytesToRead()。这种情况其实是.NET SerialPort类的一个常见“坑”，背后的原因和它的内部实现脱不了干系。

核心原因分析 #

SerialPort类底层依赖一个WinSerialStream对象处理实际的串口IO操作。虽然你看到IsOpen是true，但这个内部的WinSerialStream实例可能已经被意外销毁或置为null了，常见场景包括：

• 其他线程在你访问BytesToRead的同时，调用了Close()或Dispose()，直接干掉了内部流
• 串口硬件意外断开、故障，导致系统回收了底层流，但SerialPort的IsOpen状态还没来得及更新
• 多线程异步操作中，串口的内部状态出现了不一致，导致标识位和实际流状态脱节

可行的解决方案 #

针对这个问题，你可以试试下面几种实用的解决方法：

• 给串口操作加线程安全锁：如果你的代码是多线程环境，一定要给所有SerialPort相关操作加锁，确保访问BytesToRead、读写数据、关闭串口这些动作不会并发执行。示例代码：

  private readonly object _serialPortLock = new object();
  
  // 安全读取BytesToRead的方法
  int GetSafeBytesToRead()
  {
      lock (_serialPortLock)
      {
          if (_serialPort != null && _serialPort.IsOpen)
          {
              try
              {
                  return _serialPort.BytesToRead;
              }
              catch (NullReferenceException)
              {
                  // 内部流已失效，重新初始化串口
                  ReinitializeSerialPort();
                  return 0;
              }
          }
          return 0;
      }
  }
  

• 捕获异常并重新初始化串口：当捕获到这个特定的NullReferenceException时，说明内部流已经彻底不可用了。此时应该先尝试安全关闭当前SerialPort实例，然后重新创建并打开串口连接。

• 统一串口操作的线程上下文（桌面应用）：如果是WPF或WinForms应用，尽量让所有串口操作在同一个线程执行——如果SerialPort是在UI线程创建的，跨线程操作时记得用Invoke/BeginInvoke切换到UI线程，避免状态不一致。

额外注意事项 #

• 别迷信IsOpen的返回值：它只是SerialPort类维护的一个标识位，和底层流的实际状态可能不同步，所以永远要做好异常处理。
• 关闭串口时要彻底：确保所有读写操作都完成后再调用Close()/Dispose()，避免残留线程访问已销毁的内部流。

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