直接在日志打TraceId/SpanId不够用，因C++无ThreadLocal机制，异步/回调/协程等场景下上下文易丢失；需结合thread_local栈管理、跨进程W3C注入提取、结构化日志及异步原语拦截才能完整透传。
为什么直接在日志里打 TraceId 和 SpanId 不够用
因为 C++ 没有像 Java 的 ThreadLocal 那样开箱即用的上下文透传机制，日志写入点（比如某个异步回调、线程池任务、协程切换）往往和 trace 初始化点不在同一个执行流里。你手动把 TraceId 传进每个函数参数，不仅污染业务逻辑，还极易漏传——尤其是第三方库回调、定时器触发、信号处理等场景。
用 std::thread_local + RAII 管理当前 span 上下文
核心思路是：让每个线程持有唯一的、可嵌套的 span 上下文，并在 span 创建/结束时自动更新。关键不是“存”，而是“进出作用域时自动绑定/解绑”。
实操建议：
- 定义一个
ThreadLocalSpanContext类，内部用std::thread_local std::stack<:shared_ptr>> s_span_stack存储当前线程的 span 调用栈 - 每次进入新 span（如 RPC 入口、HTTP handler），构造一个
SpanGuard对象，它在构造时 push 到栈顶，析构时 pop —— 这就保证了即使跨函数、跨回调，只要在同一线程，GetCurrentSpan()就能拿到最新有效的 span - 日志宏（如
LOG_INFO）内部调用GetCurrentSpan()->GetTraceId()和GetCurrentSpan()->GetSpanId()，无需业务代码显式传参 - 注意：协程（如 libco、Boost.Coroutine2）不共享线程栈，需额外 hook 切换点，在 resume 时恢复目标协程关联的 span 栈
跨线程/跨进程传递必须靠 Inject() 和 Extract()
仅靠线程局部存储解决不了 RPC、消息队列、线程池投递等场景。必须把 trace 上下文序列化后塞进传输载体（HTTP Header、gRPC Metadata、Kafka Message Header、自定义二进制协议字段）。
实操建议：
- 统一使用 W3C Trace Context 格式（
traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01），避免自定义格式导致上下游系统无法识别 - 在发起 RPC 前，调用
tracer->Inject(span->context(), carrier)，其中carrier是 map或 HTTP header 容器；服务端收到请求后，用 tracer->Extract(carrier)恢复 context 并创建 child span - 别漏掉线程池任务：提交任务前，捕获当前
GetCurrentSpan()，作为 closure 捕获变量传入；任务执行时先用该 span 构造SpanGuard，再执行业务逻辑
日志输出格式要预留结构化字段，别只拼字符串
如果只是在 log 字符串开头硬加 [TraceId=xxx SpanId=yyy]，后续用 ELK 或 Loki 做 trace 关联时，还得写正则提取，既慢又易错。
实操建议：
- 用支持结构化输出的日志库（如
spdlog配合json_formatter，或g3log自定义 sink），确保每条日志天然带"trace_id"、"span_id"、"parent_span_id"字段 - 字段名严格对齐 OpenTelemetry 日志语义约定（
trace.id,span.id），方便与 traces 数据自动 join - 避免在日志中打印完整 span context 对象（含采样标志、vendor 扩展），只输出必要串联字段；调试信息可单独走 debug 日志通道
真正难的不是某一行代码怎么写，而是 span 生命周期管理边界是否清晰——比如一个异步 MySQL 查询回调，它的 parent span 应该是发起查询时的 span，而不是回调线程刚创建的空 span。这要求你在所有异步原语（promise/future、libevent 回调、asio handler）上做统一拦截和上下文恢复，漏一处，链路就断一截。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
