Context仅传递取消信号、超时控制及少量元数据（如traceID），业务数据应走函数参数或结构体；WithValue的key须为自定义类型；HTTP handler优先用WithTimeout并defer cancel；goroutine中defer cancel会失效，应传入外部ctx或显式调用cancel。
Context 里不该放业务数据
很多人一看到 context.WithValue 就立刻往里塞用户 ID、token、请求参数，结果调试时发现值丢了、类型断言 panic、甚至 goroutine 泄漏。这不是 Context 的设计本意——它只负责传递取消信号、超时控制和少量**元数据**（比如 traceID、spanID），不是通用的 request-scoped storage。
- 业务字段该走函数参数或结构体字段，清晰、可测试、不隐式
-
context.WithValue只适合传真正跨多层调用、又不便改函数签名的“上下文线索”，比如request_id或trace_id - 所有
context.WithValue的 key 必须是自定义类型（不能用string），否则不同包之间容易键冲突 - 示例中常见错误：
ctx = context.WithValue(ctx, "user_id", 123)→ 应写成type userIDKey struct{}+ctx = context.WithValue(ctx, userIDKey{}, 123)
全链路 traceID 怎么安全注入到 Context
traceID 是最典型的 Context 元数据使用场景，但直接从 HTTP header 解析后硬塞进 root context 容易出错：没校验格式、没做长度截断、没统一大小写，下游服务日志对不上。
- 务必在入口处（如 HTTP middleware）一次性解析并标准化 traceID：
strings.TrimSpace(strings.ToLower(r.Header.Get("X-Trace-ID"))) - 用固定 key 注入，例如定义
var traceIDKey = struct{}{}，避免字符串拼写错误 - 下游服务不要自己生成 traceID，除非当前 ctx 没有（即非透传请求），此时才调用
uuid.NewString()创建新 trace - 注意：gRPC 默认用
grpc-trace-binheader，格式是二进制 W3C TraceContext，需用otel.GetTextMapPropagator().Extract()（如果用 OpenTelemetry）
WithCancel / WithTimeout 哪个更适合 HTTP handler
HTTP handler 几乎总是该用 context.WithTimeout，而不是 context.WithCancel 手动控制。手动 cancel 容易漏调用、goroutine 持有 ctx 不释放、或者 cancel 太早导致中间件还没写完 response 就中断。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 标准写法：
ctx, cancel := context.WithTimeout(r.Context(), 30*time.Second)，然后defer cancel() - 别在 handler 里用
context.WithCancel(context.Background())—— 这会切断父 context 的取消链，上游超时或中断无法通知到你 - 数据库查询、HTTP client 调用必须显式传入这个带 timeout 的 ctx，否则可能永远卡住
- 注意：
http.Server.ReadTimeout和WriteTimeout是连接级的，不影响 handler 内部逻辑执行时间，所以 handler 自己的 ctx timeout 不可省
为什么 defer cancel() 在 goroutine 里会失效
这是线上最隐蔽的 Context 泄漏来源之一：把 ctx, cancel := context.WithTimeout(...) 放在 goroutine 里，再 defer cancel()，结果 cancel 永远不执行，ctx 一直存活，内存和 goroutine 都涨。
立即学习“go语言免费学习笔记（深入）”；
- 原因：
defer只在函数 return 时触发，而 goroutine 是独立函数，如果它没退出，defer 就不会跑 - 正确做法：要么不用 defer，在 goroutine 结束前明确调用
cancel()；要么用context.WithCancelCause（Go 1.21+）配合 select 监听 done channel - 更稳妥的是——别在 goroutine 里新建带 cancel 的子 context，而是把外部已有的 ctx 传进去，由上层统一控制生命周期
- 验证方式：pprof 查看
runtime.goroutines数量持续上涨，且堆栈里大量出现context.(*cancelCtx).cancel未完成状态
