context.WithCancel是最直接的请求取消方式，返回可取消Context和cancel函数，调用后者广播单向不可恢复的取消信号，需显式调用以防资源泄漏。
go中context.WithCancel是最直接的请求取消方式
当你需要手动触发取消（比如用户主动中断、超时前强制终止），context.WithCancel是首选。它返回一个可取消的Context和一个cancel函数，调用后者即通知所有监听者“该停了”。
关键点在于：取消信号是单向广播，不可恢复；且cancel函数必须被调用，否则底层资源（如goroutine、timer）可能泄漏。
- 必须在不再需要时显式调用
cancel()，尤其在Error路径或defer中 - 不要重复调用
cancel()，虽不 panic，但会浪费一次timer清理 - 子Context继承父Context的取消状态，但不会反向影响父级
ctx, cancel := context.WithCancel(context.background()) defer cancel() // 防止泄漏 go func() { select { case <-time.After(2 * time.Second): fmt.Println("work done") case <-ctx.Done(): fmt.Println("canceled:", ctx.Err()) // context.Canceled } }()
time.Sleep(1 * time.Second) cancel() // 主动触发
http.Request.Context()自带取消能力，无需手动包装
Go 1.7+ 的*http.Request已内置Context，由服务器自动绑定：客户端断开连接、超时、主动关闭连接都会让req.Context().Done()关闭。你不需要也不应该用context.WithCancel(req.Context())再包一层。
常见误用是把req.Context()当成普通上下文传给下游服务却忽略其生命周期——它会在客户端离开时立刻失效，导致下游调用过早失败。
- 直接使用
req.Context()做I/O等待、数据库查询、rpc调用 - 若需延长生命周期（如异步落库），应派生新Context：
context.WithTimeout(context.Background(), ...) - 不要用
req.Context()启动长期goroutine，除非明确处理Done()并退出
func handler(w http.ResponseWriter, r *http.Request) { // ✅ 正确：复用原生Context rows, err := db.QueryContext(r.Context(), "SELECT * FROM users WHERE id = $1", userID) // ❌ 错误：用req.Context()启动后台任务，客户端一走就中断 go sendNotification(r.Context(), msg) // 可能中途被cancel // ✅ 正确：另起独立生命周期 notifCtx, _ := context.WithTimeout(context.Background(), 5*time.Second) go sendNotification(notifCtx, msg)
}
context.WithTimeout和context.WithDeadline的区别与选型
WithTimeout基于相对时间（从调用时刻起多少秒），WithDeadline基于绝对时间（到某个time.Time截止）。HTTP handler常用WithTimeout，而定时调度类逻辑更适合WithDeadline。
注意：两个函数都依赖系统时钟，若机器时间被NTP校正回拨，WithTimeout可能意外提前触发；WithDeadline更稳定，但需小心时区与时间计算误差。
- Web API入口统一用
context.WithTimeout(parent, 30*time.Second) - 重试逻辑中避免嵌套多个
WithTimeout，会导致总耗时不可控 - 若父Context已带deadline，子Context的deadline不能晚于父级，否则会被父级提前截断
// 父Context有5s deadline，子Context设8s也会被5s截断 parent, _ := context.WithDeadline(context.Background(), time.Now().Add(5*time.Second)) child, _ := context.WithTimeout(parent, 8*time.Second) // 实际最多活5s取消后如何安全清理资源？ctx.Done()不是万能钩子
ctx.Done()只负责通知，不负责执行清理。常见陷阱是以为监听Done()就能自动释放文件句柄、关闭channel、停止goroutine——其实只是收到信号，后续动作全靠你自己写。
尤其要注意：关闭channel后仍可能有goroutine往里发数据，引发panic；数据库连接未Close()会持续占用池；长时间运行的for循环没检查ctx.Err()会完全无视取消。
- 所有阻塞操作（
Read/Write/Select/Query）必须传入Context参数 - 自定义循环必须在每次迭代开头检查
ctx.Err() != nil - 清理逻辑（如
close(ch)、conn.Close()）应放在select的default或Done()分支后立即执行
ch := make(chan int, 10) go func() { defer close(ch) // 清理必须显式写 for i := 0; i < 100; i++ { select { case ch <- i: case <-ctx.done(): return>
实际项目中最容易被忽略的是：取消信号到达后，goroutine是否真停了？有没有残留的time.AfterFunc、未关闭的net.Conn、或仍在运行的timer。Context只是开关，关掉电源不等于电器自动断电——得自己拔插头。