必须用net.resolveudpaddr解析地址后再传给net.dialudp，直接传字符串会panic；正确做法是addr, err := net.resolveudpaddr("udp", "127.0.0.1:8080")，它自动处理ipv4/ipv6、主机名和端口缺省。
net.DialUDP 发送前必须先解析地址
直接传字符串给 net.DialUDP 会 panic，比如写成 net.DialUDP("udp", nil, "127.0.0.1:8080") —— 它不接受字符串地址。Go 要求第二个参数（远端）必须是 *net.UDPAddr 类型。
正确做法是用 net.ResolveUDPAddr 解析：
-
addr, err := net.ResolveUDPAddr("udp", "127.0.0.1:8080")，它能自动处理 IPv4/IPv6、主机名（如"localhost:8080"）、缺省端口等 - 若目标是 DNS 动态地址（如
"service.example.com:9000"），别缓存解析结果太久；UDP 无连接，IP 变了后续包就发丢了 - 本地测试时注意：
"localhost"在 macOS/Linux 上常解析为::1（IPv6），而接收端只监听0.0.0.0:8080（IPv4）就收不到——建议测试阶段统一用"127.0.0.1"
WriteToUDP 才是 UDP 的本质用法
很多新手误以为 DialUDP 是“建立连接”，其实它只是绑定一个默认远端地址，方便调 Write。真要发给多个目标（比如打洞、广播、多实例上报），必须用 net.ListenUDP + WriteToUDP。
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
-
conn, _ := net.ListenUDP("udp", &net.UDPAddr{Port: 0})：让系统随机分配本地端口，适合客户端角色 -
dst, _ := net.ResolveUDPAddr("udp", "192.168.1.100:9999")：目标地址必须提前解析好，不能传nil或格式错的*net.UDPAddr，否则报invalid argument -
DialUDP创建的 conn 调WriteToUDP不报错，但会忽略你传的地址，仍发往 dial 时的目标；反过来，ListenUDP的 conn 调Write会直接 panic：write: bad file descriptor
发送后程序立即退出会导致数据没发出
WriteToUDP 或 Write 返回成功，只代表数据进了内核 socket 缓冲区，不是已发出。如果紧接着 os.Exit(0) 或函数返回，runtime 可能来不及刷缓冲区，包就丢了。
- 本地测试最简单解法：
time.Sleep(1 * time.Millisecond)，够用且不拖慢流程 - 生产环境推荐设写超时：
conn.SetWriteDeadline(time.Now().Add(2 * time.Second))，再调WriteToUDP，检查错误是否为net.ErrWriteTimeout - 别依赖
err == nil就认为发成功了——UDP 无连接，目标端口没监听时，Linux 可能延迟返回connection refused，取决于 ICMP 响应是否到达
缓冲区大小和 MTU 是丢包主因
UDP 包超过链路 MTU（通常以太网是 1500 字节）会被分片，任意一片丢掉整包就废了。更常见的是应用层缓冲区太小，导致 ReadFromUDP 截断数据却不报错。
- 发送前务必检查长度：
if len(data) > 1472 { /* 拆包或拒绝 */ }（1500 − 20 IP 头 − 8 UDP 头） - 接收端 buffer 至少开
make([]byte, 65536)，这是 IPv4 下理论最大 UDP 载荷（65535 − 8），避免截断 -
ReadFromUDP返回的n必须校验，buf[:n]才是真实收到的数据；不要假设每次都能读满整个业务消息 - 别在循环里反复调
net.ResolveUDPAddr，DNS 解析有开销，应提前做或缓存
实际部署时最容易被忽略的是写超时和缓冲区截断——前者让 goroutine 卡死数分钟，后者让日志或监控数据静默丢失，表面看一切正常，查起来却毫无头绪。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
