Go netlink 怎样向内核发送只读查询消息

我在排查“查询接口偶尔像是在改状态”这类问题时，最先会回到 netlink 消息头，而不是先看 Go 的函数名。使用 github.com/mdlayher/netlink 时，只读语义主要由目标 family、消息类型和 flags 共同决定；Conn.Execute 负责把发送、接收和回复校验收拢起来，但它不会替你猜出具体内核协议的 payload。

官方文档：https://pkg.go.dev/github.com/mdlayher/netlink

因此，一条安全的排查结论是：先选对 family，再用目标 UAPI 定义的查询消息类型，给消息加上 Request，需要完整枚举时再加 Dump，不要混入 Create、Replace 等写操作标志。下面以 Linux 路由 netlink 的“读取链路对象列表”为例说明结构，示例中的协议类型和 payload 仍应以目标内核头文件为准。

只读查询不是由“调用了 Execute”自动保证的；真正需要复查的是 family、Header.Type、Header.Flags 和协议负载是否都属于查询路径。

症状：消息发出去了，但查询边界说不清

常见误区是把“打开了 netlink socket”当成“已经完成只读查询”。实际上，Dial 只负责连接某个 netlink family；Message 还要携带消息类型、flags 和该 family 规定的二进制数据。类型错了，可能直接收到内核错误；flags 错了，则可能把本应是单对象查询的请求变成整表枚举，或者在写型消息上带入创建语义。

这次问题的触发条件通常有三个：把 NETLINK_ROUTE、NETLINK_GENERIC 等 family 混用；把 RTM_GET* 与其他 family 的类型常量混用；只检查 Go 层没有返回 error，却没有解析回复中的 Data。这三类错误都不是 Execute 能自动修正的。

先固定连接，再构造查询消息

连接层只做一件事：打开目标 family，并明确关闭责任。下面的骨架使用路由 family 和链路查询类型，Header.Type 的具体值来自 Linux rtnetlink UAPI；Data 的布局也必须跟该 UAPI 对齐。

package main

import (
	"fmt"

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

func queryLinks() error {
	// Dial 只连接指定 family；它不会替调用方选择消息类型或 payload。
	conn, err := netlink.Dial(unix.NETLINK_ROUTE, nil)
	if err != nil {
		return fmt.Errorf("打开 route netlink 失败: %w", err)
	}
	defer conn.Close() // 查询结束后释放 netlink socket。

	request := netlink.Message{
		Header: netlink.Header{
			// RTM_GETLINK 是链路查询类型，常量应来自目标 Linux UAPI。
			Type:  unix.RTM_GETLINK,
			// Request 表示请求；Dump 表示希望收到完整对象集合。
			Flags: netlink.Request | netlink.Dump,
		},
		// Data 由 rtnetlink 的 ifinfomsg 和属性规则决定，此处省略具体编码。
	}

	msgs, err := conn.Execute(request)
	if err != nil {
		return fmt.Errorf("执行只读查询失败: %w", err)
	}
	fmt.Printf("收到 %d 条 netlink 消息\\n", len(msgs))
	return nil
}

这里故意没有手写 Length、Sequence 和 PID。官方包文档说明，Send 会在这些字段为零时自动补齐；应用真正需要自己负责的是消息类型与 payload 的协议契约。若要查询单个对象，通常还要把对象标识写进 payload，并按对应 UAPI 调整 flags，不能只把 Dump 删除就认为完成了转换。

只读语义由 flags 和 payload 一起限定

在 Header.Flags 中，Request 表示请求，Dump 是 Root | Match 的组合，用于请求完整列表；Acknowledge 可以要求内核返回确认信息。相反，Create、Replace、Excl、Append 属于对象修改相关语义，不能为了“让内核返回更多信息”随意加到查询消息上。

还要注意，flags 只解决消息头层面的意图，不能替代 payload。以 RTM_GETLINK 为例，链路查询所需的 ifinfomsg 和属性仍应按内核 UAPI 编码；泛型 netlink 则要先解析 family，再根据该 family 的命令和属性编号组织数据。两者都属于协议数据边界，不应把一个 family 的常量复制到另一个 family。

Execute 如何收拢回复与错误

Execute 的价值在于把一次请求的收发配对起来：它内部调用 Send，再调用 Receive，最后按请求校验回复。Receive 会把 multipart 回复作为一个消息切片返回并去掉结束标记；如果内核返回 netlink error，错误会从接收阶段返回。

func decodeReplies(msgs []netlink.Message) error {
	for _, msg := range msgs {
		// 每条 Data 的结构由目标 family 定义，不能按通用 JSON 或字符串处理。
		if len(msg.Data) == 0 {
			continue
		}
		// 这里应调用对应 family 的解码器，并检查属性解码错误。
		fmt.Printf("type=%d flags=%s data=%d bytes\\n", msg.Header.Type, msg.Header.Flags, len(msg.Data))
	}
	return nil
}

如果查询结果是多段消息，不要只取 msgs[0] 就返回；如果需要知道是哪个请求的回复，也不要自行忽略 Sequence 和 PID。使用 Execute 可以让库完成这一层匹配，但业务仍要逐条解码 Data，并处理属性缺失、内核错误或结果为空。

防止下一次把查询写成修改

我会把下面四项放进代码评审清单：第一，family 与 message type 是否来自同一份 UAPI；第二，flags 是否只有查询所需的组合；第三，payload 是否按该 family 的结构和属性编码；第四，回复是否完整消费并区分 multipart、空结果和错误。权限问题也要单独看，某些扩展属性或一致性快照可能需要额外能力，即便消息本身是 GET。

最小结论是：netlink.Dial 建立通信边界，Message.Header 表达请求类型和只读意图，Message.Data 遵守内核协议，Conn.Execute 负责一次请求的收发和基础校验。把四层分开后，查询失败时就能判断是 family、flags、payload、权限，还是回复解码的问题。

相关问题

只查询一个对象还需要 Dump 吗？ 通常不需要。是否要带 Dump 取决于目标 family 的查询语义；单对象查询应把对象标识放进该 family 规定的 payload。

为什么 Execute 返回多条消息？ 查询列表可能采用 multipart 回复。库会把多段结果整理成切片，调用方仍要遍历并按 family 解码每条 Data。

只读查询也可能报权限错误吗？ 可能。读取特定扩展信息、进入指定网络命名空间或请求一致性快照时，内核仍可能要求能力或特权；只读不等于无条件可访问。