udp打洞失败头号原因是bind端口不一致：双方随机绑定导致nat映射失效；应固定端口、预热映射、同步打洞，并依nat类型决定是否需中继。
UDP打洞失败时，bind端口不一致是头号原因
两边程序各自bind随机端口，打洞包发出去后对方回包只能到旧端口——而那个端口早就被系统回收或没开映射。NAT设备只对“最近一次外发包的源端口+目标IP:端口”维持短暂映射，不是永久开通。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
net.ListenUDP绑定固定端口（如:50000），避免":0"让系统选端口 - 双方提前约定好打洞端口，且该端口在防火墙/路由器上未被拦截
- 若必须用动态端口，启动后立刻调用
conn.LocalAddr()读出实际绑定地址，并通过信令服务器交换 - linux下注意
net.ipv4.ip_local_port_range可能限制可用端口范围，50000–65535更稳妥
为什么WriteToUDP发不出去，但没报错？
UDP是无连接协议，WriteToUDP成功只代表数据进了发送缓冲区，不代表对方收到，也不代表NAT映射已建立。常见于：对方还没发过包、你的发包目标IP:端口不在其NAT映射白名单里、中间运营商做了UDP限速或丢弃。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 发包前先用
conn.WriteToUDP([]byte{0}, remoteAddr)发1字节空包“预热”NAT映射（某些对称型NAT要求严格匹配五元组） - 连续发3–5次打洞包，间隔
100–300ms，别依赖单次发送 - 用
tcpdump -i any udp port 50000确认本机是否真发出了包；用对方机器抓包确认是否收到 - 避免用
localhost或127.0.0.1测试——这绕过了NAT，完全不模拟真实场景
STUN响应能拿到公网IP，但p2p直连仍不通
STUN只解决“我是谁”，不解决“怎么让对方也看到我”。很多开发者误以为拿到mapped IP:port就能直接WriteToUDP，忽略了NAT类型差异：对称型NAT每次外发都会生成新映射，且只接受来自原目标地址的回包。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
stunclient github.com/ccding/go-stun测NAT类型，确认是否为全锥型（Full Cone）——只有这类才适合简单打洞 - 双方必须同时向对方的STUN得到的
mapped address发包（即“打洞同步”），不能一先一后 - 若一方是端口受限锥型（Port-Restricted Cone）或对称型（Symmetric），需引入中继（TURN）或服务端协助中转，纯UDP打洞大概率失败
- 检查
net.InterfaceAddrs()获取的本地IP是否含192.168.x.x或10.x.x.x——这才是你要告诉对方的内网地址，不是STUN返回的公网地址
Go里UDPConn复用和goroutine安全要注意什么
net.UDPConn本身是线程安全的，WriteToUDP和ReadFromUDP可并发调用，但共享buf或解析逻辑容易出竞态。更隐蔽的问题是：一个conn被多个goroutine长期阻塞在ReadFromUDP，会导致资源滞留。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个连接只启一个读goroutine，用
for { n, addr, err := conn.ReadFromUDP(buf) }循环处理，别为每次读新开goroutine - 写操作可并发，但若涉及构造不同内容的包，确保
buf不共用（比如用make([]byte, 1500)每次分配） - 用
context.WithTimeout包装ReadFromUDP调用，防止某次卡死拖垮整个连接 - 关闭连接前调用
conn.SetReadDeadline(time.Now().Add(1 * time.Millisecond))唤醒阻塞读，再conn.Close()
打洞最不可控的是NAT行为本身——同一款家用路由器，固件版本差一个小点，NAT超时时间、映射粒度、是否校验源端口都可能变。别在没抓包验证前假设“逻辑应该通”。