Go netlink Execute与Send加Receive有什么区别

在 github.com/mdlayher/netlink 中，Execute 不是另一套通信协议，而是把一次标准的“发送请求、接收回复、校验回复”组合起来。Send 只负责把一条 Message 发出去，Receive 负责把一条或多条回复读回来；如果把这两个方法拆开，就能在中间插入自己的超时、日志或校验策略。

官方地址：https://pkg.go.dev/github.com/mdlayher/netlink

简单的请求-回复优先用 Execute；只有当你确实需要控制收发边界、使用 Send 返回的已填充消息头，或者调整 Validate 的时机时，才拆成 Send 加 Receive。两种写法都不会把 multipart 回复自动变成单条消息。

先按职责拆开三个方法

可以把 Conn 看成 netlink socket 的操作入口。它提供的三个方法层级不同：

• Send(m)：发送一条消息；成功时返回一份消息副本，未填写的 Length、Sequence、PID 等头字段会被补齐。
• Receive()：接收一条或多条消息；multipart 回复会被透明收集，最后的 multipart done 消息不会出现在返回切片中。
• Execute(m)：内部组合前两个动作，再用 Validate 检查回复与请求是否匹配，返回 []Message。

因此，Execute 与 Send 加 Receive 的主要区别不在“能不能收到回复”，而在“谁负责把动作组合起来，以及谁掌握中间的控制点”。

用 Execute 完成标准请求-回复

当一个调用可以概括为“构造一条请求，等待完整回复，按库的规则校验”时，Execute 是更短的表达。下面的示例只展示 API 契约，具体的 netlink family 载荷由调用方按目标协议填充：

package main

import "github.com/mdlayher/netlink"

func requestOnce(conn *netlink.Conn, request netlink.Message) ([]netlink.Message, error) {
	// Execute 统一完成发送、接收和请求/回复匹配校验。
	replies, err := conn.Execute(request)
	if err != nil {
		// netlink 错误或回复校验失败都会沿调用链返回。
		return nil, err
	}
	// replies 可能包含多条消息，不能假定必定只有一条。
	return replies, nil
}

这个写法适合读取一组对象、查询一个属性集合，或者调用方并不需要观察发送之后到接收之前的状态。返回值是消息切片，而不是单个消息，原因是协议可能把一个逻辑回复拆成 multipart。

用 Send 加 Receive 保留控制权

拆开写法时，关键不是把 Execute 机械展开，而是接住 Send 返回的消息副本。官方文档说明，发送成功后这份副本包含自动填充后的头部参数，可以交给 Validate 与回复做匹配：

func requestWithManualBoundary(conn *netlink.Conn, request netlink.Message) ([]netlink.Message, error) {
	// Send 会补齐需要由连接管理的消息头，并返回用于后续匹配的副本。
	sent, err := conn.Send(request)
	if err != nil {
		return nil, err
	}

	// Receive 负责收集普通回复和 multipart 回复，并传播 netlink 错误。
	replies, err := conn.Receive()
	if err != nil {
		return nil, err
	}

	// 手动模式不会替你调用 Validate，需要明确保留这一步。
	if err := netlink.Validate(sent, replies); err != nil {
		return nil, err
	}
	return replies, nil
}

与 Execute 等价的核心链路是：request 进入 Send，得到带有连接级字段的 sent，再让 Receive 得到 replies，最后用同一个 sent 做校验。不要在校验时重新使用尚未填充头部的原始 request，否则你丢掉了发送阶段产生的匹配信息。

把超时和收发边界放到正确位置

拆开的价值通常来自收发之间的差异化控制。例如写入和读取可能需要不同的 deadline，可以在对应动作前设置：

func requestWithDeadlines(conn *netlink.Conn, request netlink.Message) ([]netlink.Message, error) {
	// 写入阶段使用较短的截止时间，避免发送动作无限等待。
	if err := conn.SetWriteDeadline(writeDeadline()); err != nil {
		return nil, err
	}
	sent, err := conn.Send(request)
	if err != nil {
		return nil, err
	}

	// 读取 multipart 回复时使用独立的读取截止时间。
	if err := conn.SetReadDeadline(readDeadline()); err != nil {
		return nil, err
	}
	replies, err := conn.Receive()
	if err != nil {
		return nil, err
	}
	if err := netlink.Validate(sent, replies); err != nil {
		return nil, err
	}
	return replies, nil
}

这里的重点是位置：SetWriteDeadline 约束写入，SetReadDeadline 约束读取。示例中的 writeDeadline 和 readDeadline 代表调用方已有的时间策略，文章不假设具体时长。若两段使用同一个整体截止时间，直接在调用 Execute 前设置 SetDeadline 往往更简单。

理解 multipart 与错误返回

Receive 的返回类型是 []Message，不是因为手动模式才会收到多条，而是 netlink 回复本来就可能是 multipart。Execute 内部同样调用 Receive，所以它也会把多段回复整理成切片。

两种写法都应把错误当作本次请求没有得到可用回复来处理：

• Send 返回错误时，不要继续调用 Receive 假设请求已经发出。
• Receive 返回错误时，先处理错误，不要把不完整的消息切片当作成功结果。
• 手动模式如果跳过 Validate，就失去了对回复 PID 和序列匹配的检查；只有在调用方明确接管匹配策略时才这样做。

如果使用 ReceiveIter 逐项消费 multipart 回复，还要注意在未读完时停止迭代会丢弃剩余多段消息；这属于另一种消费策略，不改变本文对 Execute 与 Send 加 Receive 的基本比较。

按场景做选择

可以记成一句话：Execute 面向“完成一次标准事务”，Send 和 Receive 面向“拆开掌控一次通信”。拆开以后不要重复发送同一条请求，也不要因为 Receive 返回了消息就省略 Validate。

常见问题

Execute 只会返回一条 Message 吗？

不会。它返回 []Message，并使用 Receive 处理 multipart 回复，因此调用方应按切片处理结果。

Send 成功后可以直接把原始 request 传给 Validate 吗？

更稳妥的做法是使用 Send 返回的副本，因为该副本包含发送阶段自动填充的消息头字段。

手动调用 Receive 是否等于关闭校验？

不等于。Receive 负责接收和错误传播；是否把回复与请求的 PID、序列等信息进行匹配，仍要由调用方调用 Validate 或实现明确的等价策略。