Go高并发I/O核心是goroutine+net.Listener组合：Accept后立即go handleConn，需设读写超时、用sync.Pool复用bufio、禁用syscall事件循环。
goroutine + net.Listener 是高并发 I/O 的基础组合
Go 的网络服务能轻松支撑数万连接，并非靠线程池或事件循环，而是靠 net.Listener.Accept() 返回的连接直接丢进 goroutine 处理。每次 Accept() 得到一个 net.Conn，立刻用 go handleConn(conn) 启动协程 —— 这是标准范式，也是性能起点。
常见错误是把 handleConn 写成同步阻塞逻辑（比如没设 SetReadDeadline 就死等 Read()），导致 goroutine 卡住不退出，连接一多就内存暴涨、调度延迟升高。
-
ListenAndServe内部已自动为每个连接启 goroutine，自定义 server 时务必手动做同样事 - 别在
handleConn里直接调conn.Close()后继续读写；应配合defer conn.Close()或显式控制生命周期 - HTTP/1.1 的 keep-alive 连接会复用同一个
net.Conn多次请求，不能简单“读一次就关”
io.Copy 和 context.WithTimeout 配合才能安全处理长连接
直接用 io.Copy(dst, src) 转发数据很简洁，但若客户端突然断网或静默挂起，Copy 会无限阻塞在 Read() 上，对应 goroutine 永久泄漏。必须结合上下文超时控制。
典型做法是在 handleConn 开头创建带超时的 context：ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)，再用 http.TimeoutHandler（HTTP 场景）或手动检查 ctx.Err() 控制读写循环。
立即学习“go语言免费学习笔记（深入）”；
-
net.Conn本身支持SetReadDeadline/SetWriteDeadline，比 context 更底层、更轻量，适合 TCP 层精细控制 -
io.Copy不感知 context，需换用io.CopyN+ 循环 +select判断 ctx.Done() - HTTP Server 中，
http.Server.ReadTimeout和WriteTimeout只作用于请求头/响应头阶段，body 传输仍需额外控制
sync.Pool 缓存 bufio.Reader/Writer 可显著降低 GC 压力
每秒处理几千连接时，频繁 new bufio.NewReader(conn) 和 bufio.NewWriter(conn) 会快速触发 GC，表现为周期性 STW 延迟毛刺。用 sync.Pool 复用缓冲区实例是 Go 生产服务的标配优化。
注意 sync.Pool 中对象无所有权保证，取出后必须重置状态（如调用 Reset(io.Reader)），且不能在 goroutine 退出后还持有对 pool 对象的引用。
- 推荐 Pool 的 New 字段返回已初始化好缓冲大小（如 4KB）的
bufio.Reader - 用完必须调
pool.Put(reader)，否则等于内存泄漏 - 不要把
net.Conn放进 Pool —— 它不是可复用资源，且生命周期由上层控制
epoll/kqueue 是 runtime 自动启用的，你不需要也不应该碰 syscall
有人试图用 syscall.EpollWait 手写事件循环来“榨取更高性能”，这在 Go 里是徒劳且危险的。Go runtime 在 Linux/macOS 下早已通过 runtime.netpoll 封装了 epoll/kqueue，并在 net.Conn.Read 等阻塞点自动注册/反注册 fd —— 所有这些对用户透明。
强行绕过 net 包直操作 syscall，会破坏 goroutine 与网络 fd 的绑定关系，导致调度器无法唤醒等待中的 goroutine，最终服务卡死。
- 所有标准库 net/http、net/rpc、grpc-go 都构建在这套机制之上，兼容性和稳定性远超手写
- 真正瓶颈通常不在事件分发层，而在业务逻辑、序列化（JSON）、数据库查询或锁竞争
- 想压测真实性能？优先改
GOMAXPROCS、调优 GC 参数、检查pprof中的 mutex contention 和 allocs/op
高并发 I/O 的复杂点从来不在“怎么启动 goroutine”，而在于连接生命周期管理、超时传播路径是否完整、缓冲区复用是否真正生效——这些细节一旦漏掉一处，流量高峰时的表现就是不可预测的延迟抖动或 OOM。
