UDP服务端需用net.ListenUDP监听，调用SetReadDeadline设超时，ReadFromUDP读取并用addr回复；客户端用net.DialUDP发请求后Read收响应；缓冲区应设65536防截断。
UDP服务端如何正确监听并读取数据
Go 的 net.ListenUDP 返回的 *UDPConn 是阻塞式连接，调用 ReadFromUDP 会一直等待直到收到数据包。如果没做超时控制，程序可能卡死在读取阶段。
- 必须显式设置读超时：调用
conn.SetReadDeadline，传入time.Now().Add(5 * time.Second)这类相对时间 -
ReadFromUDP返回的addr是对端地址（含 IP 和端口），可用于后续单播回复；不要直接用conn.RemoteAddr()—— UDP 连接本身无“远程地址”概念，该方法返回 nil - 缓冲区大小建议设为 65536（即最大 IPv4 UDP 包长），避免截断：用
make([]byte, 65536)
conn, _ := net.ListenUDP("udp", &net.UDPAddr{Port: 8080})
defer conn.Close()
buf := make([]byte, 65536)
for {
n, addr, err := conn.ReadFromUDP(buf)
if err != nil {
if netErr, ok := err.(net.Error); ok && netErr.Timeout() {
continue // 超时，继续下一轮
}
log.Println("read error:", err)
continue
}
log.Printf("received %d bytes from %v: %s", n, addr, string(buf[:n]))
}UDP客户端如何发送并接收响应
UDP 是无连接协议，客户端无需“建立连接”，但要发请求 + 等响应，需自己管理对端地址和读取逻辑。常见错误是只调用 WriteToUDP 就结束，没预留时间收回复。
- 使用
net.DialUDP可复用同一本地端口、自动绑定，并获得带目标地址的连接句柄，比反复WriteToUDP更可控 - 发送后立即调用
Read（不是ReadFromUDP），因为DialUDP返回的连接已关联远端地址，Read会只收该地址发来的包 - 仍需设读超时，否则对方不响应时会永久阻塞
addr := &net.UDPAddr{IP: net.ParseIP("127.0.0.1"), Port: 8080}
conn, _ := net.DialUDP("udp", nil, addr)
defer conn.Close()
conn.SetReadDeadline(time.Now().Add(3 * time.Second))
_, _ = conn.Write([]byte("ping"))
buf := make([]byte, 1024)
n, _ := conn.Read(buf)
log.Printf("got response: %s", string(buf[:n]))为什么 ReadFromUDP 有时读不到完整包
根本原因是缓冲区太小 —— UDP 包超过缓冲长度时，多余字节被丢弃，且 ReadFromUDP 仍返回 n == len(buf)，不会报错或提示截断。
- 检查
n是否等于len(buf)：若相等，极可能被截断（除非对方真发了那么大包） - IPv4 UDP 最大理论载荷是 65507 字节（65535 - 8 UDP header - 20 IP header），实际应用中极少超过 1500（MTU 限制）
- 不要依赖
len(buf)判断是否收完——UDP 本就是消息边界完整的协议，一次ReadFromUDP对应一个完整 UDP 数据报
UDP通信中地址复用与端口冲突问题
多个进程监听同一 UDP 端口默认失败，但可通过 SetReuseAddr(true) 允许 SO_REUSEADDR，常用于快速重启服务或负载分发场景。
立即学习“go语言免费学习笔记（深入）”；
- 调用时机必须在
ListenUDP之前：先net.ListenUDP得到*UDPConn，再对其调用SetReadBuffer/SetWriteBuffer/SetReuseAddr -
SetReuseAddr在 Linux/macOS 上有效，在 Windows 上部分版本需配合SetReusePort（Go 1.11+ 支持） - 注意：启用复用后，内核将随机把入包分发给任一监听该端口的进程，不适合有状态的单实例服务
真正容易被忽略的是：UDP 没有连接状态，所以没有 TIME_WAIT，但也没有 ACK 重传机制。发出去的包丢了，你根本不知道。
