UDP包超MTU会被内核静默丢弃，Go应用层无感知；需按1200字节分片、手动实现PMTUD、应用层处理分片重装、启用PacketInfo获取目的地址、并发写必须加锁。
UDP包超过MTU时会直接被内核丢弃，不通知应用层
Go 的 net.Conn.WriteTo 或 net.UDPConn.WriteToUDP 对大于路径 MTU 的 UDP 包不会报错，而是静默丢弃——这是最常被误以为“网络卡顿”或“对方没收到”的根源。根本原因在于 IP 层分片失败（比如中间设备禁用了 ICMP “Fragmentation Needed” 报文），而 Go 应用层完全感知不到。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 默认假设 IPv4 路径 MTU ≤ 1500 字节，IPv6 ≤ 1280 字节；实际生产中建议按
1200字节切分业务数据，留足 IP+UDP 头部余量 - 不要依赖
SetReadBuffer/SetWriteBuffer来“增大 MTU”，它们只影响 socket 缓冲区，不影响 IP 分片行为 - 若需探测真实路径 MTU，必须自行实现 PMTUD：发送带
DF标志的 UDP 包 + 监听 ICMPv4 “Type 3 Code 4” 或 ICMPv6 “Type 2”，Go 标准库不提供封装
Go 标准库没有内置的 UDP 分片重装逻辑
net.UDPConn 是纯裸通道，收发都是原始 UDP datagram。哪怕你发了 3 个分片包，对方收到后也是 3 次独立的 ReadFrom 调用，顺序、丢失、重复全由上层处理——标准库既不分片也不重组。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 若要支持可靠传输，必须在应用层定义分片协议：比如前 4 字节存 total_size，再 4 字节存 fragment_index，再 2 字节存 fragment_count
- 避免用时间戳或序号做唯一标识，UDP 乱序下容易误判；推荐用随机
session_id+ 单调递增的frag_id - 接收端缓存窗口不宜过大，
map[session_id][]*fragment要配超时清理（比如 5 秒无新分片则丢弃），否则内存泄漏
启用 IPV6_RECVPKTINFO 或 IP_PKTINFO 才能获取入包接口/目的地址
UDP 服务监听 :0 或 0.0.0.0:port 时，收到包默认不知道它具体打在哪个本地 IP 上。这对多网卡、NAT 回包、源地址校验等场景是硬伤。Go 1.19+ 支持通过 SetControlMessage 启用控制消息，但需手动解析 CMSG 数据。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- IPv4 下启用
net.IPv4PacketInfoOn，IPv6 下用net.IPv6PacketInfoOn，然后从UDPAddr.ControlMessage解析目的 IP - 注意：Windows 不支持该机制，
ReadFrom返回的*net.UDPAddr中IP字段始终为空；Linux/macOS 可用，但需确保内核版本 ≥ 2.6.32 - 别在循环里反复调用
SetControlMessage，它开销大；初始化连接时设一次即可
UDP 并发写导致 write: message too long 错误
多个 goroutine 并发调用同一个 *net.UDPConn.WriteTo，且未加锁，可能触发 "write: message too long"——这不是数据超长，而是内核 socket 发送缓冲区被并发写冲垮，返回了错误码 EMSGSIZE（即使单次数据远小于 MTU）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对同一
*net.UDPConn的写操作必须串行化，最简单是加sync.Mutex；高并发场景可用chan []byte配合单个 writer goroutine - 不要用
conn.SetWriteDeadline来“防阻塞”，它只控制系统调用超时，不解决并发冲突 - 如果使用
gopacket或 raw socket，务必检查syscall.Sendto返回值，Go 标准库会把EMSGSIZE转成明确的错误字符串
