应使用 context 控制长生命周期协程的退出：传入可取消的 context，select 监听 ctx.Done()，收到信号后清理资源并返回，避免资源泄漏。
在 Go 中管理长生命周期协程（goroutine），核心是确保协程能被及时、安全地退出，同时释放其持有的资源（如通道、文件句柄、数据库连接、定时器等）。协程本身不直接导致内存泄漏，但若它持续运行、持有引用或阻塞在未关闭的通道上，就会引发资源累积和内存占用上升。
用 context 控制协程生命周期
context 是 Go 官方推荐的跨 goroutine 传递取消信号、超时和值的机制。所有长周期协程都应监听 ctx.Done() 并在接收到信号后优雅退出。
- 启动协程时传入带取消能力的 context（如
context.WithCancel、context.WithTimeout） - 在协程主循环中使用
select监听ctx.Done()和业务事件（如通道接收、定时器触发） - 收到
ctx.Done()后，清理资源（关闭子通道、释放锁、关闭连接等），再 return
示例：
func runWorker(ctx context.Context, jobs <-chan string) {
for {
select {
case job, ok := <-jobs:
if !ok {
return
}
process(job)
case <-ctx.Done():
log.Println("worker shutting down:", ctx.Err())
return
}
}
}避免在协程中持有未关闭的通道或连接
协程若长期阻塞在 <-ch 或 ch <- x 上，且通道未被关闭或缓冲区满而无人接收，该协程将永远挂起，造成“僵尸协程”。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 发送方需确保通道最终被关闭，或使用带缓冲的通道 + 明确退出条件
- 接收方不要无条件
for range ch，除非确认发送方一定会 close；否则应配合 context 判断退出时机 - 数据库连接、HTTP 客户端、文件句柄等资源，必须在协程退出前显式关闭（可用
defer，但注意 defer 在 goroutine 返回时才执行）
慎用无限 for 循环 + time.Sleep
常见错误写法：for { doWork(); time.Sleep(1 * time.Second) } —— 这类协程无法响应外部停止信号，且 sleep 时间不可控。
- 改用
time.AfterFunc或time.Ticker配合 context 取消 - 例如：用
ticker := time.NewTicker(...); defer ticker.Stop()，并在 select 中监听ticker.C和ctx.Done() - 避免在循环内创建新 ticker 或 timer 而不释放，否则会泄漏 timer 结构体
监控与诊断协程状态
上线后难以察觉协程泄漏，需主动观测：
- 通过
runtime.NumGoroutine()定期采样，突增可能意味着协程堆积 - 开启 pprof：注册
/debug/pprof/goroutine?debug=2查看完整协程栈，定位阻塞点 - 对关键协程添加日志（启动/退出/panic），尤其记录退出原因（正常 cancel 还是 panic）
- 使用结构化日志 + trace ID，便于关联协程行为与请求生命周期
不复杂但容易忽略。关键不是“怎么启动协程”，而是“怎么让它确定地结束”。
