Go 的 context 用于传播取消信号、超时、截止时间和请求范围值，而非直接控制请求生命周期；其自动取消由 http.Server 在连接断开、读取超时或响应完成时触发 cancel() 实现。
Go 的 context 不是用来“控制请求生命周期”的工具，而是用来**传播取消信号、超时、截止时间与请求范围值（request-scoped values）**的机制。HTTP 请求生命周期的“控制”实际由 http.Server、http.Request.Context() 和你自己的 handler 逻辑共同完成——context 只负责把“该停了”这个信号可靠地透传下去。
为什么 handler 中的 ctx := r.Context() 会自动取消？
因为 Go 标准库的 http.Server 在每次收到请求时，会为该请求创建一个派生自 server.BaseContext（默认是 context.Background()）的新 context，并在以下任一情况发生时调用 cancel()：
- 客户端主动断开连接（如浏览器关闭标签页、curl 被 Ctrl+C 中断）
- 请求体读取超时（
ReadTimeout）或头读取超时（ReadHeaderTimeout）触发 - 响应写入完成或发生错误（如 client hung up）
- 你显式调用
http.Request.Cancel（已弃用，仅兼容旧代码）
这意味着：你无需手动监听连接状态，只要在 I/O 或阻塞操作中检查 ctx.Done()，就能响应中断。
context.WithTimeout 和 context.WithDeadline 的关键区别
两者都返回带取消能力的子 context，但触发条件不同：
立即学习“go语言免费学习笔记（深入）”；
-
context.WithTimeout(parent, 5 * time.Second)：从调用时刻起计时，5 秒后自动调用cancel() -
context.WithDeadline(parent, time.Now().Add(5 * time.Second))：按绝对时间点触发，适合需要对齐服务端时钟或跨系统协调的场景（如分布式 trace 截止）
⚠️ 注意：WithTimeout 底层就是 WithDeadline，所以它们的性能和行为几乎一致；但如果你在 handler 中多次嵌套调用 WithTimeout，会导致多个 timer goroutine 累积（虽小但可避免）。推荐优先用 WithTimeout，除非你需要明确 deadline 语义。
如何安全地将 context 传给下游依赖（DB、HTTP Client、channel 操作）？
不是所有库都原生支持 context.Context，传之前先确认接口是否接受：
- 数据库驱动（
database/sql）：必须用db.QueryContext(ctx, ...)等带Context后缀的方法，否则超时不会中断查询 -
net/http.Client：必须用client.Do(req.WithContext(ctx))或直接调用client.GetContext(ctx, url)（Go 1.13+） - 自定义 channel 操作：不能直接用
select { case ，要包装成可取消的接收：
select {
case val := <-ch:
// 处理数据
case <-ctx.Done():
// 返回 ctx.Err()，例如 context.Canceled 或 context.DeadlineExceeded
return ctx.Err()
}⚠️ 常见错误：把 context.Background() 或 context.TODO() 直接传给下游——这会让整个链路失去取消能力；或者只传给部分调用，遗漏关键阻塞点（如日志 flush、文件 close），导致 goroutine 泄漏。
为什么 context.WithValue 不该存业务参数？
WithValue 的设计意图是传递**请求元数据**（如 traceID、userID、auth token），而非业务逻辑所需的数据结构。原因有三：
- 类型安全丢失：取值时需强制类型断言，容易 panic
- 难以追踪来源：谁 put 的？在哪被覆盖的？没有编译期检查
- 掩盖设计问题：本该通过函数参数或结构体字段传递的业务数据，塞进 context 会让 handler 变得隐式依赖、难测试、难复用
✅ 正确做法：业务参数走函数参数；跨多层中间件的元信息（且确定只读）才考虑 WithValue，并配合自定义 key 类型防止冲突：
type ctxKey string
const userIDKey ctxKey = "user_id"
<p>// 设置
ctx = context.WithValue(ctx, userIDKey, "u_123")</p><p>// 获取（带安全断言）
if uid, ok := ctx.Value(userIDKey).(string); ok {
// 使用 uid
}真正难的是让每个协程、每个第三方调用都尊重同一个 ctx.Done()。一旦漏掉一处 select 或忘了传 context，整个请求就卡死在那里，而你看到的只是 CPU 低、goroutine 数暴涨、pprof 显示一堆阻塞在 runtime.gopark ——这时候得翻每一行 I/O 调用，看它有没有接 context。
