Go 的 SetReadBuffer 和 SetWriteBuffer 不一定生效，因底层依赖系统 setsockopt 且受 OS 权限、策略限制；调用后需检查错误，err == nil 不代表设置成功。
Go 的 SetReadBuffer 和 SetWriteBuffer 真的生效吗？
不一定。Go 的 net.Conn 接口确实提供了 SetReadBuffer 和 SetWriteBuffer 方法，但它们只是“尽力而为”——底层调用的是系统 setsockopt(SO_RCVBUF/SO_SNDBUF)，是否成功、最终设成多大，取决于操作系统策略和当前权限。
- Linux 默认限制普通用户进程设置缓冲区上限（通常 212992 字节），超限会静默截断，不报错
- macOS 对
SO_RCVBUF有倍增行为（实际分配 ≈ 2× 设置值），且最小值强制为 4096 - Windows 表现相对稳定，但同样受系统全局配置影响
- 调用后务必检查返回错误：
err != nil才代表明确失败；err == nil不等于“已按预期设置”
什么时候该主动调用 SetReadBuffer？
典型场景是处理高吞吐、低延迟的 TCP 流（如实时日志转发、行情推送），且你观察到 read 频繁阻塞或 netstat -s | grep "packet receive errors" 出现丢包提示——这往往说明内核接收队列溢出，需要扩大 socket 缓冲区来暂存来不及应用层读取的数据。
- 必须在
conn建立后、首次Read前调用，否则多数系统直接忽略 - HTTP Server / gRPC 等框架通常已内部调优，手动设置反而可能干扰其流控逻辑
- UDP 场景更敏感：小缓冲区 + 高频发包极易丢包，
SetReadBuffer是必要手段 - 建议值参考：TCP 可设为 1MB（
1024 * 1024），UDP 至少 256KB 起步
SetReadBuffer 后读性能没提升？检查这几个点
缓冲区变大 ≠ 应用层读得快。常见瓶颈其实在 Go runtime 层或业务逻辑里。
- 你的
Read调用是否还在用小 buffer（如make([]byte, 1024)）？即使 socket 缓冲区是 1MB，每次只读 1KB，照样频繁 syscall - 是否在循环中反复
Read却没做批量处理？考虑改用bufio.Reader或预分配大 slice - Go 1.19+ 后
net.Conn.Read默认启用io.Copy的优化路径，但若你用了自定义io.Reader包装器，可能绕过该优化 - 用
ss -i（Linux）或netstat -nb（Windows）确认rcv_space/sb_queued是否真被修改，别只信代码逻辑
替代方案：比 SetReadBuffer 更可控的缓冲策略
直接调系统 socket 选项受限太多，更稳的做法是把缓冲逻辑收归应用层。
立即学习“go语言免费学习笔记（深入）”；
- 对写操作：用
bufio.Writer包装conn，控制 flush 触发时机和 buffer 大小，比依赖SO_SNDBUF更可预测 - 对读操作：启动 goroutine 持续
Read到大 buffer，再通过 channel 或 ring buffer 推给业务逻辑，解耦内核缓冲与消费速度 - UDP 场景可考虑
golang.org/x/net/ipv4的PacketConn，它支持SetControlMessage精确控制 IP 层行为 - 极端场景（如金融行情）需确定性延迟，干脆关掉 Nagle 算法：
conn.(*net.TCPConn).SetNoDelay(true)，比调缓冲区更关键
缓冲区大小不是越大越好，内核分配的是物理内存页，盲目设到几十 MB 可能触发 OOM Killer；真正要盯的是 ss -m 里每个连接的 rcv_wscale 和 rcv_ssthresh，它们才反映 TCP 实际窗口行为。
