Go中Context传递链路需手动注入trace ID并日志打点实现可视化追踪；defer cancel()后Context未取消是因为接收方未监听ctx.Done()或检查ctx.Err()。
Context传递链路怎么可视化追踪
Go 的 context.Context 本身不提供调用栈或传播路径记录，必须靠手动注入可观测性信息。最轻量且可靠的方式是用 context.WithValue 塞入唯一 trace ID 或层级标识符，再配合日志打点。
- 不要依赖
context.String()或fmt.Printf("%v", ctx)—— 它只输出类型和地址，看不到父子关系 - 推荐在每次创建子 context 时生成新 ID（如
uuid.NewString()），并存入ctx = context.WithValue(parent, keyTraceID, id) - 所有关键函数入口处读取该值：
id := ctx.Value(keyTraceID)，然后日志里统一带trace_id=xxx - 注意：
WithValue不适合传业务数据，仅用于调试/追踪；key 必须是私有未导出变量，避免冲突
为什么 defer cancel() 后 Context 还没被取消
常见错觉是“调用了 cancel() 就立刻生效”，其实取消信号需要被接收方主动检测 —— ctx.Done() 是一个 channel，只有监听它并退出的 goroutine 才会响应。
- 如果某函数没检查
ctx.Err()或没 select 监听ctx.Done()，即使父 context 已 cancel，它仍继续执行 - 数据库查询、HTTP 调用等标准库方法内部会监听，但自定义阻塞操作（如
time.Sleep、for 循环）必须手动加select { case - 子 context 的
cancel()函数调用后，其Done()channel 立即关闭，但父 context 不受影响；只有根 context（如context.WithTimeout创建的）超时才会级联关闭所有子孙
WithCancel / WithTimeout / WithDeadline 的行为差异
三者底层都基于 cancelCtx，但触发条件不同，直接影响流程中断时机。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
context.WithCancel(parent)：纯手动控制，调用返回的cancel()函数才触发取消 -
context.WithTimeout(parent, 2*time.Second)：等价于WithDeadline(parent, time.Now().Add(2*time.Second))，但更常用；计时器由 runtime 启动，精度受 GPM 调度影响，可能延迟几十毫秒 -
context.WithDeadline(parent, t)：按绝对时间触发，适合跨服务协调；若系统时钟回拨，可能导致提前取消（Go 1.20+ 已用 monotonic clock 修复） - 所有子 context 都继承父 context 的
Done()和Err()，但各自的取消函数互不影响
Debug 时怎么快速定位 Context 断裂点
Context 断裂通常表现为下游 goroutine 永远不退出、超时未生效、或 ctx.Err() 始终为 nil。核心排查逻辑是“从入口往下逐层验证是否透传”。
立即学习“go语言免费学习笔记（深入）”；
- 检查每个函数签名是否接收
ctx context.Context参数，并确认调用时传的是入参ctx，而非硬编码context.Background() - 用
fmt.Printf("in %s: err=%v\n", "funcName", ctx.Err())快速打印各层状态（仅调试用，勿留生产） - 特别注意中间件、goroutine 启动、defer 闭包等场景：比如
go fn(ctx)正确，但go fn(context.Background())就断了 - 第三方库（如
sql.DB.QueryContext）要求显式传 ctx；漏传会导致该调用完全脱离上下文控制
Context 流程分析没有银弹，关键在于每层都做“是否监听、是否透传、是否及时响应”三重校验。最容易被忽略的是：子 goroutine 启动时捕获的 ctx 变量是否在闭包中被意外覆盖，或者 defer 里的 cancel 被提前调用导致上游还没用完就失效。
