直接在日志宏里加 TraceId 和 SpanId 会出错，因为 C++ 无运行时协程上下文，全局或 thread_local 变量无法跨线程/异步回调正确传递 trace 上下文，导致串号或丢失；可靠方案是用 OpenTelemetry Logs SDK 显式传入 SpanContext 并通过 RAII 封装 TracedLogger。
为什么直接在日志宏里加 TraceId 和 SpanId 会出错
因为 C++ 没有运行时协程上下文（比如 Go 的 goroutine local storage 或 Java 的 ThreadLocal），而 OpenTracing / OpenTelemetry 的 trace_id 和 span_id 是绑在当前执行流上的。如果只是全局变量或静态 TLS 变量，跨线程、跨异步回调、跨 std::async 或第三方线程池时，TraceId 就会丢失或串号。
常见错误现象：log output shows same TraceId across unrelated requests，或者 SpanId is empty in async callback logs。
- 别用
thread_local static std::string g_current_trace_id手动赋值——你很难保证每次进函数都手动 set - 别依赖日志库自带的 “MDC” 类功能（如 spdlog 的
set_pattern+set_level配合自定义 sink）——它不感知 trace 生命周期 - OpenTelemetry C++ SDK 默认不自动注入日志字段，得自己桥接
用 OpenTelemetry C++ 的 opentelemetry::trace::Scope + 自定义 logger wrapper
核心思路：把 trace 上下文和日志行为绑定在同一个作用域内，靠 RAII 管理生命周期。不是“往每条 log 里塞字符串”，而是让 logger 实例本身持有当前 scope 的 context。
实操建议：
- 封装一个
TracedLogger类，构造时传入opentelemetry::trace::SpanContext（可从tracer->GetCurrentSpan()->GetContext()拿） - 重载
info()/error()等方法，在内部调用原始 logger 前，先从 span context 提取trace_id.ToString()和span_id.ToString() - 避免在异步任务中捕获栈上
SpanContext——要用std::shared_ptr持有，否则回调执行时 context 已销毁 - 示例片段：
auto current_span = tracer->GetCurrentSpan(); auto ctx = current_span ? current_span->GetContext() : opentelemetry::trace::SpanContext::GetInvalid(); auto logger = std::make_shared<tracedlogger>(spdlog::get("app"), ctx); // 传 shared_ptr 或拷贝值 logger->info("request processed"); // 自动注入 trace_id=0123... span_id=abc...</tracedlogger>
在 spdlog 中通过 custom_flag_formatter 注入，但必须配合上下文传递
spdlog 支持自定义格式标记（如 %t），但它本身没有上下文感知能力。所以不能只注册 formatter，还得让每条 log 调用时能访问到当前 trace context。
可行做法：
- 定义一个 thread_local 变量
thread_local opentelemetry::trace::SpanContext g_tls_span_ctx，但只在明确受控的入口点（如 HTTP handler 开始）设置它，并在 handler 结束时清空 - 写 formatter：
struct TraceIdFormatter { void format(const spdlog::details::log_msg &msg, const std::tm &, spdlog::memory_buf_t &dest) { auto tid = g_tls_span_ctx.trace_id().ToString(); fmt::format_to(dest, "{}", tid.substr(0, 8)); // 截断防日志过长 } }; - 注册：
spdlog::register_formatter(，然后在 pattern 里用std::make_shared);() %t - ⚠️ 注意：这个方案只适用于单线程同步模型；若用了
asio::post、std::jthread或任何线程切换，g_tls_span_ctx就断了
真正可靠的方案：用 OpenTelemetry 的 LogRecord API 直接 emit
OpenTelemetry C++ SDK 1.10+ 正式支持 Logs SDK（不再是 experimental）。这意味着你可以绕过传统 logger，直接用 OTel 的 LoggerProvider 创建 logger，并在 EmitLogRecord 时显式传入 trace context —— 这是唯一能 100% 对齐 trace 生命周期的方式。
关键点：
- 不用改现有日志调用点？不行。得把
LOG_INFO 替成otel_logger->EmitLogRecord(...) - 必须传
opentelemetry::logs::Severity、opentelemetry::common::SystemTimestamp、以及opentelemetry::trace::SpanContext - 好处是：log record 会自动被 exporter 当作 trace 关联事件（event），在 Jaeger / Grafana Tempo 里点开 span 就能看到内嵌日志
- 性能影响：比 printf-style logger 略重，但可控；建议用
opentelemetry::logs::LoggerProvider::GetLogger("mylib")单例复用
复杂点在于，你需要在每个可能产生日志的地方确保 SpanContext 可达——这往往意味着把 trace context 作为参数向下传递，或用 scoped wrapper 包裹业务逻辑。很多人卡在这一步，不是技术不会，是改造粒度太细，容易漏。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
