conn.read挂起goroutine而非卡死线程，因其底层调用gopark()将g注册到socket的polldesc并释放m去执行其他g；触发条件是内核socket缓冲区为空时走netpoll流程，避免忙轮询。
conn.Read 为什么会挂起 Goroutine 而不卡死线程
因为 Go 的 conn.Read 看似同步，实则底层调用了 gopark() 让当前 Goroutine 进入等待状态，并把它的地址注册到对应 socket 的 pollDesc 中——这个过程和 epoll 的事件注册完全绑定。M（OS 线程）立刻被释放去执行其他 G，而不是阻塞空转。
常见错误现象：
– 写了个简单 HTTP server，连接数一过万就 CPU 暴涨、响应延迟飙升
– pprof 显示大量 Goroutine 停在 net.(*conn).Read，但 runtime.MemStats 里堆内存没涨 —— 这其实是健康的表现，说明它们真正在“等数据”，不是泄漏
- 关键点：挂起的是 G，不是 M；一个 M 可以轮转成千上万个 G
- 触发条件：只要内核 socket 缓冲区为空，
conn.Read就会走 netpoll 流程，不会做忙轮询 - 别手动加
time.Sleep或for {}等待，那会把 G 锁死在 M 上，彻底废掉调度优势
为什么默认 net/http 服务器扛不住百万连接
不是 Goroutine 不够轻，而是默认配置在高频小包、长连接场景下暴露了资源管理短板：buffer 频繁分配、超时缺失、连接未复用、日志/panic 处理拖慢主路径。
典型表现：
– go tool pprof -http=:8080 http://localhost:6060/debug/pprof/heap 显示大量 bytes.makeSlice 占比高
– lsof -i :8080 | wc -l 到 5 万后新建连接变慢，ss -s 显示大量 tw（TIME_WAIT）堆积
- 必须设
ReadTimeout/WriteTimeout，否则空闲连接永远不关，pollDesc不释放 -
http.Server.ReadBufferSize和.WriteBufferSize默认是 4KB，对小请求浪费；建议按业务报文大小预估，如 IM 场景设为 2KB - 启用
TCP_NODELAY：在net.Listen后对 listener 调用SetNoDelay(true)，避免 Nagle 算法攒包 - 禁用
http.DefaultServeMux，自己构造http.ServeMux并关闭server.Handler的自动 panic 捕获（它会分配栈帧）
sync.Pool 缓存 buffer 时容易漏掉的三个细节
sync.Pool 能显著降低 GC 压力，但缓存对象生命周期不匹配或误用 Put/Get 顺序，反而引发内存泄漏或数据污染。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
错误现场：
– 用 pool.Get().(*bytes.Buffer) 后直接 buf.Write()，下次 Get 到的 buffer 里还残留上次数据
– 在 defer 里 Put，但 handler panic 了，defer 没执行，buffer 永远回不到池里
– Pool.New 返回了带初始 cap 的 slice，但没清零底层数组，导致后续 Write 覆盖旧内容
-
Get后务必调用buf.Reset()，不要依赖buf.Truncate(0)（它不清底层数组） -
Put必须在函数退出前明确执行，推荐写成defer pool.Put(buf)+recover()捕获 panic 后再Put -
New函数里返回&bytes.Buffer{}即可，别预分配大 buffer；真正需要时用buf.Grow(n)
想绕过 net/http 直接用 epoll，真有必要吗
99% 的业务不需要。Go 的 netpoll 已经封装了 epoll/kqueue/iocp，暴露的是语义清晰的文件描述符抽象；手动调用 syscall.EpollCreate1 只在极少数场景有价值：协议解析完全自定义（如自研 L7 负载均衡器）、需精确控制 ET/LT 模式、或要对接 DPDK/XDP 用户态协议栈。
现实陷阱：
– 自己管理 fd 生命周期，close() 忘了调用？fd 泄漏，EMFILE 报错
– epoll_wait 返回多个事件，但只处理第一个就 continue，剩下事件被丢弃
– ET 模式下没一次性读完所有数据，下次 epoll_wait 就再也收不到该 fd 的 EPOLLIN
- 标准库的
net.Conn对象本身已绑定 epoll，你写的每个conn.Read都在触发 netpoll 事件分发 - 如果真要 syscall 层控制，优先用
golang.org/x/sys/unix而不是裸syscall，它更稳定、跨平台兼容更好 - 先用
go tool trace确认瓶颈真在 netpoll 分发层，而不是业务逻辑或 GC —— 大多数时候问题出在json.Unmarshal或数据库查询上
epoll 本身不难懂，难的是理解 Go 如何把它藏得既深又稳：你写同步代码，它替你做事件注册；你起百万 Goroutine，它帮你调度到几个 M 上跑。最常被忽略的，其实是连接生命周期管理 —— Close 调没调、超时设没设、buffer 清没清，这些细节才真正决定并发上限。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
