Go网络IO优化核心是理解其原生“非阻塞+协程化”设计：net.Conn默认由runtime透明管理，无需手动设非阻塞或协程池；性能瓶颈多在业务逻辑、内存分配与资源使用，而非IO模型本身。
在 Go 中优化网络 IO，核心不是强行套用“非阻塞模式”或“协程池”这类术语，而是理解 Go 原生网络模型的设计哲学：net.Conn 默认就是非阻塞的（由 runtime 调度层透明管理），而 goroutine 本身就是轻量级、按需创建的“协程”，通常无需手动维护协程池。盲目引入额外抽象反而可能降低性能、增加复杂度。
Go 的网络 IO 本质已是“非阻塞 + 协程化”
Go 的 net 包底层基于 epoll（Linux）、kqueue（macOS）或 IOCP（Windows），所有阻塞式方法（如 conn.Read()、conn.Write()、listener.Accept()）在 runtime 层被自动转换为异步等待 + goroutine 挂起/唤醒。你写的同步代码，实际运行时不会阻塞 OS 线程。
- 不需要调用
SetNonblock(true)—— Go 运行时不依赖该标志，手动设置还可能破坏调度逻辑 - 不需要用
syscall.Read/Write配合 for-select 循环轮询 —— 这是 C/Node.js 的做法，在 Go 里属于倒退 - 每个连接启动一个 goroutine（
go handleConn(conn)）是标准且高效的做法，goroutine 创建开销约 2KB 栈空间，远低于线程
真正影响性能的关键点
瓶颈往往不出现在 IO 模型本身，而在业务逻辑、内存分配和系统资源使用上：
- 避免在 handler 中做同步耗时操作：如直接调用数据库同步查询、调用 HTTP 同步客户端、大量正则匹配等。应改用异步驱动（如 pgx、fasthttp.Client）或 offload 到 worker goroutine
-
复用缓冲区和对象：频繁 new/drop []byte 或 struct 会加剧 GC 压力。使用
sync.Pool缓存读写 buffer（如bufio.Reader/Writer）、解包结构体实例 -
控制并发规模，而非协程数量：用带缓冲 channel 或 semaphore（如
golang.org/x/sync/semaphore）限制同时处理的请求数，防止单机过载，比“协程池”更语义清晰 -
启用 TCP KeepAlive 和合理超时：防止连接堆积、及时释放僵尸连接。例如：
ln, _ := net.Listen("tcp", ":8080")
tcpLn := ln.(*net.TCPListener)
tcpLn.SetKeepAlive(true)
tcpLn.SetKeepAlivePeriod(3 * time.Minute)
何时需要自定义“协程池”？
极少数场景下，比如服务需长期维持数万长连接，且每个连接周期性触发 CPU 密集型任务（如加解密、音视频转码），此时可考虑固定 worker goroutine 池来复用执行上下文、减少调度抖动：
立即学习“go语言免费学习笔记（深入）”；
- 用
chan job分发任务，固定 N 个 goroutine 消费（N ≈ GOMAXPROCS） - 注意：这不是替代 net/http 的 handler 模型，而是对连接内特定子任务的优化
- 避免全局大池子——按业务域隔离（如 auth pool、codec pool），防止互相干扰
推荐实践组合
- HTTP 服务：优先用
net/http（已高度优化），配合http.Server.ReadTimeout、WriteTimeout、IdleTimeout - 高性能 TCP/UDP：用
net.Conn+bufio+sync.Pool，handler 内只做协议解析与快速响应 - 连接密集型：启用
SO_REUSEPORT（Go 1.19+ 支持net.ListenConfig{Control: reusePort}），让多个进程/线程分担 accept - 可观测性：通过
http/pprof抓取 goroutine profile，确认是否真有 goroutine 泄漏或阻塞
