应只在需主动退出时（如用户中断、Ctrl+C）显式调用 cancel() 以提前释放资源；cancel() 可重复调用且安全；WithTimeout 适合相对时长场景（如 HTTP 请求），WithDeadline 适合绝对时间约束（如批处理）；http.Request.Context() 本身不可取消，须用 WithCancel 包装并显式传递下游。
context.WithCancel 什么时候该自己调用 cancel()？
手动调用 cancel() 不是为了“结束任务”，而是为了**提前释放关联的 goroutine 和 channel 资源**。如果父 context 已经被取消（比如超时或主动 cancel），子 context 会自动收到信号，此时再调用子级 cancel() 是冗余的；但若你主动控制生命周期（如用户中断上传、命令行 Ctrl+C），就必须在业务逻辑中显式调用对应 cancel()。
常见错误是：只传入 ctx 却忘了保存返回的 cancel 函数，导致无法主动终止；或者在 defer 中无条件调用 cancel()，结果父 context 还没结束就提前释放了资源。
- 只在需要“主动退出”时才保存并调用
cancel()，比如 HTTP handler 中监听客户端断连 - 避免在 defer 中直接写
cancel()，除非你能确保它不会干扰上层 context 的传播 -
cancel()可被多次调用，是安全的，但第二次起不产生实际效果
context.WithTimeout 和 context.WithDeadline 的关键区别
WithTimeout 是基于“从现在起多久后截止”，而 WithDeadline 是指定一个绝对时间点。它们底层都生成 *timerCtx，但误用会导致行为偏差——比如系统时间被修改、跨时区调度、或需要复用同一 deadline 多次创建 context 时，WithDeadline 更可靠。
一个典型陷阱：在循环里反复用 WithTimeout(ctx, 5*time.Second)，每次都会重置计时器，导致总耗时远超预期；而用 WithDeadline 配合固定时间点，才能真正约束整个流程上限。
立即学习“go语言免费学习笔记（深入）”；
- HTTP 客户端请求推荐用
WithTimeout，因为语义清晰：“这个请求最多等 5 秒” - 批处理作业或定时任务协调，优先用
WithDeadline(time.Now().Add(30 * time.Second)) - 不要混用：传给
http.Client.Timeout的是连接/读写超时，和 context 超时是两层控制，需同时设置
为什么 http.Request.Context() 不能直接用来 WithCancel？
HTTP server 创建的 request context 是由 context.Background() 派生的 *valueCtx，它**不支持取消**——没有关联的 cancel 函数，调用 context.WithCancel(req.Context()) 会新建一个可取消的子 context，但原 request context 依然存活，且无法通过它影响子 context 的取消状态。
这意味着：如果你只改了子 context，却没把新 context 传进下游调用（如数据库查询、RPC），那些操作根本不会响应取消信号。
- 必须将
WithCancel(req.Context())的结果显式传给所有可能阻塞的函数，例如db.QueryRowContext(cancelCtx, ...) - 别指望 “改了 request context 就全局生效”，Go 的 context 是单向传递的，不是全局状态
- 中间件中若需增强 request context（如加 traceID 或 timeout），应使用
req = req.WithContext(newCtx)并继续向下传递
select + ctx.Done() 阻塞时，为什么 err 常为 context.Canceled 而不是 context.DeadlineExceeded？
因为 ctx.Err() 返回的是 context 实际终止的原因：context.Canceled 表示被显式 cancel；context.DeadlineExceeded 是 timerCtx 在截止时间到达后内部调用 cancel 所触发的特例。但两者都会让 ctx.Err() 判断。
更隐蔽的问题是：如果多个 goroutine 同时监听同一个 ctx.Done()，其中一个先拿到信号并关闭资源（如关闭 channel），其他 goroutine 再操作就会 panic。这不是 context 的问题，而是并发控制缺失。
- 永远用
if err := ctx.Err(); err != nil { return err }显式检查终止原因 - 不要仅依赖
select { case 就认为是超时，后续逻辑仍需校验ctx.Err() - 对共享资源（如文件、连接）做关闭保护，避免重复 close 或在已关状态下操作
context 的取消与超时不是开关，而是信号广播机制；真正决定是否停止工作的，是你在每个关键节点有没有读取 ctx.Done()、有没有检查 ctx.Err()、有没有把新 context 正确往下传。漏掉任意一环，cancel 就只是个哑信号。
