Go x/net/ipv4.PacketConn 为什么区分控制信息与数据载荷

使用 Go x/net/ipv4.PacketConn 处理 UDP 或其他 IPv4 数据报时，最容易混淆的是 ReadFrom 返回的三类信息：真正的业务字节、IP 层控制信息，以及对端地址。它们不是同一份数据的不同写法，而是分别服务于“读什么”“从哪张网卡/哪个 IP 层上下文读写”和“对端是谁”。把三者混在一起，常见结果就是目的地址判断失效、接口选择不生效，或者把控制字段误当成业务协议内容。

先把 ReadFrom 的三个返回值分成三层

排查“收到包却判断不到目标地址”时，先看方法签名：ReadFrom(b []byte) (n int, cm *ControlMessage, src net.Addr, err error)。n 表示写入缓冲区的载荷字节数；cm 保存按控制选项取得的 IPv4 层信息；src 表示收到数据报的源地址。它们的生命周期也不同：载荷通常交给 UDP、DNS 或自定义协议，cm 用来做多播目的地址或接口判断，src 用来识别回包对象。

接收控制字段不是默认把所有信息都塞给调用方，而是显式订阅。比如只关心数据报到达了哪个 IPv4 目的地址和接口，可以这样写：

func readIPv4(p *ipv4.PacketConn) error {
	// 只请求本文要用的目的地址和入站接口，避免无关控制字段混入判断。
	if err := p.SetControlMessage(ipv4.FlagDst|ipv4.FlagInterface, true); err != nil {
		return fmt.Errorf("enable control message: %w", err)
	}

	buf := make([]byte, 1500)
	n, cm, src, err := p.ReadFrom(buf)
	if err != nil {
		return fmt.Errorf("read IPv4 datagram: %w", err)
	}
	if cm == nil || cm.Dst == nil {
		return fmt.Errorf("destination control data is unavailable")
	}

	// n 才是本次载荷长度，不能把整个 1500 字节缓冲区交给上层。
	payload := buf[:n]
	fmt.Printf("src=%v dst=%v if=%d payload=%q\n", src, cm.Dst, cm.IfIndex, payload)
	return nil
}

这里的 cm.Dst 不是业务数据里的字段，也不会自动出现在 payload 中。它来自协议栈提供的辅助信息；如果没有启用对应 flag，或者当前平台不提供该能力，就不能把它当成一定存在的值。

为什么控制信息不能塞进 payload

载荷是应用协议的字节序列，协议作者可以定义 JSON、二进制头或文本格式；控制信息则是操作系统和 IPv4 栈围绕某个数据报附带的元数据。两者混合会产生两个问题。第一，业务协议会被迫知道网卡索引、目的 IP 等主机细节，跨进程转发时还容易把已经失效的本机信息继续传出去。第二，控制字段并不一定存在于每个平台，若把它编码进载荷，接收端会误以为这是一项跨平台协议保证。

PacketConn 的设计把边界留在 API 上：ReadFrom 复制载荷，ControlMessage 表达每包 IP 层选项，SetControlMessage 控制哪些辅助信息从协议栈进入 Go 代码。这种拆分也让同一段业务 payload 可以在不同接口发送，而不必重写上层协议。

WriteTo 怎样把内容、目标和发送路径分开

发送方向的签名是 WriteTo(b []byte, cm *ControlMessage, dst net.Addr)：b 是要发出的数据，dst 是目标地址，cm 在需要时描述数据报路径和出站接口。比如多网卡程序只把接口选择放到控制消息里：

func sendOnInterface(p *ipv4.PacketConn, ifIndex int, dst net.Addr, payload []byte) error {
	// IfIndex 必须是有效的接口索引；业务内容仍然只放在 payload 中。
	cm := &ipv4.ControlMessage{IfIndex: ifIndex}
	if _, err := p.WriteTo(payload, cm, dst); err != nil {
		return fmt.Errorf("send through interface %d: %w", ifIndex, err)
	}
	return nil
}

官方文档还特别标明，WriteTo 中用于控制数据报路径的控制消息目前支持 Darwin 和 Linux；Windows 上 PacketConn 的 ReadFrom/WriteTo 控制消息未实现。因此遇到“代码无报错但接口选择不生效”，不要先修改 payload 格式，先确认平台和控制字段是否真的被支持。

故障排查时先看这张边界清单

常见问题

ControlMessage 是不是 IPv4 头本身？

不是。它是每包 IP 层选项的 Go 表达，和应用载荷、对端地址分开返回；需要完整 IPv4 头时，应考虑 RawConn 的专门接口。

只调用 ReadFrom，不调用 SetControlMessage 可以吗？

可以读取载荷和源地址，但不要假设能得到目的地址、接口索引等辅助字段。需要哪些字段就显式开启对应的 ControlFlags，并处理平台不支持的情况。

为什么同一份代码在 Windows 上行为不同？

x/net/ipv4 官方文档列出了 Windows 上 PacketConn 控制消息未实现的限制。跨平台程序应把该能力当作可探测的运行时特性，而不是无条件的业务前提。