手动创建 span 必须从入站请求或消息上下文提取 trace 信息并恢复 context，再用 tracer.startspan(..., childof(spanctx))；tag 要用标准保留字段（如 error=true）、小写点分命名、避免敏感信息；k8s 下需统一 w3c propagator 并透传 traceparent；务必 defer span.finish() 防内存暴涨。
Go 链路追踪里怎么手动创建 Span 而不依赖 HTTP 中间件
直接用 tracer.StartSpan()，但必须传入有效的 context.Context，否则后续的父子关系、传播都会断掉。常见错误是传 context.Background() 后发现 Span 不进 Jaeger/Zipkin——因为没继承上游 traceID，系统把它当新链路处理了。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 从入站请求（比如 HTTP handler 的
r.Context()）或消息队列消费上下文里提取 trace 信息，用tracer.Extract()恢复SpanContext - 手动 Start 时务必把恢复后的 context 塞进去：
tracer.StartSpan("db.query", opentracing.ChildOf(spanCtx)) - 别在 goroutine 里裸用
context.Background()起 Span，除非你明确要切新链路（比如异步补偿任务）
给 Span 加 Tag 时哪些 key 是保留字、哪些会触发采样逻辑
error、http.status_code、span.kind 这类 key 是 OpenTracing / OpenTelemetry 兼容层识别的保留字段，写错格式会干扰 UI 展示或采样策略。比如设 span.SetTag("error", "timeout") 不会标红，但设 span.SetTag("error", true) 才会被识别为错误 Span。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 业务自定义 Tag 全部用小写字母 + 点号分隔，如
"user.id"、"order.amount"，避免空格和大写 - 数值型 Tag 直接传
int64或float64，别转成字符串——某些后端（如 Jaeger v1.22+）对 string 类型的数字不索引 - 敏感字段（如
user.token）绝不要打到 Tag，Span 本身不加密，日志和存储都明文可见
为什么自定义 Span 在本地跑得通，上 K8s 就丢 TraceID
根本原因是 Pod 间 HTTP 调用没透传 traceparent 或 uber-trace-id 头。Istio 默认只透传标准 W3C 字段，而 Go 里用 opentracing-go 默认发的是 Uber 格式头；反过来，如果你用 otel-go 却没配 propagators，也可能收不到。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 统一 propagator：用
otel.SetTextMapPropagator(otelpropagation.TraceContext{})强制走 W3C 标准 - 检查 Envoy Filter 或 Istio Sidecar 配置，确认
tracing.random_sampling没关死，且 header 白名单包含traceparent - 在 Span 创建后立刻 log 出
span.Context().TraceID().String()，对比上下游是否一致，比看 UI 更快定位断点
高频 Span 场景下怎么避免内存暴涨和 GC 压力
每秒几千个 Span，每个带 10+ Tag，又没及时 Finish，很容易触发 runtime.mallocgc 频繁调用。不是 Span 本身大，而是底层 span buffer 和 context 链表堆积导致对象逃逸。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有手动 Start 的 Span 必须配
defer span.Finish()，哪怕在 error 分支也得包一层if span != nil { span.Finish() } - 禁用低价值自动采集：关掉
otelhttp的WithFilter默认全埋点，改用显式包裹关键路径 - Tag 值做池化复用：比如状态码用
strconv.AppendInt(buf[:0], code, 10)而非fmt.Sprintf("%d", code)，减少小对象分配
Span 生命周期和 context 传递是耦合最紧、出问题最隐蔽的部分，调试时别只盯 UI 上有没有线，先抓包看 header 传没传、log 里 traceID 断在哪一级——很多“定制失败”其实是传播断了，不是 Span 没建好。
