Go 中使用 net.DialUDP 创建的是已连接的 UDP 套接字，其底层调用 connect() 系统调用，导致 ReadFromUDP 仅接受来自目标地址（含 IP 和端口）的数据包，若响应源端口与初始目标端口不一致，则数据包被内核静默丢弃。
go 中使用 `net.dialudp` 创建的是已连接的 udp 套接字，其底层调用 `connect()` 系统调用，导致 `readfromudp` 仅接受来自目标地址（含 ip 和端口）的数据包，若响应源端口与初始目标端口不一致，则数据包被内核静默丢弃。
在 Go 的网络编程中，net.DialUDP 与 net.ListenUDP 行为有本质区别：前者创建已连接（connected）UDP socket，后者创建未连接（unconnected）UDP socket。这一差异直接决定了 ReadFromUDP 方法的接收行为。
? 为什么 DialUDP 会限制源地址？
调用 net.DialUDP("udp6", nil, remoteAddr) 时，Go 底层执行的是类 Unix 系统的 connect() 系统调用（即使对 UDP）。根据 man 2 connect 的明确说明：
If the socket sockfd is of type SOCK_DGRAM then addr is the address to which datagrams are sent by default, and the only address from which datagrams are received.
即：对 SOCK_DGRAM 类型套接字，connect() 不仅设定了默认发送目标，还强制限定了唯一合法的接收来源地址（IP + 端口）。任何来自其他地址（哪怕同一 IP、不同端口）的数据包，都会被内核在协议栈层面直接丢弃，根本不会送达 Go 应用层 —— 因此 ReadFromUDP 永远阻塞或返回错误（如 io.EOF 或连接重置），而 Wireshark 却能看到响应包，正是这一“内核过滤”现象的典型表现。
✅ 正确做法：使用 ListenUDP 实现灵活收发
若需接收来自任意地址（例如服务端需处理多个客户端、或响应端口动态变化的场景），应改用 net.ListenUDP 创建监听套接字，并通过 WriteToUDP 显式指定目标地址：
package main
import (
"log"
"net"
"time"
)
func main() {
// 解析目标地址（仅用于发送，不用于绑定）
boxAddr, err := net.ResolveUDPAddr("udp6", "[fe80::211:7d00:30:8e3f%en0]:5684")
if err != nil {
log.Fatal(err)
}
// 监听本地任意可用地址（推荐显式绑定链路本地地址+scope ID）
laddr, err := net.ResolveUDPAddr("udp6", "[fe80::%en0]:0") // 端口 0 表示系统自动分配
if err != nil {
log.Fatal(err)
}
conn, err := net.ListenUDP("udp6", laddr)
if err != nil {
log.Fatal(err)
}
defer conn.Close()
log.Printf("Listening on %v", conn.LocalAddr())
// 启动接收协程
go func() {
buf := make([]byte, 1024)
for {
n, addr, err := conn.ReadFromUDP(buf)
if err != nil {
log.Printf("Read error: %v", err)
continue
}
log.Printf("Received %d bytes from %v: %s", n, addr, string(buf[:n]))
}
}()
// 定期向目标发送时间戳
ticker := time.NewTicker(1 * time.Second)
defer ticker.Stop()
for range ticker.C {
msg := []byte(time.Now().String())
if _, err := conn.WriteToUDP(msg, boxAddr); err != nil {
log.Printf("Write to %v failed: %v", boxAddr, err)
continue
}
log.Printf("Sent %d bytes to %v", len(msg), boxAddr)
}
}? 关键提示：IPv6 链路本地地址必须携带接口标识（如 %en0），否则 ResolveUDPAddr 可能失败；ListenUDP 的 laddr 应明确包含 scope ID，否则绑定可能失败或行为不可预测。
⚠️ 注意事项与最佳实践
- 不要混用 DialUDP 与多对端通信：DialUDP 天然适用于“一对一”请求-响应模型（如 DNS 查询），但不适合服务端或需要泛化接收的场景。
- ReadFromUDP 在 connected socket 上仍可调用，但语义已变：它不再返回源地址（始终返回 Dial 时的目标地址），且仅接收匹配该地址的数据包 —— 实际等价于 Read()。
- 调试技巧：使用 conn.LocalAddr() 打印实际绑定地址，确认是否含正确 scope ID；用 ss -ulpn | grep :<port>（Linux）或 netstat -nul | grep <port>（macOS）验证套接字状态。
- 安全性考量：ListenUDP 接收任意源数据，生产环境需自行校验 addr 字段，防范伪造源地址攻击。
总之，理解 UDP “连接态” 的内核语义是避免此类问题的关键。选择 DialUDP 还是 ListenUDP，本质上是在「通信确定性」与「地址灵活性」之间做权衡 —— 根据你的协议设计目标，明确选择即可。
