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 // 每次读前设动态 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 <p>}</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill4860" title="GitHub Actions Retry Recovery Audit"><img
src="https://img.php.cn/upload/skill/000/000/081/179024049910965.jpg" alt="GitHub Actions Retry Recovery Audit" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill4860" title="GitHub Actions Retry Recovery Audit" class="overflowclass">GitHub Actions Retry Recovery Audit</a>
<p class="overflowclass">审计 GitHub Actions 运行，检测失败后成功的重试恢复模式，量化 flaky 重运行的浪费。</p>
</div>
<a rel="nofollow" href="/xiazai/skill4860" title="GitHub Actions Retry Recovery Audit" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div><hr><h3>哪些场景下 <code>recover</code> 还算“可用”？</h3>
- 单 goroutine 独占连接，且明确知道 panic 只发生在业务解包阶段（非 I/O 阻塞中）
-
recover仅用于记录 panic 日志，不执行任何 Close / send / close(ch) 操作 - 连接关闭由外部统一协调：比如主流程收到
SIGTERM后，先发信号给所有handleConngoroutine，等它们自然退出后再调conn.Close()
最常被忽略的一点：优雅关闭的“优雅”，来自可预测的退出路径，而不是对 panic 的补救。panic 是异常，不是流程控制手段。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
