goroutine泄漏本质是阻塞导致永不退出，并非gc问题；必须用context.context配合select监听ctx.done()，避免裸调time.sleep、ch
goroutine 泄漏不是“偶尔发生”，而是没用 context 的必然结果。只要存在阻塞操作（如 time.Sleep、ch 、<code>、<code>http.Get），又没监听 ctx.Done()，就大概率泄漏。
为什么 goroutine 会泄漏而不退出
泄漏的本质是 goroutine 卡在某个阻塞点，永远等不到它期待的信号。比如：
- 往一个没人接收的无缓冲
chan int发送数据，ch 永远挂起 - 启动一个轮询
time.Ticker，但主逻辑没提供退出路径 - HTTP 请求卡在网络层，没有超时，调用方已放弃但 goroutine 还在等响应
Go 不会强制终止 goroutine，它只靠你主动检查退出条件。而 context 提供的 ctx.Done() 就是最标准、最可组合的退出信号源。
必须把 ctx 当作第一个参数传入
这不是风格问题，是防止上下文丢失的关键约定。所有可能派生子 goroutine 或发起 I/O 的函数，都应接受 context.Context 作为首参：
func fetchUser(ctx context.Context, userID string) (User, error) {
// 使用 ctx 控制 http.Client 超时
req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
resp, err := http.DefaultClient.Do(req)
if err != nil {
return User{}, err
}
// ...
}
不这样做会导致：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 子调用无法感知父级取消（例如请求被客户端断开）
- 后续加超时要改一堆签名，破坏兼容性
- 静态分析工具（如
staticcheck）会报SA1012警告
别在结构体里存 context
context 是一次性的、有生命周期的值，不是配置项。把它塞进 struct 字段，等于把一个随时会失效的信号源长期持有：
// ❌ 错误：结构体持有 context
type Service struct {
ctx context.Context // 危险！可能早已过期或被 cancel
db *sql.DB
}
<p>// ✅ 正确：每次方法调用传入 fresh context
func (s *Service) GetUser(ctx context.Context, id int) error {
// 在这里用 ctx 控制查询超时
rows, err := s.db.QueryContext(ctx, "SELECT ...")
// ...
}</p>
常见后果：
- struct 实例复用时，旧
ctx已关闭，但新请求仍误用它，提前失败 - GC 无法回收关联的定时器或 goroutine，造成隐性泄漏
- 和
WithTimeout/WithCancel派生链断裂，级联取消失效
WithCancel 和 WithTimeout 的关键区别
两者都返回 cancel 函数，但触发时机和适用场景不同：
-
context.WithCancel(parent)：纯手动控制。调用cancel()立即关闭ctx.Done()。适合“用户点击取消”“收到 SIGINT”这类外部事件驱动的退出 -
context.WithTimeout(parent, 5*time.Second)：从调用该函数的**那一刻起**开始倒计时，无论 goroutine 是否已启动。适合包装 HTTP 请求、数据库查询等不确定耗时的操作
注意：WithTimeout 内部就是 WithDeadline + time.Now().Add(d)，所以它不感知 goroutine 启动延迟。如果你需要“从任务真正开始执行起计时 5 秒”，得自己封装一个带启动时间戳的 wrapper。
最易被忽略的一点：每个 goroutine 都要自己监听 ctx.Done() —— 即使它的父 goroutine 已监听过。因为 Done() 是广播信号，但退出动作必须由每个 goroutine 自己完成。漏掉一层，就多一个泄漏点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
