context.WithCancel适合手动控制协程退出时机，通过调用cancel函数立即通知监听该context的goroutine退出，需defer调用防泄漏、定期检查ctx.Done()并避免误用context传业务参数。
context.WithCancel 适合手动控制协程退出时机
当协程需要响应外部信号（比如用户主动停止、配置变更）时，context.WithCancel 是最直接的选择。它返回一个可取消的 context.Context 和一个 cancel 函数，调用后者会立即触发所有监听该 context 的 goroutine 退出。
常见错误是忘记调用 cancel()，导致 context 泄漏、goroutine 无法回收；或在多个 goroutine 中重复调用 cancel() —— 虽然安全，但没必要。
- 始终在 defer 中调用
cancel()（如果生命周期由当前函数管理） - 传递 context 时用
ctx命名，避免混用context.Background()或context.TODO() - 协程内部需定期检查
ctx.Done()，不能只在启动/结束时判断
ctx, cancel := context.WithCancel(context.Background())
defer cancel() // 防止泄漏
<p>go func(ctx context.Context) {
for {
select {
case <-ctx.Done():
fmt.Println("goroutine exit:", ctx.Err()) // context.Canceled
return
default:
time.Sleep(100 * time.Millisecond)
}
}
}(ctx)context.WithTimeout 更适合网络请求或 I/O 等有明确耗时上限的场景
context.WithTimeout 本质是基于 context.WithDeadline 的封装，自动计算截止时间。它比手动算 time.Now().Add(...) 更可靠，尤其在系统时间被调整时仍能保持行为一致。
容易踩的坑：超时时间设得太短，导致正常请求被误杀；或在循环中反复创建新 timeout context，却没复用或及时 cancel，造成 timer 泄漏。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 超时值建议从配置或上层传入，避免硬编码
- 若需重试，每次重试应新建独立的
context.WithTimeout，旧 context 必须 cancel - 注意：
ctx.Err()在超时后为context.DeadlineExceeded，不是nil
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel()
<p>resp, err := http.DefaultClient.Do(req.WithContext(ctx))
if err != nil {
if errors.Is(err, context.DeadlineExceeded) {
log.Println("request timed out")
}
}select + ctx.Done() 是协程协作退出的唯一可靠方式
Go 没有强制终止 goroutine 的机制，所有“取消”都依赖协程自身配合。关键就是把 放进 <code>select 分支，并在收到信号后干净退出 —— 释放资源、关闭 channel、返回错误等。
常见反模式：只在 loop 开头检查一次 ctx.Err()；或把 ctx.Done() 和其它 channel 混在一个无 default 分支的 select 中，导致阻塞无法响应取消。
- 任何可能长时间阻塞的操作（如
time.Sleep、ch 、<code>）前都应加 <code>select判断ctx.Done() - 不要在
ctx.Done()分支里再起 goroutine 或做复杂清理，否则可能错过取消时机 - 如果用了
sync.WaitGroup，必须确保所有 goroutine 退出后才wg.Done()
不要用 context 传递业务参数或共享状态
context.Context 设计初衷是跨 API 边界传递截止时间、取消信号和少量请求级元数据（如 trace ID）。把它当通用容器塞结构体、数据库连接、配置对象，会导致代码难以测试、内存泄漏风险上升，且违反 Go 的显式依赖原则。
典型症状：函数签名越来越长，单元测试必须构造 fake context，重构时不敢删 context 参数怕影响下游。
- 业务参数一律通过函数参数显式传入
- 需要共享的状态（如 logger、DB client）用 struct 字段或依赖注入容器管理
- 真要传元数据，用
context.WithValue，但 key 必须是私有类型（避免冲突），且仅限字符串/整数等简单值
// ❌ 错误示例：用 context 传 DB 实例
ctx = context.WithValue(ctx, "db", db)
<p>// ✅ 正确做法：显式传参
func handleUser(ctx context.Context, db *sql.DB, userID int) error { ... }context 的取消机制本身很轻量，但滥用或忽略协作契约会让整个并发模型变得脆弱。真正难的不是调用 WithCancel，而是让每个 goroutine 都尊重 Done() 信号，并在任意执行点都能安全退出。
