setreadbuffer 仅设置内核 socket 接收缓冲区（so_rcvbuf），不直接等同于 tcp 接收窗口（rcv_wnd）；窗口由内核根据空闲缓冲、rtt、拥塞状态动态通告，且需在连接建立后、首次读取前调用才有效，否则可能被忽略或截断。
为什么 SetReadBuffer 调用后 net.Conn 读缓冲区没变大？
常见现象是调用了 conn.SetReadBuffer(64 * 1024)，但用 ss -i 或 netstat -n -tul 查看 TCP 接收窗口（rcv_wnd）仍卡在默认值（如 212992 字节），甚至更小。这不是 Go 的 bug，而是底层 socket 缓冲区和 TCP 窗口的两层概念被混淆了。
Go 的 SetReadBuffer 只影响内核 socket 的接收缓冲区（SO_RCVBUF），而 TCP 窗口大小由内核根据当前缓冲区空闲空间、RTT、拥塞状态动态通告，不是静态等于缓冲区大小。也就是说：你设了 buffer，不代表对端就按这个值发包。
- 必须在
conn建立后、首次读取前调用SetReadBuffer，否则部分系统（如 Linux）会忽略 - 实际生效值可能被内核截断——Linux 会将用户设置值翻倍（用于元数据），再与
/proc/sys/net/core/rmem_max比较取小值 - 若连接已开始收包，缓冲区已被占用，新设置不会清空已有数据，也不会立刻扩大通告窗口
Linux 下 SetReadBuffer 和 /proc/sys/net/ipv4/tcp_rmem 冲突怎么办？
当 Go 设置的值超过 tcp_rmem 中间值（默认 262144），或低于最小值（默认 4096），内核会静默修正。比如你设 1MB，但 tcp_rmem 是 “4096 262144 6291456”，那最终 SO_RCVBUF 最大只能到 262144×2 = 524288 字节（内核双倍机制）。
- 查当前限制：
cat /proc/sys/net/ipv4/tcp_rmem（格式：min default max） - 临时放宽上限：
echo "4096 524288 8388608" > /proc/sys/net/ipv4/tcp_rmem - Go 中建议设为
tcp_rmem中间值的 0.8 倍左右，留余量给内核管理开销，例如中间值 524288 → 设conn.SetReadBuffer(419430) - 注意：修改
tcp_rmem影响全局所有 TCP 连接，生产环境需压测验证
高吞吐场景下只调 SetReadBuffer 不够，还得配 SetWriteBuffer 和 SetKeepAlive
单向加大读缓冲区，写侧若阻塞或延迟 ACK，会反向抑制接收窗口增长。尤其在长连接 + 小包高频交互（如 MQTT、gRPC 流）中，写缓冲区不足会导致 Write 阻塞，进而让内核不敢通告大窗口。
立即学习“go语言免费学习笔记（深入）”；
- 写缓冲区同样要设：比如
conn.SetWriteBuffer(256 * 1024)，避免因应用层未及时Flush导致发送队列积压 - 启用保活：
conn.SetKeepAlive(true)并设合理周期（如 30 秒），防止中间 NAT/防火墙因空闲超时断连，导致窗口重置 - 禁用 Nagle：
conn.SetNoDelay(true)，避免小包合并延迟，这对低延迟要求的场景（如实时信令）关键 - 别忘了超时控制：
conn.SetReadDeadline和SetWriteDeadline必须设，否则大缓冲区下出错时 hang 更久
SetReadBuffer 在不同 Go 版本和平台上的行为差异
Go 1.17+ 对 SetReadBuffer 的错误处理更严格：若系统调用失败（如权限不足、值超限），会直接返回 error；而旧版本可能静默失败。macOS 和 Windows 的 socket 缓冲区策略也不同——macOS 默认 SO_RCVBUF 上限更低，且不支持自动扩容。
- Linux：支持动态调整，但受
rmem_max和tcp_rmem双重限制 - macOS：默认
SO_RCVBUF上限约 1MB，且无法通过 sysctl 提升（需改内核参数kern.ipc.maxsockbuf） - Windows：依赖
SO_RCVBUF，但 TCP 自适应窗口（RFC 1323）开启与否影响更大，建议确认注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnablePMTUDiscovery为 1 - 务必检查返回值：
err := conn.SetReadBuffer(size); if err != nil { log.Printf("set read buffer failed: %v", err) }
真正起作用的从来不是某个 buffer 数值，而是它在整个 TCP 栈中的位置：是否匹配你的 RTT、丢包率、应用消费速度。设大了撑不住，设小了压不住流量，中间那个平衡点得靠 ss -i 抓真实 rcv_wnd 和 unacked，而不是只信代码里写的数字。
