net.Conn.Read 卡住但不报错，主因是对端未发数据、TCP窗口为0或本地缓冲区满；需设ReadDeadline、查Recv-Q、用go tool trace分析IO wait态。
为什么 net.Conn.Read 会卡住，但没报错？
这是最常被误判为“网络断开”的假象。实际可能是对端未发送数据、TCP窗口缩为0、或本地接收缓冲区已满且应用层未及时读取。Go 的 Read 默认阻塞，不会因超时自动返回错误，除非设置了 SetReadDeadline。
- 先确认是否设置了读超时：
conn.SetReadDeadline(time.Now().Add(5 * time.Second))
- 检查
Read返回值：若n == 0 && err == nil，说明连接已关闭（FIN）；若err != nil且是net.ErrTimeout或io.EOF，才可明确归因 - 用
ss -i或netstat -s | grep -A 5 "Tcp:"查看系统 TCP 接收队列是否堆积（Recv-Q持续非零）
runtime/pprof 抓不到 I/O 瓶颈？试试 go tool trace
pprof 主要反映 CPU 和堆分配热点，而网络 I/O 阻塞往往发生在 goroutine 调度等待态，pprof 的 goroutine profile 只拍快照，容易漏掉瞬时阻塞。真正有效的是运行时 trace：
- 启动时加
runtime.StartTrace()，或通过 HTTP pprof 接口触发：curl http://localhost:6060/debug/pprof/trace?seconds=10 -o trace.out
- 用
go tool trace trace.out打开后，重点关注 “Goroutine analysis” → “Blocking profile”，看哪些 goroutine 长时间处于IO wait状态 - 注意 trace 中的
network poller事件：如果大量 goroutine 堆在同一个 file descriptor 上，说明该连接或监听器成了瓶颈
高并发下 epoll_wait 调用延迟升高，是不是内核问题？
不一定。Go 运行时的网络轮询器（netpoll）确实基于 epoll（Linux），但延迟升高更常源于用户层逻辑干扰：
- 每个 goroutine 调用
Read/Write时，若处理逻辑耗时（如 JSON 解析、DB 查询），会导致该 goroutine 长时间占用 M，间接拖慢 netpoll 循环频率 - 检查
GOMAXPROCS是否过低：若远小于 CPU 核心数，netpoll goroutine 和用户 goroutine 会争抢 P，造成轮询延迟 - 用
perf record -e syscalls:sys_enter_epoll_wait -a sleep 5看单次epoll_wait耗时，若普遍 >100μs，再查内核参数（如/proc/sys/net/core/somaxconn是否过小）
用 bufio.Reader 就一定能提升吞吐？
不能一概而论。它只在「小包高频」场景下有效（如 Redis 协议解析），但会引入额外内存拷贝和边界判断开销：
立即学习“go语言免费学习笔记（深入）”；
- 当单次
Read已能拿到完整业务包（如 HTTP/2 frame 或 Protobuf 消息），加bufio反而多一次 copy -
bufio.Reader的ReadSlice在找不到分隔符时会不断扩容 buffer，可能触发 GC 压力；改用ReadBytes或自定义定长读取更可控 - 真实瓶颈常在协议解析层（如
json.Unmarshal），建议先用go tool pprof -http=:8080 binary cpu.pprof确认热点再决定是否加缓冲
关键点在于：I/O 瓶颈很少孤立存在，它总和 goroutine 调度、内存分配、协议设计耦合在一起。盯着 Read 超时看，不如打开 trace 看 goroutine 等在哪、等了多久。
