Go Unix 数据报套接字怎样处理报文边界

如果本地进程之间传递的是一条条独立消息，Go 的 unixgram 比把消息硬塞进字节流更容易保持边界：发送端一次写入对应一个数据报，接收端一次读取拿到一个数据报。真正容易出问题的地方是接收缓冲区，如果它比报文小，应用拿到的只是被截短的 payload。

处理这类套接字时可以记住一句话：用 unixgram 保留消息边界，用足够大的缓冲区承接完整报文；需要确认截断状态时，再读取消息标志。

先把两种边界分开

Unix 域套接字有不同网络名。unix 更接近连续字节流，适合在连接上自行设计长度前缀或分隔符；unixgram 是本地数据报，发送动作天然带着一条消息的边界。Go 文档中的 ListenUnixgram 要求网络名为 unixgram，返回的连接仍然实现了 net.Conn 和数据报读取相关方法。

这意味着接收代码不应该把多次 ReadFromUnix 的结果拼成一条“连续流”再猜分隔符。每次读取先处理当前报文，然后再进入下一次读取；消息协议中的请求编号、类型和校验字段也应该在这一次读取里完成判断。

用 ListenUnixgram 接收一个完整数据报

服务端可以先绑定一个 net.UnixAddr，再使用 ListenUnixgram。接收时优先用 ReadFromUnix，因为它同时返回读取字节数、发送方地址和错误。示例里的缓冲区只是演示尺寸，真实项目应该根据协议允许的最大报文长度确定它。

package main

import (
	"fmt"
	"net"
)

func main() {
	addr := &net.UnixAddr{Name: "/tmp/notify.sock", Net: "unixgram"}
	conn, err := net.ListenUnixgram("unixgram", addr)
	if err != nil {
		// 绑定失败通常意味着路径已被占用或当前用户没有权限。
		panic(err)
	}
	defer conn.Close() // 进程退出前释放套接字描述符。

	buf := make([]byte, 2048) // 按协议上限准备一个数据报缓冲区。
	for {
		n, sender, err := conn.ReadFromUnix(buf)
		if err != nil {
			// 读取失败时停止处理，避免把不完整数据当成新消息。
			panic(err)
		}

		payload := buf[:n]
		fmt.Printf("from=%v bytes=%d payload=%q\n", sender, n, payload)
	}
}

ReadFromUnix 的关键不是“把数据读满”，而是把当前数据报复制到传入切片并返回本次复制的字节数。不要像处理 TCP 那样因为第一次读取小于缓冲区长度，就继续读取并把后一个数据报接到前一个数据报后面。

缓冲区太小会发生什么

数据报边界被保留，并不等于 payload 一定完整。假设发送方发出 1200 字节，而接收方只给了 512 字节切片，应用最多只能拿到切片能容纳的部分。后续再次读取会进入下一个数据报，不会把上一次报文的剩余部分补回来。

因此，协议设计时要先确定最大报文长度。缓冲区至少覆盖这个上限；如果报文长度来自不可信输入，则要在发送端限制大小，并在接收端把“容量不足”视为协议错误或丢弃当前消息，不能把被截断的内容继续交给业务层。

还要区分两个概念：make([]byte, 2048) 是用户态本次读取能接收多少；SetReadBuffer 调整的是操作系统接收缓冲区。后者可以帮助应对突发流量，但不能把一个已经过小的用户态切片变大，也不能替业务协议恢复被截掉的 payload。

需要确认截断时用 ReadMsgUnix

只关心正常、小尺寸报文时，ReadFromUnix 足够直观。若协议允许接近上限的报文，或者你必须知道内核是否设置了消息标志，可以使用 ReadMsgUnix。它除了返回复制到 payload 的字节数，还返回带外数据长度、消息 flags 和源地址。

package main

import (
	"fmt"
	"net"
)

func readDatagram(conn *net.UnixConn, maxPayload int) error {
	buf := make([]byte, maxPayload)
	oob := make([]byte, 32) // 预留少量带外数据空间；不用时仍可传空切片。

	n, oobn, flags, sender, err := conn.ReadMsgUnix(buf, oob)
	if err != nil {
		// 让调用方决定重试、记录或关闭连接，不吞掉底层错误。
		return err
	}

	if flags != 0 {
		// flags 是消息级元数据；出现标志时先记录，再决定是否丢弃。
		fmt.Printf("message flags=%d sender=%v\n", flags, sender)
	}
	if n == len(buf) {
		// n 等于容量只能说明切片已填满，是否截断要结合协议上限和 flags 判断。
		return fmt.Errorf("payload may be truncated: capacity=%d", len(buf))
	}

	fmt.Printf("bytes=%d oob=%d payload=%q\n", n, oobn, buf[:n])
	return nil
}

这里的判断刻意写成“可能截断”，因为仅凭 n == len(buf) 无法证明报文一定比缓冲区长：完整报文也可能刚好填满切片。更可靠的做法是让协议规定最大长度，并用 ReadMsgUnix 返回的 flags 配合平台文档判断是否出现截断标志。

把选择收敛成一张清单

最后再强调一次：unixgram 解决的是消息边界，不替你解决消息大小、重试、顺序和校验。把最大报文长度写进协议，把接收缓冲区按上限配置，并对边界情况单独处理，才是稳定的本地数据报实现。

常见问题

ReadFromUnix 会把一次报文拆成多次返回吗？

它按数据报读取，不应按 TCP 的“继续读直到填满”思路拼接结果。是否完整取决于传入切片是否覆盖报文，以及应用是否正确处理截断信号。

SetReadBuffer 能避免 payload 被截断吗？

不能直接避免。它影响操作系统接收队列的容量，用户态切片仍然必须足够大；协议允许的单条消息上限也应受到控制。

什么时候应该改用 unix 而不是 unixgram？

当消息可能很大、需要连续流式传输，或者你愿意自行实现长度前缀与拆包时，可以考虑 unix。如果业务天然是一条条独立通知，unixgram 的边界语义更直接。