夏令时时钟回拨导致NetworkStream.ReadTimeout失效问题问询

我来聊聊这个棘手的场景——这大概率和.NET底层处理超时的逻辑有关，甚至可能是个未被完全覆盖的边缘Case，先给你拆解下：

问题本质 #

当夏令时触发时钟回拨（比如伦敦时区从夏令时切回冬令时，时钟往回跳1小时），NetworkStream的ReadTimeout属性会完全失效，导致代码陷入空转循环。核心原因在于：
.NET的IO超时机制大多依赖系统时钟来计算到期时间——它会先记录「当前系统时间 + 超时时长」作为到期戳，每次读取操作时检查当前时间是否超过这个戳。但时钟回拨后，这个到期戳会突然比当前时间晚了整整1小时（原本只剩10秒到期，回拨后变成还有59分50秒），Read操作会一直认为还没到超时时间，反复尝试读取，最终空转。

是不是.NET的Bug？ #

这得从设计角度看：.NET的超时逻辑默认假设系统时钟是单调递增的，而夏令时回拨属于系统时钟突变的极端场景。如果微软官方文档没有明确说明这种场景下的预期行为，那这更像是一个「未被覆盖的边缘场景」，或者说设计上的局限（毕竟处理时钟回拨会大幅增加超时逻辑的复杂度）。你完全可以把它看作是一个需要修复的Bug，因为用户设置了超时就应该得到预期的超时行为，不管时钟怎么变。

临时解决方案 #

你可以绕过.NET自带的超时机制，自己用单调时钟（比如Stopwatch）来控制超时，因为Stopwatch依赖的是硬件计时器，不受系统时钟变化影响。示例代码如下：

var readStopwatch = Stopwatch.StartNew();
const int ReadTimeoutMs = 3000; // 自定义3秒超时
byte[] buffer = new byte[1024];
NetworkStream stream = /* 你的NetworkStream实例 */;

while (true)
{
    // 用Stopwatch检查是否超时
    if (readStopwatch.ElapsedMilliseconds > ReadTimeoutMs)
    {
        throw new TimeoutException("读取操作超时");
    }

    try
    {
        // 设置一个很短的ReadTimeout，避免长时间阻塞
        stream.ReadTimeout = 100;
        int bytesRead = stream.Read(buffer, 0, buffer.Length);
        
        if (bytesRead > 0)
        {
            // 处理读取到的数据
            break;
        }
    }
    catch (IOException ex) when (ex.InnerException is TimeoutException)
    {
        // 忽略短超时异常，继续检查总时长
        continue;
    }
}

这个思路是用Stopwatch记录总耗时，给Read设置一个很短的超时，每次读取后检查总耗时是否超过阈值，这样就算系统时钟回拨，也不会影响Stopwatch的计时。

后续建议 #

你可以去dotnet/runtime的GitHub仓库提交Issue，详细描述复现步骤（时区设置、夏令时切换时机、代码示例），让官方团队确认这是否属于需要修复的Bug。毕竟这种边缘场景虽然少见，但确实影响了代码的可靠性。

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