Context必须作为函数第一个参数显式传递，不可省略或挪位；禁用context.WithValue传业务数据；下游调用前须用tracer.Start延续span；goroutine需显式传ctx。
Context传递必须显式传参，不能依赖全局或闭包隐式携带
Go 的 context.Context 不会自动穿透调用栈，任何需要响应取消、超时或携带请求范围值的函数，都必须把 ctx 作为第一个参数显式接收。常见错误是写了一个封装函数却漏传 ctx，导致下游调用永远无法被取消。
比如封装数据库查询时，若直接调用 db.QueryRow("SELECT ...") 而没用 db.QueryRowContext(ctx, ...)，那这个查询就完全脱离了父 Context 的生命周期控制。
- 所有标准库中支持 Context 的方法（如
http.Client.Do、sql.DB.QueryRowContext、time.AfterFunc的替代方案）都以XXXContext命名，务必优先使用 - 自定义函数只要涉及 I/O、网络、sleep、channel 等可能阻塞的操作，就该加
ctx参数，并在内部用select监听ctx.Done() - 不要把
context.Background()或context.TODO()当成“兜底”传给下游——这等于主动放弃取消能力
Cancel 函数必须配对调用，且仅由创建方负责调用
context.WithCancel、context.WithTimeout、context.WithDeadline 返回的 cancel 函数，本质是向底层 channel 发送关闭信号。它不是幂等的，重复调用会 panic；也不该由接收方调用，否则破坏调用链责任边界。
典型误用：在 HTTP handler 中调用 ctx, cancel := context.WithTimeout(r.Context(), 5*time.Second)，然后在 defer 中执行 cancel() —— 这会导致父 Context（即 r.Context()）被提前关闭，影响中间件或其他并行 goroutine。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 只在你「创建」了子 Context 的地方调用
cancel()，且确保只调用一次（通常用defer cancel()最安全） - 如果只是接收并向下传递 Context，绝不要调用它的
cancel—— 你没权利终止上游的生命周期 - 注意
context.WithValue创建的 Context 没有cancel函数，它只是装饰，不改变取消行为
WithTimeout 和 WithDeadline 的时间精度与系统时钟依赖
context.WithTimeout(ctx, d) 底层依赖 time.Timer，而 time.Timer 的精度受 Go runtime 调度和系统时钟影响。在高负载或虚拟化环境中，实际触发可能比设定延迟几十毫秒甚至更久；若系统时间被 NTP 向后跳变，还可能造成 timeout 提前触发。
这不是 bug，而是设计权衡：Context 的 timeout 是“尽力而为”的协作机制，不是硬实时保证。
- 不要用
WithTimeout实现精确的定时任务——改用time.AfterFunc或独立 timer - 对延迟敏感的服务（如金融类 RPC），建议在业务逻辑内额外做时间检查，而不是只依赖
ctx.Done() -
WithDeadline使用绝对时间，比WithTimeout更易受系统时间跳变影响，生产环境更推荐用WithTimeout
WithValue 容易滥用，仅限传递请求元数据，不可用于控制流或状态共享
context.WithValue 常被误当成“Go 版 ThreadLocal”，用来传用户 ID、trace ID、配置开关等。但它的 key 必须是可比较的类型（通常用私有结构体指针），且一旦写入就不可修改——这导致它不适合做状态容器。
更严重的问题是：如果多个中间件往同一个 ctx 写相同 key，后写的会覆盖前写的，而调用方完全感知不到。
- key 类型必须是 unexported struct，避免第三方包冲突，例如：
type ctxKeyUser struct{}，而非string - 只存轻量、只读、请求生命周期内的元数据（如
userID、requestID），绝不存连接池、锁、缓存实例等资源 - 不要用
ctx.Value做条件分支（如 “如果 ctx.Value(k) == true 就跳过校验”）——这会让调用关系隐晦难测
Context 的核心是传播取消信号和超时，不是通用状态总线。真正容易被忽略的是：哪怕你每层都正确传了 ctx，只要有一处 I/O 操作没接上 ctx（比如忘了用 ReadContext 而用了阻塞的 Read），整条链路就断开了。检查点永远在「每个阻塞点是否监听了 ctx.Done()」。
