net.Pipe仅用于内存内同步通信，不模拟网络行为；测网络逻辑须用net.Listen+net.Dial或net.ListenUDP，配合超时与连接控制。
net.Pipe 不是 TCP/UDP 模拟，别用它测网络行为
net.Pipe 返回一对同步的、内存内的 Conn，读写直接走 channel 或 buffer，零网络栈参与。它不经过 syscall、不触发包分片、不模拟丢包/延迟/乱序，更不会出现 connection refused 或 timeout 这类真实网络错误。拿它测“TCP重传逻辑”或“UDP丢包恢复”，结果一定误导——你测的其实是 goroutine 通信效率。
常见错误现象：net.Pipe 上调 SetReadDeadline 无效；Write 永远不阻塞（除非缓冲区满）；LocalAddr() 和 RemoteAddr() 返回假地址；抓包看不到任何数据包。
- 适用场景：单元测试协议编解码、状态机流转、应用层帧处理逻辑（比如 HTTP/2 frame 解析）
- 不适用场景：验证超时控制、连接建立/关闭时序、NAT 穿透、拥塞控制反馈、MTU 分片行为
- 性能影响：极快，但和真实网络延迟、buffer 限制、系统 socket 队列完全无关
真 TCP 模拟该用 net.Listen + conn.Dial，配合 timeout 控制
要观察三次握手失败、RST 响应、read timeout、write blocking 等行为，必须走真实 socket。最简方式是启动一个本地 net.Listener，用 net.Dial 连接它，再人为控制 listener 行为。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
net.Listen("tcp", "127.0.0.1:0")获取随机空闲端口，避免端口冲突 - 在
Accept后立即conn.Close()可模拟 connection refused（客户端 dial 会报dial tcp 127.0.0.1:xxxx: connect: connection refused） - 对 client conn 调
SetReadDeadline(time.Now().Add(100 * time.Millisecond))，再读不到数据就会触发io.EOF或timeout错误 - 不要在 listener 上设
SetDeadline—— 它只影响Accept，不是连接行为
示例关键片段：
ln, _ := net.Listen("tcp", "127.0.0.1:0")
go func() {
conn, _ := ln.Accept()
time.Sleep(200 * time.Millisecond) // 故意延迟响应
conn.Write([]byte("hello"))
conn.Close()
}()
client, _ := net.Dial("tcp", ln.Addr().String())
client.SetReadDeadline(time.Now().Add(100 * time.Millisecond))
buf := make([]byte, 10)
n, err := client.Read(buf) // 这里大概率返回 timeoutUDP 模拟必须用 net.ListenUDP，Pipe 完全不适用
net.Pipe 没有地址概念、不支持 WriteTo/ReadFrom，而 UDP 的核心语义就是“无连接 + 显式地址”。想测 sendto 失败、ICMP 目标不可达、接收缓冲区溢出丢包，必须用 net.ListenUDP。
容易踩的坑：
- 监听地址写成
"127.0.0.1:0"是对的，但客户端WriteToUDP必须指定目标 addr，不能传nil（否则 panic） - UDP conn 默认无读写超时，需手动调
SetReadDeadline/SetWriteDeadline - Linux 下 UDP 接收缓冲区默认很小（约 256KB），快速发包会静默丢包 —— 这正是你要测的，别急着调大
sysctl net.core.rmem_max - 用
net.InterfaceByName("lo")+multicast.JoinGroup才能测组播行为，net.Pipe根本不支持
复杂点在于状态隔离：每次测试得 clean up listener & goroutine
每个测试用例启动的 net.Listener 或 net.UDPConn 必须显式 Close()，否则端口残留、goroutine 泄漏，后续测试可能复用旧连接或卡死。Go 的 testing.T.Cleanup 是刚需。
典型遗漏：
- 忘记
ln.Close()导致 “address already in use” 报错 - goroutine 在
Accept或ReadFrom中阻塞，没被 cancel，test 进程 hang 住 - UDP server 用
for循环ReadFrom，但没检查err == nil就继续，导致 EOF 后 panic
所以哪怕只是模拟一次“服务端短暂不可达”，也要确保 listener 启停完整、超时可控、goroutine 可退出 —— 这比写业务逻辑还容易出错。
