Go x/net/ipv6.ControlMessage 为什么需要先启用接收选项

ControlMessage 是逐包元数据的表示对象，接收端还需要通过 SetControlMessage 请求协议栈提供相应信息。只创建结构体不会启用内核套接字选项。正确做法是在目标 PacketConn 上设置需要的标志、处理配置错误，再通过它的 ReadFrom 同时读取负载、控制消息和来源地址。

官方文档：https://pkg.go.dev/golang.org/x/net/ipv6

为什么建一个 ControlMessage 还不够

Go 结构体存在，不意味着每个字段都有数据来源。ControlMessage 表示 HopLimit、目标地址、接口索引等逐包属性；SetControlMessage 决定接收端向协议栈请求哪些信息，ReadFrom 才提供当前包关联的结果。

这里至少有三个对象：数据报负载、来源地址和附带的控制消息。它们不能互相替代。来源地址说明数据从哪里来，cm.Dst 用于表达收到包的目标地址；监听通配地址时，也不能简单把本地绑定地址当成每个包的目标地址。

在Go的ipv6协议栈操作里，ControlMessage属于内核额外返回的控制元数据，这类信息默认是不会随普通数据报文透传到用户态的，必须提前显式开启对应的套接字接收选项，内核才会把对应的控制信息塞到读取返回的辅助数据缓冲区里，你才能正常拿到ControlMessage里的源地址、跳转限制、接口索引这些附加字段。

如果没提前开启对应接收选项直接读ControlMessage，要么读到空的结构体，要么直接抛解析错误，本质是用户态缓冲区里根本就没有内核写入的对应控制数据。

怎样启用并读取逐包元数据

下面完整函数自行创建 IPv6 UDP 接收端，启用三个标志并设置等待期限，读取一个包后关闭。调用方传入自己使用的本地监听地址。它没有发送端，不会凭空产生数据包，也不包含本文的实际网络测试结果。

package packetmeta

import (
    "fmt"
    "net"
    "time"

    "golang.org/x/net/ipv6"
)

type Received struct {
    Payload []byte
    Source net.Addr
    Control *ipv6.ControlMessage
}

// ReadOne 在指定本地 IPv6 地址接收一个数据报，随后关闭端点。
func ReadOne(localAddress string) (Received, error) {
    conn, err := net.ListenPacket("udp6", localAddress)
    if err != nil {
        return Received{}, fmt.Errorf("建立 IPv6 接收端: %w", err)
    }
    defer conn.Close() // 当前函数拥有端点，结束时释放。
    pc := ipv6.NewPacketConn(conn)
    flags := ipv6.FlagDst | ipv6.FlagInterface | ipv6.FlagHopLimit
    if err := pc.SetControlMessage(flags, true); err != nil {
        return Received{}, fmt.Errorf("启用接收控制消息: %w", err)
    }
    if err := pc.SetReadDeadline(time.Now().Add(5 * time.Second)); err != nil {
        return Received{}, fmt.Errorf("设置接收期限: %w", err)
    }
    buf := make([]byte, 65535) // 示例接收区，不覆盖所有特殊超大数据报情形。
    n, cm, source, err := pc.ReadFrom(buf)
    if err != nil {
        return Received{}, fmt.Errorf("读取 IPv6 数据报: %w", err)
    }
    // 保留 cm 是否存在的原始状态，不把缺失伪装成业务默认值。
    return Received{Payload: buf[:n], Source: source, Control: cm}, nil
}

配置应在开始接收前完成。示例遇到 SetControlMessage 错误就停止，避免应用误以为请求的元数据已经可用。如果产品允许缺少某些可选字段，可以另行设计降级分支，但要明确记录哪些能力没有启用。

读取必须使用这里的 pc.ReadFrom。若随后改用原始 conn.ReadFrom，其返回签名没有 ControlMessage，调用方也就没有从这个接口取得附带元数据。不要让两个独立读取循环同时从同一端点抢包，再尝试拼接结果。

cm 为空或字段为零应该怎么判断

先处理读取 error，再判断 cm 是否为 nil，然后结合已成功配置的选项解释字段。不能直接访问 cm.Dst 而跳过指针判断，也不能把全部零值统一理解为“配置成功且网络值就是零”。不同字段和平台支持情况需要分别解释。

cm 非 nil 也不代表结构体中所有字段都已填充。代码只请求了目标地址、接口索引和 HopLimit，不应期待所有其他属性自然出现。诊断记录应包含请求的 flags、配置错误、读取错误，以及 cm 是否存在。

普通收包成功与元数据满足业务需求是两个条件。如果某项元数据是处理所必需的，缺失时应由业务明确拒绝或等待替代信息；如果只是用于日志，可保留未知状态。不要偷偷填入看似合理的常量再当作网络事实。

接收配置与发送配置有什么区别

SetControlMessage 控制的是接收逐包信息。发送时，WriteTo 的 cm 参数向协议栈指定某些发送选项；修改一个用于发送的 cm，不会自动启用接收选项。SetHopLimit 则设置后续发出包的跳数限制，也不是“接收 HopLimit”的开关。

结构体字段还有方向差异。官方文档将 Src、NextHop 标为指定发送选项用途，将 Dst、MTU 标为接收用途。不能把接收得到的整个对象不加判断地当成一份完整发送配置，应该只设置发送任务需要且接口支持的字段。

接入时还要注意哪些边界

在所有系统上启用都能得到相同信息吗？不能这样承诺。官方文档列出平台限制，其中 Windows 的 PacketConn ReadFrom 和 WriteTo 控制消息未实现。项目应以实际平台、依赖版本和配置返回错误为依据，不能通过忽略错误获得支持。

启用接收选项会改写对方发来的内容吗？它请求协议栈把相关逐包属性交给应用，不是应用负载转换器。业务读取负载时仍应按自己的协议处理。

没有包到达，为什么一直等不到 cm？控制消息随接收结果出现，配置本身不产生数据。示例设置五秒期限，以免调用无限等待。

可以关闭某类元数据吗？SetControlMessage 的 on 参数用于启用或关闭相应接收选项；调整时仍要处理错误，并让业务知道可用字段发生了变化。

接入时保持“配置同一个端点、从对应封装读取、按需解释字段”三者一致，通常比只查看 ControlMessage 的零值更容易找出问题。

参考：SetControlMessage 文档、ControlMessage 字段约定。