应只在需主动退出时（如用户中断、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 配合固定时间点，才能真正约束整个流程上限。
- 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 的取消状态。
