Go网络IO吞吐瓶颈90%源于连接管理、内存分配和超时控制失当；须禁用HTTP/2、将Read/Write/IdleTimeout设于Server级、复用bufio.Reader并配合sync.Pool池化、SO_REUSEPORT需匹配GOMAXPROCS，且不可手动设非阻塞。
Go 的网络 IO 吞吐瓶颈，90% 不在 syscall，而在连接管理、内存分配和超时控制失当。盲目加 goroutine 数量或调大 socket 缓冲区，反而会抬高延迟、触发 GC 尖峰、甚至压垮内核连接队列。
http.Server 必须禁用 HTTP/2 并设对超时位置
HTTP/2 默认开启后，每个连接要维护多个 stream 状态，在短连接 API 场景下，GC 压力陡增、goroutine 调度抖动明显。ReadTimeout 和 WriteTimeout 若写在 handler 里（比如用 context.WithTimeout），根本无法中断底层 conn.Read()，只 cancel 掉后续逻辑。
- 初始化
http.Server时显式关闭 HTTP/2：TLSConfig: &tls.Config{NextProtos: []string{"http/1.1"}} -
ReadTimeout、WriteTimeout、IdleTimeout全部设在http.Server实例上，不是 handler 内 - 短连接服务（如网关）建议
IdleTimeout≤ 5s，防 TIME_WAIT 积压；长连接可设为 30–60s
每个连接必须复用 bufio.Reader + sync.Pool
默认 bufio.NewReader(conn) 每次都 new 一个 4KB buffer，千级并发就是 MB 级临时内存，GC 频繁扫描。更糟的是，不池化 reader 会导致每次读取都 malloc 新 slice。
- Accept 后立即调用
conn.SetReadBuffer(64 * 1024)和conn.SetWriteBuffer(64 * 1024) - 用
sync.Pool管理bufio.Reader实例，预分配固定大小的底层[]byte - 示例池化逻辑：
var readerPool = sync.Pool{ New: func() interface{} { buf := make([]byte, 4096) return bufio.NewReaderSize(bytes.NewReader(buf), 4096) }, }注意：实际使用中需封装Reset()调用，并确保归还前清空敏感数据（buf = buf[:0]）
SO_REUSEPORT 需配合 GOMAXPROCS 且仅解决 accept 队列争抢
SO_REUSEPORT 让多个 Go 进程（或多个 runtime.P）能同时 listen 同一端口，缓解内核 accept 队列锁竞争。但它不解决 goroutine 调度倾斜——如果 GOMAXPROCS 远小于 CPU 核心数，多出来的 P 根本不会被调度器启用。
- 启用方式：用
net.ListenConfig{Control: func(fd uintptr) { syscall.SetsockoptInt32(int(fd), syscall.SOL_SOCKET, syscall.SO_REUSEPORT, 1) }} - 务必同步设置
runtime.GOMAXPROCS(runtime.NumCPU())，否则多核无法真正并行处理连接 - 注意：Linux 3.9+ 才支持，macOS 从 10.11 开始支持，Windows 不支持
别碰 SetNonblock，也别自己轮询 epoll
Go 的 net.Conn 底层早已基于 epoll/kqueue 实现非阻塞 IO，所有 Read/Write 调用由 runtime 自动挂起/唤醒 goroutine。手动调用 SetNonblock(true) 不但无效，还可能破坏 netpoll 注册逻辑；用 syscall.Read + for-select 轮询是 C 风格写法，在 Go 里等于倒退。
- 标准写法就是
go handleConn(conn)，每个连接一个 goroutine —— 创建开销约 2KB，远低于线程 - 真正该做的是控制 handler 内耗时操作：数据库查询用
pgx异步驱动，HTTP 调用换fasthttp.Client，正则匹配提前编译 - 高频路径避免
fmt.Sprintf，改用strings.Builder或预分配[]byte
最容易被忽略的点：sync.Pool 中的 buffer 归还前必须清空内容（buf = buf[:0]），否则跨请求泄露数据；而 SO_REUSEPORT 在容器环境里常因 host 网络配置缺失导致静默失效——建议启动时加日志确认 getsockopt SO_REUSEPORT 返回值是否为 1。
