Go网络编程常见坑包括：conn.Read/Write忽略返回值n导致解析错误；ListenAndServe后未优雅shutdown引发连接中断；HTTP handler中goroutine未传context致泄漏；TCP长连接未设KeepAlive或动态超时致黑盒故障。
Go 网络编程里最常踩的坑，不是语法写错，而是对 net.Conn 生命周期、io.Read 行为、超时控制粒度这些底层语义理解偏差导致的——连接卡死、goroutine 泄漏、粘包误判、panic 无法 recover。
Read/Write 没检查返回值就直接用
Go 的 conn.Read() 和 conn.Write() 都返回 (n int, err error)，但很多人只关注 err，忽略 n。比如：
-
n == 0 && err == nil是合法状态（如对方关闭写端但未关闭连接），不代表数据读完了 n 不一定出错，TCP 是流式协议，一次Read()只保证返回「当前可读」的数据，可能只有几个字节- 直接拿
buf[:n]做后续解析没问题，但若用buf全长去解码（比如 JSON.Unmarshal(buf)），就会解错或 panic
buf := make([]byte, 1024)
n, err := conn.Read(buf)
if err != nil {
// 处理 err（包括 io.EOF）
return
}
// ✅ 正确：只处理已读取部分
data := buf[:n]
json.Unmarshal(data, &req)
// ❌ 错误：假设 buf 已满
json.Unmarshal(buf, &req) // 可能解到脏数据
ListenAndServe 后没做 graceful shutdown
http.ListenAndServe() 或 http.Server.Serve() 是阻塞调用，但进程退出时若不主动 Shutdown()，正在处理的请求会被粗暴中断，连接重置，客户端收不到响应。
-
Server.Shutdown()必须传入带超时的context.Context，否则会永久等待活跃连接结束 - 要先关闭 listener（避免新连接接入），再等已有连接自然完成或超时
- 信号监听（如
os.Interrupt）必须在Shutdown()调用后才退出，否则 goroutine 泄漏
srv := &http.Server{Addr: ":8080", Handler: mux}
go func() {
if err := srv.ListenAndServe(); err != http.ErrServerClosed {
log.Fatal(err)
}
}()
// 收到 SIGINT 后
sig := make(chan os.Signal, 1)
signal.Notify(sig, os.Interrupt)
<-sig
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
srv.Shutdown(ctx) // ✅ 主动触发优雅关闭
HTTP handler 里启动 goroutine 却没传 context 或管理生命周期
在 http.HandlerFunc 中用 go doSomething() 是常见模式，但极易引发 goroutine 泄漏或访问已释放变量：
- handler 返回后，request scope 的
*http.Request和http.ResponseWriter不再安全，goroutine 若继续读写它们会 panic 或写失败 - 没绑定
context.Context，无法感知 client 断连或 timeout，任务可能永远跑下去 - 没做并发控制（如 worker pool），突发流量会瞬间起成百上千 goroutine，OOM
func handler(w http.ResponseWriter, r *http.Request) {
// ❌ 危险：r.Body 在 handler 返回后不可读
go func() {
body, _ := io.ReadAll(r.Body) // 可能 panic 或读空
process(body)
}()
// ✅ 安全做法：复制必要数据 + 用 request.Context()
data := make([]byte, r.ContentLength)
r.Body.Read(data) // 同步读完
go func(ctx context.Context, d []byte) {
select {
case <-time.After(5 * time.Second):
process(d)
case <-ctx.Done():
return // client 断开，主动退出
}
}(r.Context(), data)}
TCP 连接复用时忘记 SetKeepAlive 或 Read/Write 超时
长连接场景（如 MQTT client、自定义 RPC）中，若网络中间设备（NAT、防火墙）静默丢弃空闲连接，而 Go 端没探测，就会出现「连接看似正常，实际发包失败」的黑盒问题。
-
conn.SetKeepAlive(true)开启 TCP keepalive，但默认间隔是 2 小时（Linux），远超多数中间设备超时阈值 -
conn.SetDeadline()是一次性设置，每次Read()/Write()前都得重设；更推荐用SetReadDeadline()/SetWriteDeadline()配合业务逻辑动态更新 - 仅设
WriteDeadline不够：对方崩溃后，本端Write()仍可能成功（数据进内核缓冲区），直到下次Read()才发现连接异常
conn, _ := net.Dial("tcp", "api.example.com:80")
conn.SetKeepAlive(true)
conn.SetKeepAlivePeriod(30 * time.Second) // ⚠️ 注意：Go 1.19+ 才支持该方法
// 更通用做法：每次读前设 deadline
for {
conn.SetReadDeadline(time.Now().Add(10 * time.Second))
n, err := conn.Read(buf)
if err != nil {
if netErr, ok := err.(net.Error); ok && netErr.Timeout() {
// 处理超时
}
break
}
}
真正难的不是写出能跑的网络代码，而是预判连接在各种异常路径下的行为——比如三次握手失败、SYN flood、RST 包乱序到达、TIME_WAIT 状态堆积。这些不会在本地测试暴露，只在高并发、弱网、混部环境下集中爆发。
