Go netlink 怎样解码多部分Netlink响应

使用 github.com/mdlayher/netlink 时，多部分响应通常不需要自己循环调用 Receive 并等待 Done。普通请求可用 Conn.Execute，它调用接收逻辑收集响应并核对请求关联；拿到 []netlink.Message 后，应用再按对应协议逐条解码 Data。

项目文档地址：https://pkg.go.dev/github.com/mdlayher/netlink。本文以v1.11.2为接口依据，用Linux只读接口列表说明这两层工作，不执行网络配置修改。

先区分传输分段与业务消息

假设要取得当前网络命名空间的接口名称。接口多了，内核可能把dump结果拆到多个接收批次；但这些消息并不是某段大JSON的碎片。每条Netlink消息仍有自己的Header和Data，业务载荷需要分别解释。

我更愿意先把这个问题看成“谁负责边界”，再考虑优化：通用库负责外层消息及多部分接收，协议代码负责接口信息。官方接口提供了这种分层能力；这是一种工程选择，并不能据此声称行业都在迁移到某种新模式，本文也没有热度或吞吐统计。

把完整接收交给Execute

库的 Receive 会透明处理多部分消息，返回合并后的消息切片，并移除末尾的多部分完成消息。Execute 再把发送、接收与请求响应匹配包在一次调用里。收到的是一批消息，不是一个需要再按固定缓冲区大小切片的裸字节数组。

容易误用的一点是：Execute已经消费了响应，调用方又继续Receive等待Done。此时完成消息已被库处理，额外读取可能等待后续数据，直到超时。不要为“确认收全”再加一个没有协议依据的读取循环。

逐条解析接口信息与属性

示例向 NETLINK_ROUTE 发出 RTM_GETLINK dump请求。每条预期响应类型是 RTM_NEWLINK，Data的起始部分为ifinfomsg，后面才是属性。接口名称取自IFLA_IFNAME，不把所有Data拼接，也不把整个Data直接送入属性解析器。

# 在已有Go模块中固定本文使用的netlink版本
go get github.com/mdlayher/netlink@v1.11.2

//go:build linux

package main

import (
    "bytes"
    "fmt"
    "log"
    "time"

    "github.com/mdlayher/netlink"
    "golang.org/x/sys/unix"
)

// 接口查询是只读操作；只在整批接收和解析都成功时返回名称。
func linkNames() ([]string, error) {
    c, err := netlink.Dial(unix.NETLINK_ROUTE, nil)
    if err != nil { return nil, err }
    defer c.Close()
    // 用总截止时间限制请求等待，示例连接用完即关闭。
    if err := c.SetDeadline(time.Now().Add(5 * time.Second)); err != nil {
        return nil, err
    }
    req := netlink.Message{
        Header: netlink.Header{
            Type: netlink.HeaderType(unix.RTM_GETLINK),
            Flags: netlink.Request | netlink.Dump,
        },
        // ifinfomsg首字节为AF_UNSPEC，其余为零，不添加属性。
        Data: make([]byte, unix.SizeofIfInfomsg),
    }
    messages, err := c.Execute(req)
    if err != nil { return nil, fmt.Errorf("查询接口：%w", err) }

    names := make([]string, 0, len(messages))
    for i, m := range messages {
        // dump中断不能当作完整接口快照交付。
        if m.Header.Flags&netlink.HeaderFlags(unix.NLM_F_DUMP_INTR) != 0 {
            return nil, fmt.Errorf("接口dump被中断")
        }
        if m.Header.Type != netlink.HeaderType(unix.RTM_NEWLINK) {
            return nil, fmt.Errorf("第%d条消息类型不符合接口响应约定", i)
        }
        if len(m.Data) 

代码仅适用于Linux。运行环境需满足所选依赖的Go版本要求；容器的网络命名空间和安全配置也会影响可见接口或请求是否被允许。这里不列固定接口名，不声称已经运行成功。

包装函数选择“全部成功才返回名称”，任何短载荷、属性解码错误或缺少名称都会使整次调用失败，避免把半份列表当作完整结果。忽略其他属性是因为它们不在本文任务范围内，并不表示它们无效。此处的名称解析只适用于这个已知的字符串属性，不能推广成所有Netlink属性都按字符串读取。

选择手动收发前先明确代价

不能因为Conn支持并发调用，就让一个后台监听器随意接走查询连接的消息。Execute提供事务锁定，但业务仍需设计哪些连接用于请求，哪些用于事件监听。对普通接口名称读取，我倾向先采用独立连接加Execute，代码更容易说明成功与失败。

若换成 Generic Netlink，Data还可能包含它自己的协议头；如果换成其他rtnetlink消息，固定头也不一定是ifinfomsg。不要把这里的偏移量复制到不同消息类型中。

记录完整性与解析错误

落地时关注三类信息就足够明确：请求是否超时或被内核拒绝；响应是否符合预期类型及完整性要求；业务属性是否可解析。记录错误时带上消息索引或阶段，有助于区分“没接收完”和“接收完成但载荷处理错了”。这些是读者实现程序时的错误边界，不是本文的实际运行记录。

Linux文档提醒dump结果可能带有NLM_F_DUMP_INTR，意味着结果可能不一致，应重新获取。示例检查返回的数据消息标记；若完整性要求更高，还应结合所用版本对结束消息状态的处理确认覆盖范围，不能把“没有错误”宣传为某一时刻的强一致快照。重试应受次数或时间预算限制。

多部分响应是不是一定包含多条业务记录？

不一定。它描述协议传输方式，不能当作记录数量。程序应处理空集合及不同长度的消息切片。

为什么解析属性总是报长度错误？

先确定Data前面是否有协议固定头。示例要跳过ifinfomsg；Generic Netlink和其他消息类型需要按各自定义处理，不能统一跳过同一个长度。

是不是把接收缓冲区调大就能代替多部分处理？

不能。缓冲区大小和协议结束边界是不同问题。调大缓冲区也不能替代正确的消息类型、请求关联与属性解释。

依据：netlink接口文档、v1.11.2连接实现、Linux Netlink协议介绍。