recover不能优雅关闭网络连接，它仅捕获panic而不管理conn生命周期、不保证状态安全，盲目调用conn.Close()易致二次panic或漏关，真正关闭须由context或显式信号统一控制。
recover 不能用来优雅关闭网络连接——它连“关”都做不到，更谈不上“优雅”。
recover 只是 panic 捕获机制，不持有 net.Conn、不控制 goroutine 生命周期、也不参与连接状态管理。试图在 defer + recover 里调用 conn.Close()，大概率会触发二次 panic（比如 conn 已被其他 goroutine 关闭），或漏关（panic 发生时连接正被另一个 goroutine 使用）。
recover 里调 conn.Close() 为什么危险？
-
conn.Close()是并发安全的，但重复调用不会报错，也不会生效；而你无法判断当前是否已有人关过它 - panic 时 goroutine 状态不可控：可能刚写完一半包、正在 select 等待读、或已进入超时清理逻辑
- 如果连接被多个 goroutine 共享（如读/写分离模型），
recover里的Close()可能提前中断另一端的读写循环，导致io.EOF或use of closed network connection错误被误判为网络异常 -
recover不知道 context 是否已取消，也无法通知对端“我要断了”，更不会等缓冲区发完数据
真正可控的连接关闭路径长这样
- 连接生命周期必须由主控流程统一决定，不是错误兜底逻辑
- 所有读写操作必须配合
context.Context和SetReadDeadline/SetWriteDeadline - 主动关闭信号应走显式通道（如
done chan struct{}）或 context 取消，而非依赖 panic 捕获
典型结构：
func handleConn(conn net.Conn, done <-chan struct{}) {
defer conn.Close() // 仅确保资源释放，不承担“优雅”语义
<pre class="brush:php;toolbar:false;">// 每次读前设动态 deadline
for {
conn.SetReadDeadline(time.Now().Add(100 * time.Millisecond))
n, err := conn.Read(buf)
if err != nil {
if errors.Is(err, io.EOF) || errors.Is(err, net.ErrClosed) {
return
}
if ctx.Err() != nil { // 检查主控 context
return
}
continue
}
// 处理数据...
select {
case <-done:
return
default:
}
}
}
哪些场景下 recover 还算“可用”？
- 单 goroutine 独占连接，且明确知道 panic 只发生在业务解包阶段（非 I/O 阻塞中）
-
recover仅用于记录 panic 日志，不执行任何 Close / send / close(ch) 操作 - 连接关闭由外部统一协调：比如主流程收到
SIGTERM后，先发信号给所有handleConngoroutine，等它们自然退出后再调conn.Close()
最常被忽略的一点：优雅关闭的“优雅”，来自可预测的退出路径，而不是对 panic 的补救。panic 是异常，不是流程控制手段。
立即学习“go语言免费学习笔记（深入）”；
