Go genetlink 通用命令编号与Netlink消息类型有什么区别

在Generic Netlink业务消息中，外层Netlink消息的 Header.Type 用来选择协议族，内层 genetlink.Header.Command 用来选择这个族中的操作。前者通常来自发现到的Family.ID，后者来自该族公开的命令定义，两者不能互换。

官方项目文档：https://pkg.go.dev/github.com/mdlayher/genetlink。本文以genetlink v1.4.0为接口依据，讨论Generic Netlink，不把Classic Netlink中的类型含义直接套过来。

先按所在消息头区分两个编号

可以把族ID理解为“交给哪个子系统”，命令理解为“在这个子系统里做什么”。相同命令数字出现在两个不同族中，未必表示同一种操作。接口设计时把参数命名为familyID和command，比都叫msgType更容易避免误传。

让族标识和命令分别成为参数

genetlink的Execute接口接收三个部分：Message、family uint16以及netlink.HeaderFlags。Message.Header放Command和Version；family参数由库封装到外层Type；flags则放入外层Flags。使用高层Execute时，不需要再手工把Netlink外层头塞进Message.Data。

实际连接可用GetFamily按名称取得Family，再使用它的ID。对动态分配的族ID，不应把另一台机器或过去日志中的数字当作稳定常量。命令编号也不能靠猜测，必须来自目标族的UAPI定义或协议说明；发现一个族，并不意味着任何命令都受支持。

版本字段同样不能用随意截断的整数代替兼容策略。若包装接口接收较宽的版本值，应先检查是否符合目标协议及uint8范围，再转换；不要因为字段名叫Version，就把MySQL、Go或内核版本号填进去。

离线封装一条两层消息

下面用虚构族ID和命令演示结构，完全不发送请求。它有意不提供真实业务属性，因为属性格式与必填条件属于具体协议族。

# 在已有Go模块中固定本文讨论的genetlink版本
go get github.com/mdlayher/genetlink@v1.4.0

package main

import (
    "fmt"
    "log"
    "github.com/mdlayher/genetlink"
    "github.com/mdlayher/netlink"
)

func demo() error {
    // 都是离线演示值，不是当前机器上的真实族ID或真实命令。
    const familyID uint16 = 0x31
    const queryCommand uint8 = 7
    inner := genetlink.Message{
        Header: genetlink.Header{Command: queryCommand, Version: 1},
        Data: nil, // 仅演示头部，真实命令按族规范填充属性。
    }
    payload, err := inner.MarshalBinary()
    if err != nil { return err }

    // 外层Type取族ID，内部载荷已经包含Generic Netlink头。
    outer := netlink.Message{
        Header: netlink.Header{
            Type: netlink.HeaderType(familyID),
            Flags: netlink.Request,
        },
        Data: payload,
    }
    var decoded genetlink.Message
    // 解内层时只传外层Data，不再次包含Netlink头。
    if err := decoded.UnmarshalBinary(outer.Data); err != nil { return err }
    fmt.Printf("family=%d command=%d version=%d\n",
        uint16(outer.Header.Type), decoded.Header.Command, decoded.Header.Version)
    return nil
}

func main() {
    // 示例不打开socket、不发送消息，也不读取真实内核响应。
    if err := demo(); err != nil { log.Fatal(err) }
}

按示例赋值，外层类型应是十进制49，内层命令是7，版本是1；这是构造推导，不是本机运行记录。示例只构造外层Go对象，没有把它序列化成可直接发送的完整Netlink字节流；真实收发应让Conn处理长度、序列号和端口ID等外层信息。

错误处理要能指出是哪一层

如果族发现失败，先处理当前系统是否存在这个族；如果族存在但命令不支持，应检查协议版本和命令定义；如果载荷解析失败，应看属性区域或族专用头布局。把这些问题都归成“Type错误”，会使调用方不知道应该更新发现信息还是修改请求格式。

还有一个重要例外：外层Type也承载Netlink控制消息类型，例如错误和完成通知。不能对接收到的每一条低层消息都无条件把Type当业务族ID，更不能一律从Data开头读Generic命令。使用genetlink高层接口时，应先处理它返回的错误；自写低层收发才需要额外承担控制消息分类。

Command也不保证在回复中机械回显请求值。回复操作、通知命令和属性集合需要按目标族协议解释。外层请求关联与内层业务语义是两项职责，序列号匹配不能替代载荷类型判断。

接口交付时保留编号来源

在业务封装中，建议保留族名称、发现得到的族ID、命令常量及采用的协议版本约定。日志可记录这些元数据和错误阶段，避免无必要地记录完整属性内容。重连或模块生命周期变化后，动态发现结果也应纳入应用的刷新策略。

NETLINK_GENERIC的16就是目标族ID吗？

不是。NETLINK_GENERIC用于打开相应Netlink协议的socket；消息中的族ID负责在该协议内选择子系统。它与某些编号恰好相同，也不代表两个字段可以互换。

可以把uint8命令转换为HeaderType就发送吗？

Go类型转换可能通过编译，但业务含义仍错误。外层Type需要目标族标识，命令属于内层Command，强制转换不会修复层级混淆。

RTM_GETLINK也要放到Generic Command里吗？

不能直接这样套用。它属于NETLINK_ROUTE的Classic Netlink消息体系，需按相应协议组织，而不是给任意Generic族发送这个数值。

依据：genetlink v1.4.0封装实现、Go接口文档、Linux Netlink分层与控制消息说明。