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 概念，但也不意味着天然并发。

关键点：

• 每个收到的包都应起独立 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 字节存长度），否则无法判断一个完整逻辑包是否收齐。这点常被忽略，直到出现粘包或半包问题才意识到。