Go net.Pipe 写入少量数据为什么也会阻塞

Go 里用 net.Pipe 做协议测试时，Write([]byte("ok")) 也可能一直不返回。原因通常不是消息太大，而是 net.Pipe 没有内部缓冲：一端的写入要和另一端的读取同步完成。若同一个 goroutine 先写后读，或者对端根本没有进入 Read，少量数据同样会卡住。

把 net.Pipe 当成“内存里的同步连接”即可。需要让对端并发读取；如果业务必须允许等待，就设置写入/读取 deadline，并在协议结束时关闭连接。

net.Pipe 为什么不看数据量

net.Pipe() 返回两个实现了 net.Conn 的端点。官方文档把它定义为 synchronous、in-memory、full duplex connection，并明确说明没有 internal buffering。也就是说，左端写入的数据不是先放进一个容量未知的缓存，再等右端慢慢读取；它会直接寻找右端的读取操作。

实现上，写端把字节交给对端的读取通道，然后等待对端报告实际复制了多少字节。读端没有出现时，写端就没有完成交接的条件。因此“只写 2 个字节应该立刻返回”这个判断并不适用于 net.Pipe。

先查是不是同一个 goroutine 先写后读

最常见的死等结构如下：当前 goroutine 调用 a.Write，但只有它返回后才会调用 b.Read。由于 a 和 b 是一对相连端点，写入正在等读取，读取又被排在写入返回之后，双方自然无法前进。

package main

import "net"

func wrongOrder(a, b net.Conn) error {
	// 这里会等待 b.Read，但 b.Read 还没有机会执行。
	_, err := a.Write([]byte("ok"))
	if err != nil {
		return err
	}
	// 只有 Write 返回后才到这里，形成自我等待。
	buf := make([]byte, 2)
	_, err = b.Read(buf)
	return err
}

排查时先看三个位置：Write 所在的 goroutine 是否还承担读取、另一端是否真的拿到了对应连接、测试失败时是否只打印了“写入卡住”而没有记录 deadline 或关闭错误。若把 net.Pipe 换成带缓冲的对象后现象消失，也只能说明缓冲掩盖了顺序问题，并不表示原来的协议顺序正确。

让读写两端同时存在

最小可用的组织方式是让写入放到 goroutine 中，主流程立即在另一端读取。这里的关键不是“多开一个 goroutine”本身，而是给同步交接提供一个确实会发生的对端 Read，并检查双方返回值。

package main

import (
	"fmt"
	"net"
)

func exchange() error {
	a, b := net.Pipe()
	defer a.Close()
	defer b.Close()

	writeDone := make(chan error, 1)
	go func() {
		// 写端等待对端接收，错误要交回主流程。
		_, err := a.Write([]byte("ok"))
		writeDone 

这段代码没有依赖“消息边界”假设：net.Pipe 只是复制字节，如何划分一条消息仍由协议自己决定。如果真实协议可能一次读不完整，就继续根据长度字段、分隔符或 io.ReadFull 组织读取，不要把一次 Read 当成一条完整消息。

用 deadline 和 Close 拦住永久阻塞

测试代码和服务代码都不应把无限等待当成正常的失败处理方式。net.Conn 提供 SetDeadline、SetReadDeadline 和 SetWriteDeadline；对 net.Pipe 而言，这些设置会让等待中的读或写在截止时间到达后返回超时错误。

deadline := time.Now().Add(500 * time.Millisecond)
if err := a.SetWriteDeadline(deadline); err != nil {
	return err
}
if err := b.SetReadDeadline(deadline); err != nil {
	return err
}

// 进入协议结束或取消分支时，关闭会唤醒另一端的等待。
defer a.Close()
defer b.Close()

检查错误时不要只比较错误字符串。写端超时通常可以用 errors.Is(err, os.ErrDeadlineExceeded) 判断；对端关闭可能得到 io.EOF 或 io.ErrClosedPipe，具体取决于正在执行的是读还是写。deadline 是一次截止时间设置，下一轮交互需要时要重新设置或清零。

常见问题

net.Pipe 有类似 TCP 的内核发送缓冲吗？

没有。它是进程内的同步内存连接，不经过 TCP 内核缓冲；写入完成依赖另一端接收。

把消息改小就能解决阻塞吗？

通常不能。只要没有匹配的 Read，很小的字节切片也会等待；应先修正读写并发关系。

为什么要同时关闭两个端点？

两个端点分别拥有本地关闭状态。协议结束时显式关闭两端，能让仍在等待的读写尽快收到可判断的结束错误。

所以，看到 net.Pipe 的小消息写入阻塞时，先把问题改写成“对端有没有在读”。确认读写配对后，再用 deadline 限制等待，用 Close 处理取消和结束，这比盲目增加消息缓冲更接近它的设计。