WithCancel比WithTimeout更轻量，因为前者仅维护原子状态和channel，后者需启动定时器goroutine，高频调用时调度与内存开销显著。
为什么WithCancel比WithTimeout更轻量
因为 context.WithTimeout 内部会启动一个定时器 goroutine，而 context.WithCancel 仅维护一个原子状态和一个 channel。在高频调用路径（比如每秒数万次的中间件）中，前者会带来可观的调度开销和内存分配压力。
实操建议：
- 若业务逻辑本身已由外部控制超时（如 HTTP server 的
ReadTimeout），优先用context.WithCancel+ 手动触发取消 - 避免在循环内反复调用
context.WithTimeout；可复用同一个 cancelable context，再按需调用cancel() - 用
pprof观察runtime.timerproc占比，若偏高，说明超时 context 过度使用
不要在函数参数里无差别加context.Context
很多团队把 context.Context 当成“标配参数”，塞进每个工具函数——哪怕该函数不涉及 I/O、不启动 goroutine、也不需要响应取消。这不仅增加调用栈深度，还让编译器难以内联，间接拖慢性能。
实操建议：
- 只在可能阻塞或依赖生命周期管理的函数中接收
ctx：比如数据库查询、HTTP 调用、time.Sleep、select等 - 纯计算型函数（如 JSON 解析、字符串处理、加密校验）完全不需要
ctx - 若某个模块内部多个函数共用同一 context，考虑将其封装进结构体字段，而非层层透传
WithValue 的键必须是 unexported 类型，且慎用
context.WithValue 本身开销不大，但滥用会导致两个隐性成本：一是每次 Value() 查找都是链表遍历（O(n)），n 是派生层数；二是如果 key 是 string 或 int 这类通用类型，极易发生 key 冲突，导致取错值甚至 panic。
实操建议：
- 定义 key 时用私有结构体：
type requestIDKey struct{}，而非"request_id" - 避免在 hot path（如请求处理主循环）中频繁调用
ctx.Value()；可提前解包到局部变量 - 绝不把业务参数（如 user ID、order ID）塞进 context——它们应作为显式函数参数传递
Background 和 TODO 的选择不是语义问题，而是逃逸分析问题
context.Background() 返回的是全局变量，不会逃逸；context.TODO() 虽然语义上表示“暂未决定用哪种 context”，但其实现也是全局变量，二者在性能上无差异。真正影响性能的是后续派生操作——比如你在热代码中反复调用 context.WithValue(context.Background(), ...)，就会导致每次分配新 context 实例。
实操建议：
- 服务入口（如 HTTP handler）用
r.Context()，别自己 newBackground - 测试中若需构造 context，优先复用一个预创建的
ctx, _ := context.WithCancel(context.Background())实例，而不是每次 new - 用
go tool compile -gcflags="-m"检查 context 派生是否逃逸；若显示 “moved to heap”，说明产生了额外分配
真正难优化的从来不是单个 context 操作，而是 context 树过深 + 频繁 Value 查找 + 多层 WithTimeout 嵌套——这些组合起来才容易在 pprof 里看到不可忽视的占比。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
