因为 context.context 是接口，不持有取消能力；真正可取消的是 context.withcancel 返回的子上下文和配套 cancel 函数，子 goroutine 必须接收外层创建的同一 ctx 实例才能响应父级取消信号。
为什么 context.WithCancel 不能直接传给子 goroutine 而要显式传参
因为 context.Context 是接口，本身不持有取消能力；真正可取消的是由 context.WithCancel 返回的 ctx（子上下文）和配套的 cancel 函数。子 goroutine 如果只拿到父 ctx，它无法触发取消——cancel 必须被调用才能关闭 ctx.Done()。
常见错误是：在 goroutine 内部调用 context.WithCancel(ctx)，以为能继承取消信号，结果创建了新分支，父取消不会影响它。
- 正确做法：把外层生成的
ctx直接作为参数传入 goroutine，且确保所有下游调用都基于同一个ctx实例 - 错误写法：
go func() { childCtx, _ := context.WithCancel(ctx) // ❌ 新建独立取消链 - 关键点：
ctx的取消传播依赖树形继承关系，不是靠“相同类型”或“同名变量”自动同步
context.WithValue 传值时 key 类型为什么不能用 string
因为 context.Value(key interface{}) 的 key 是用于 map 查找的，如果多个包都用 "user_id" 这种裸字符串作 key，极易发生冲突——A 包存的值被 B 包误读，且编译期无法发现。
Go 官方明确建议用自定义类型（未导出字段）做 key，保证唯一性。
- 推荐写法：
type userIDKey struct{}，然后用ctx = context.WithValue(ctx, userIDKey{}, 123) - 不推荐：
ctx = context.WithValue(ctx, "user_id", 123)或ctx = context.WithValue(ctx, "auth_token", token) - 性能影响：key 是 interface{}，但实际比较开销极小；主要风险是语义污染和调试困难
HTTP handler 中的 ctx.Request.Context() 什么时候会关闭
它会在以下任一情况发生时关闭：ctx.Done() 被触发，此时 ctx.Err() 返回具体原因：
- 客户端断开连接（如浏览器关闭、curl 中断）→
context.Canceled - 请求超时（由 HTTP server 的
ReadTimeout/WriteTimeout或中间件设置）→context.DeadlineExceeded - 服务端主动调用
http.CloseNotifier（已废弃）或通过中间件 cancel —— 实际极少手动触发
注意：ctx.Request.Context() 是框架注入的，**不是**你用 context.WithTimeout 包一层就能覆盖的；它生命周期由 net/http 控制，你的派生 context 应该以它为 parent。
WithTimeout 和 WithDeadline 的底层区别不只是时间表达方式
context.WithTimeout 是对 context.WithDeadline 的封装，但它们在定时器实现上不同：
-
WithTimeout使用time.AfterFunc启动一个相对计时器，启动时刻是函数调用时 -
WithDeadline使用time.Until计算剩余时间后调用AfterFunc，更精确地对齐绝对时间点 - 当系统时间被大幅调整（如 NTP 校正），
WithDeadline更可靠；但日常开发中二者行为基本一致 - 不要混用：
context.WithTimeout(context.WithDeadline(...), ...)会导致嵌套 cancel，容易提前触发
最易忽略的一点：所有带 cancel 的 context 都必须调用 cancel()，否则底层 timer 不会释放，长期运行服务会出现 goroutine 泄漏。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
