context.WithTimeout 本身不中断 goroutine，仅提供 Done() channel 和 Err()；需在关键路径（如 HTTP 请求、数据库查询、循环）中显式监听 ctx.Done()，否则超时无效。
Go 中 context.WithTimeout 是最常用也最容易出错的超时方式
直接用 context.WithTimeout 启动 goroutine 本身不会自动中断正在运行的函数，它只提供一个可监听的 Done() channel 和配套的 Err()。真正起作用的是你是否在关键路径里检查这个 channel。
常见错误是：启用了 timeout context，但底层 HTTP 请求、数据库查询或自定义循环里完全没响应 ctx.Done()，导致 goroutine 实际卡住不退出。
- 必须在阻塞操作前或循环中显式 select
ctx.Done()，例如：select { case <-time.After(5 * time.Second): // 正常完成 case <-ctx.Done(): return ctx.Err() // 或做清理 } - HTTP 客户端要传入带 timeout 的
context，不能只靠http.Client.Timeout，后者不传播取消信号 - 数据库驱动（如
database/sql）支持QueryContext、ExecContext等方法，必须替换掉旧版无 context 的接口
用 time.AfterFunc 做超时是反模式，除非你不需要取消语义
time.AfterFunc 只能触发一次回调，无法与 goroutine 生命周期联动，也不能释放关联资源。它适合发告警、打日志这类“尽力而为”的场景，但不能替代 context 取消机制。
典型误用：
time.AfterFunc(3*time.Second, func() {
close(ch) // ch 可能已被读完或未初始化
}) 这种写法竞态风险高，且无法区分是超时关闭还是业务主动关闭。
- 需要精确控制生命周期时，一律用
context.WithTimeout或context.WithCancel+ 手动调用cancel() -
time.AfterFunc的 timer 不会自动 stop，如果 handler 没执行完就退出，timer 仍驻留直到触发，可能造成内存泄漏 - 若只是想延时执行某事（比如清理临时文件），且不依赖其他 goroutine 状态，
AfterFunc可用，但要加defer timer.Stop()防止重复触发
goroutine 泄漏往往源于忘记 select ctx.Done() 或未关闭 channel
超时控制失效最隐蔽的表现不是报错，而是 goroutine 数持续上涨。pprof 查到大量状态为 chan receive 或 select 的 goroutine，基本可以确定是 context 未被消费。
立即学习“go语言免费学习笔记（深入）”；
另一个高频坑是：向已关闭的 channel 发送数据，引发 panic；或向 nil channel 发送，导致永久阻塞。
- 所有接收方应统一用
select { case v := ，避免直接 <code> - 发送方在 send 前先判断
ctx.Err() != nil，或用select包裹发送逻辑 - 不要在 defer 里关 channel，尤其当 channel 被多个 goroutine 共享时；优先让 sender 关闭，receiver 不负责关
第三方库对 context 支持程度差异大，务必查文档验证
像 redis/go-redis、elastic/go-elasticsearch 都要求显式传 ctx 到每个 API 调用；但有些老 SDK（比如部分云厂商的 Go SDK）只接受全局 client timeout，根本不接收 context 参数。
遇到这种库，只能在外层用 context.WithTimeout 包一层，并在 goroutine 内部用 select 监听超时，然后调用其提供的 Close() 或 Cancel() 方法（如果有）强行中断。
- 没有 cancel 接口的老库，超时后只能放弃该 goroutine，靠 runtime GC 回收，无法立即释放连接等系统资源
- 某些库的 context 仅控制请求发起阶段，不控制响应读取过程（如部分 HTTP 封装），这时需额外加
io.CopyContext或手动分块读 + 检查ctx.Done() - 永远不要假设 “用了 context 就万事大吉”，每次集成新库都应写最小复现 case，用
runtime.NumGoroutine()和pprof验证是否真能及时退出
实际并发超时控制最难的不是写对那几行 context.WithTimeout，而是确保整条调用链——从入口 goroutine、中间件、下游 SDK、到底层 syscall——每一环都尊重并传递 ctx。漏掉任意一环，超时就形同虚设。
