优雅断开的核心是让依赖连接的goroutine主动感知退出，而非仅关闭连接；直接调用conn.Close()无法唤醒阻塞在Read/Recv的goroutine；必须用select+ctx.Done()包裹所有长周期I/O操作。
Go 服务里所谓“优雅断开”，核心不是关掉连接，而是让所有依赖该连接的 goroutine 主动感知并退出。不绑定 context 的断开函数，基本等于没断开——协程照跑、资源照占、连接照挂。
为什么直接调 conn.Close() 不够用
网络连接关闭只是释放 fd，但监听该连接的 goroutine 可能还卡在 conn.Read() 或 stream.Recv() 上，尤其是当连接背后有 proxy、Nginx 或 TLS 层时，内核可能仍处于阻塞等待状态，Close() 并不会自动唤醒它。
- HTTP handler 里写
defer conn.Close()：只关了连接，没通知正在读取的子 goroutine - gRPC stream server 中只调
stream.Send()后就返回：stream.Context() 已失效，但处理逻辑可能还在跑 - WebSocket 连接关闭后，心跳 goroutine 仍在
time.Sleep()，没检查 ctx 是否已取消
select + ctx.Done() 是唯一可靠入口点
所有长周期阻塞操作必须被包裹进 select，否则 context 取消信号永远进不来。这不是可选项，是 Go 生态对“可取消 I/O”的事实标准。
- 不要写：
for { n, err := conn.Read(buf) }—— 完全无法响应 cancel - 必须写：
select { case - 更稳妥的做法是配合
conn.SetReadDeadline()，用ctx.Deadline()设置超时，避免 Read 卡死在内核态 - 对
http.ResponseWriter写流也一样：每次Flush()前检查ctx.Err() != nil
cancel() 调用时机决定是否泄漏
很多人调了 context.WithCancel()，却忘了在哪调 cancel()。结果是 timer 不释放、done channel 永远不 closed、goroutine 一直挂着。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- HTTP handler 结束时 defer cancel()：适合短请求，但对长连接无效（handler 不会自然结束）
- 长连接场景推荐：连接建立时派生子 ctx，并在
defer中注册清理函数，例如：go func() { - 注意：不要在多个 goroutine 里重复调
cancel()，它虽幂等，但掩盖逻辑错误——比如本该由连接关闭触发，却被超时提前触发 - RabbitMQ 消费者中，必须先
ch.Cancel(tag, false)，再等当前消息处理完，最后关 channel 和 conn；直接 close(msgs) 会 panic
第三方库不支持 context 时怎么破
像 streadway/amqp 的 Consume() 不接受 context.Context，这不是 bug，是设计限制。你不能强塞 context 进去，而要控制它的使用边界。
- 把
Consume()放进一个独立 goroutine，用select监听msgs和ctx.Done() - 收到
ctx.Done()后，立刻调ch.Cancel(tag, false)告诉 RabbitMQ 停止投递 - 别假设
msgschannel 会自动关闭——它不会，必须显式ch.Close()和conn.Close() - 数据库查询要用
db.QueryContext(ctx, ...)，而不是db.Query(...)；同理，HTTP client 要用http.NewRequestWithContext()
最常被忽略的一点：context 泄漏往往不是因为没调 cancel()，而是调得太晚，或者把 ctx 传给第三方库后，彻底丢失了对 cancel() 的控制权。一旦 ctx 从主流程脱钩，它就成了一个没有出口的 goroutine 发射器。
