正确做法是利用日志库上下文绑定机制：spdlog用thread_local+set_pattern(%v)配合，log4cplus用threadlocaldata.put()和%x{trace_id}；跨线程需显式透传，http遵循w3c trace context标准，trace_id须为32位十六进制字符串，禁用std::string_view指向临时对象。
log4cplus / spdlog 怎么注入 trace_id 到每条日志？
直接往 logger 的每个 log() 调用里塞 trace_id 参数，短期能跑，长期必崩——人会漏、宏难统一、第三方库日志进不来。
正确做法是利用日志库的「上下文绑定」机制，在线程入口一次性写入，后续所有日志自动携带。不同库实现路径不同：
-
spdlog：用spdlog::default_logger_raw()->set_level()不行，得靠spdlog::details::thread_pool无关的spdlog::sinks::sink自定义 +spdlog::details::log_msg拦截，更推荐用spdlog::set_pattern()配合%v占位符 +spdlog::source_loc外的线程局部存储（thread_local std::string current_trace_id） -
log4cplus：原生支持log4cplus::ThreadLocalData，调用log4cplus::getThreadLocalData().put("trace_id", tid)后，在 pattern 里写%X{trace_id}即可生效
如何保证跨线程、跨 async 任务不丢 trace_id？
线程局部存储（thread_local）只在当前线程有效。一旦用了 std::async、线程池、回调函数，新线程里 current_trace_id 是空的。
必须显式透传：不是复制字符串，而是把 trace_id 封装进任务对象或闭包环境里。常见错误是只传了业务参数，忘了带上下文：
立即学习“C++免费学习笔记（深入）”；
- 用
std::packaged_task包裹时，在构造时捕获当前trace_id，而不是在 task 执行时读取新线程的thread_local - 异步 HTTP 客户端（如
boost::beast）发请求前，把trace_id写进headers["X-Trace-ID"]；服务端收到后，立刻存入本线程的thread_local缓存 - 禁止在子线程里调用全局
generate_trace_id()—— 这会让链路断裂成多个独立 ID
HTTP 请求头怎么规范透传 trace_id？
别自己发明字段名。优先用 W3C Trace Context 标准：traceparent（必需）+ tracestate（可选）。手写解析容易出错，建议用现成库如 opentelemetry-cpp 的 trace::SpanContext 解析。
关键点不是“能不能传”，而是“谁负责生成、谁负责校验、谁负责拒绝非法值”：
- 入口服务（如 nginx 或网关）若没带
traceparent，应生成新的trace_id并设trace_flags = 01（采样开启） - 下游服务收到后，必须验证
traceparent格式（正则^([0-9a-f]{2})-([0-9a-f]{32})-([0-9a-f]{16})-([0-9a-f]{2})$），非法值要 fallback 到新建 trace，不能直接 panic 或丢弃请求 -
trace_id必须是 32 位十六进制字符串，不要用std::uuid直接 to_string()（带花括号和短横线）
为什么用 std::string_view 存 trace_id 会崩溃？
因为 std::string_view 不拥有数据，只引用。如果你把它指向一个临时 std::string（比如函数返回值），或者指向栈上局部变量，那在线程切换或函数返回后，string_view.data() 就指向野内存。
线上最常踩的坑是这样写：
std::string_view get_id() {
return std::string{"abc123"}; // 错！返回的是临时 string 的 view
}
正确做法只有两个：
- 用
std::string存（小字符串优化后开销极低，现代编译器下sizeof(std::string)常为 24 字节） - 如果真要零拷贝，必须确保生命周期覆盖整个 trace 生命周期：比如存进
thread_local std::string，再返回其string_view
trace_id 是链路的锚点，不是性能瓶颈点。在这里省几个字节拷贝，换来 core dump，不值得。
