UDP ReadFrom 不返回时的 deadline 设置方式

UDP 接收代码里，ReadFrom“一直不返回”通常不是方法失效，而是连接正在等待下一个数据报。要给这段等待加上边界，应在读取前调用 UDPConn.SetReadDeadline(time.Now().Add(timeout))。它设置的是绝对时间点，会同时约束当前已经阻塞的读取；超时后用 errors.Is(err, os.ErrDeadlineExceeded) 识别，再决定继续等待、退出 worker，还是记录真正的网络错误。

下面只讨论 Go net 包的 UDP 接收循环：如何放置 deadline、什么时候刷新，以及如何把超时从普通故障中分离出来。

UDP ReadFrom 为什么看起来一直不返回

net.PacketConn.ReadFrom 的职责是等待数据并返回字节数、来源地址和错误。没有数据报时，它自然会阻塞；如果代码既没有设置读取 deadline，也没有通过关闭连接结束等待，调用方就看不到下一行日志。

这里要先分清两个概念：ReadFrom 负责取数据，SetReadDeadline 负责给读操作设置时间上限。后者不是“等待多少秒”的相对计时器，而是一个绝对的 time.Time。零值时间表示不设置读取超时。

先给 UDPConn 配置读取时间边界

最小写法是在每次进入读取阶段前设置 deadline。下面的示例绑定本地 UDP 端口，等待 3 秒；没有数据时，ReadFromUDP 会返回可识别的超时错误。

package main

import (
    "errors"
    "fmt"
    "net"
    "os"
    "time"
)

func main() {
    // 绑定本地 UDP 地址，端口 0 交给系统选择可用端口。
    conn, err := net.ListenUDP("udp", &net.UDPAddr{IP: net.IPv4zero, Port: 0})
    if err != nil {
        panic(err)
    }
    defer conn.Close() // 退出时释放底层 socket。

    buf := make([]byte, 2048)
    // deadline 是绝对时间点，限制这一次阻塞读取最多等待 3 秒。
    if err := conn.SetReadDeadline(time.Now().Add(3 * time.Second)); err != nil {
        panic(err)
    }

    n, addr, err := conn.ReadFromUDP(buf)
    switch {
    case err == nil:
        fmt.Printf("收到 %d 字节，来源 %s\n", n, addr)
    case errors.Is(err, os.ErrDeadlineExceeded):
        fmt.Println("3 秒内没有收到 UDP 数据")
    default:
        fmt.Printf("UDP 读取失败：%v\n", err)
    }
}

关键位置是 ReadFromUDP 之前，而不是收到数据之后才第一次设置。只要 deadline 已经过去，后续读也会立即失败；想恢复等待，必须把它刷新到未来的时间点。

把 deadline 放在接收循环的阶段入口

实际 worker 往往不是只收一个包，而是持续等待。此时常见的选择有三种：每轮固定等待一个窗口、每次成功收包后刷新空闲窗口，或者为整个 worker 设置一个最终截止时间。不要把它们混成一个“超时参数”。

func receiveLoop(conn *net.UDPConn, stop 

如果需求是“连续 5 秒没有任何数据就退出”，可以在成功收包后刷新 deadline，并在超时时返回；如果需求是“每轮最多等 5 秒但 worker 永远运行”，就像示例一样在超时后继续。选择哪种方式，取决于超时代表空闲状态还是生命周期结束。

超时与真实网络错误要分开处理

ReadFromUDP 返回的 n、addr、err 是一个契约。不要只写 if err != nil { return err }，否则正常空闲会被当成故障；也不要把所有实现了 Timeout() 的错误都吞掉，因为超时接口并不等于这次一定由 deadline 触发。

推荐的判断顺序是：先用 errors.Is(err, os.ErrDeadlineExceeded) 识别 deadline；再根据 worker 的关闭约定识别连接关闭；剩余错误按真实网络故障记录并返回。若底层库包装了错误，errors.Is 仍比直接比较字符串稳妥。

func classifyReadError(err error) string {
    // deadline 是可恢复的空闲状态，交给上层决定是否继续等待。
    if errors.Is(err, os.ErrDeadlineExceeded) {
        return "idle-timeout"
    }
    // 其它错误不能靠错误文本猜测，保留原始错误供日志和重试策略使用。
    if err != nil {
        return "network-error"
    }
    return "ok"
}

把读取边界接入自动恢复与通知

当 UDP 接收逻辑放进后台 worker，deadline 的价值不只是“让函数返回”。它还提供了一个稳定的调度门：空闲超时可以更新心跳或检查停止信号，连接关闭可以正常退出，非超时错误才触发告警或重建 socket。

可以按下面的表格组织动作：

最后检查三个容易忽略的边界：第一，SetDeadline 会同时影响读和写，接收服务通常更适合使用 SetReadDeadline；第二，deadline 是绝对时间，循环里要重新计算 time.Now().Add(...)；第三，关闭连接也会唤醒阻塞的读取，所以停止流程应明确由谁负责 Close，不要只依赖超时轮询。

常见问题

为什么设置了一次 deadline，后面的读取都立即超时？

因为 deadline 是绝对时间，不会在每次成功读取后自动延长。持续接收时，应在下一次 ReadFrom 前把它设置到新的未来时间点。

应该用 SetDeadline 还是 SetReadDeadline？

只需要限制 UDP 接收时优先用 SetReadDeadline；只有读写都需要同一个截止时间时，才使用 SetDeadline。

能不能只通过 Timeout 方法判断超时？

不建议。优先用 errors.Is(err, os.ErrDeadlineExceeded) 识别 deadline，再把其它错误交给连接生命周期和重试策略处理。

总结

UDP ReadFrom 没有数据时阻塞是正常语义，解决方式是给连接设置读取 deadline，而不是在读取函数外部猜测等待状态。把 SetReadDeadline 放在每轮读取入口，按业务选择刷新或退出，再用 errors.Is 区分空闲超时与真实错误，就能让 UDP worker 的等待、恢复和告警边界保持一致。