UDP客户端用net.DialUDP复用连接收发，需解析目标地址、设读超时、处理无响应；服务端用net.ListenUDP监听，每包启goroutine并发处理；跨机丢包主因防火墙或绑定127.0.0.1；需按最大包长分配缓冲区并自行定义消息边界。
UDP客户端如何发送并接收响应
Go 的 net.DialUDP 可以复用同一个连接收发，但要注意它默认不支持广播，且必须指定目标地址。常见错误是调用 WriteToUDP 时传入了 nil 地址，导致 panic：「write: invalid argument」。
实操建议：
- 先用
net.ResolveUDPAddr解析目标地址，避免手动拼接"127.0.0.1:8080"字符串出错 - 客户端应设置读超时（
SetReadDeadline），否则ReadFromUDP会永久阻塞 - 不要假设服务端一定回复——UDP 无连接、不可靠，需设计重试或超时逻辑
conn, _ := net.DialUDP("udp", nil, &net.UDPAddr{IP: net.IPv4(127, 0, 0, 1), Port: 8080})
defer conn.Close()
conn.SetReadDeadline(time.Now().Add(2 * time.Second))
conn.Write([]byte("hello"))
buf := make([]byte, 1024)
n, addr, _ := conn.ReadFromUDP(buf)
fmt.Printf("received %s from %v\n", string(buf[:n]), addr)UDP服务端如何正确监听并处理并发请求
用 net.ListenUDP 启动的服务端本身是单 goroutine 的，ReadFromUDP 是阻塞调用。若在主 goroutine 中循环读取，就无法同时处理多个请求——这不是 TCP，没有 accept 概念，但也不意味着天然并发。
关键点：
立即学习“go语言免费学习笔记（深入）”；
- 每个收到的包都应起独立 goroutine 处理，否则后续
ReadFromUDP被卡住 - 务必检查
ReadFromUDP返回的n，避免读到空数据或越界写入 - 服务端地址用
":8080"即可监听所有网卡，但生产环境建议绑定具体 IP
addr := &net.UDPAddr{Port: 8080}
conn, _ := net.ListenUDP("udp", addr)
defer conn.Close()
for {
buf := make([]byte, 1024)
n, clientAddr, err := conn.ReadFromUDP(buf)
if err != nil {
continue
}
go func(n int, addr *net.UDPAddr) {
// 处理逻辑，例如回写
conn.WriteToUDP([]byte("ack"), addr)
}(n, clientAddr)
}为什么 UDP 包在本地测试通，跨机器就丢包
最常见原因是防火墙拦截或端口未开放。Linux 上可通过 sudo ufw status 查看；macOS 检查「系统设置 → 隐私与安全性 → 防火墙」；Windows 则看「高级安全 Windows 防火墙」入站规则。
其他可能性：
- 服务端绑定了
127.0.0.1，只能本机访问；应改用""或0.0.0.0 - 路由器或云服务器安全组未放行 UDP 端口（注意：TCP 和 UDP 端口策略是分开的）
- 某些网络环境（如企业内网）会主动丢弃 UDP 小包，可尝试发大于 512 字节的数据验证
UDP 通信中如何避免缓冲区溢出和内存泄漏
Go 的 UDP 连接底层复用系统 socket，但每次 ReadFromUDP 都需提供足够大的缓冲区。若固定用 make([]byte, 1024)，而对方发来 2KB 数据，多余部分直接被截断——UDP 不重传，也不会通知你丢包。
稳妥做法：
- 按业务最大可能包长分配 buffer（例如 DNS 最大 512B，自定义协议可设 64KB）
- 避免在 goroutine 中长期持有大 buffer；用
sync.Pool复用切片可降低 GC 压力 - 不要在循环里反复
make([]byte, ...)，尤其高并发场景下易触发频繁堆分配
复杂点在于：UDP 没有消息边界保证，应用层需自行定义帧头（比如前 4 字节存长度），否则无法判断一个完整逻辑包是否收齐。这点常被忽略，直到出现粘包或半包问题才意识到。
