std::source_location不能替代OpenTelemetry上下文传播，因其仅含编译期代码位置信息，无trace_id、span_id、时间戳及序列化能力，仅适用于与已有trace context对齐的日志记录。
std::source_location 不能直接注入分布式 trace context，它只提供编译期快照，不带 trace_id、span_id、时间戳或序列化能力——想靠它替代 OpenTelemetry 的上下文传播，会立刻卡在跨进程传输这一步。
std::source_location::current() 为什么不能填进 trace 上下文
它返回的是一个仅含 file_name()、line()、column()、function_name() 的 trivial 结构体，所有字段都是编译期常量：
-
file_name()返回const char*，指向只读字面量，无法动态拼接trace_id - 没有时间字段，
std::chrono::steady_clock::now()必须额外手动获取并组合 - 无任何线程/协程上下文感知，不会自动关联当前 gRPC 或 HTTP 请求 scope 中的 span
- 结构体未定义序列化协议，
std::source_location对象不能直接 JSON 化或 protobuf 编码传给下游服务
它真正能用在分布式追踪里的位置：日志对齐 trace_id
在已有 trace context（如 OpenTelemetry SDK 注入）的系统中，std::source_location 的价值是让每条日志自带精确代码位置，和 trace 日志对齐，避免“看到 trace 报错却找不到对应 log 是哪一行打的”：
- 必须配合 trace context 提取器使用：比如从
opentelemetry::context::RuntimeContext::GetCurrent()拿到当前 span，再调用span.GetTraceId() - 日志函数签名应为：
void log_with_trace(const char* msg, const opentelemetry::trace::SpanContext& ctx, const std::source_location& loc = std::source_location::current()) - 输出格式建议包含
trace_id+file:line，例如：[0x1a2b3c][main.cpp:42] DB query timeout - 别在日志里重复解析
file_name()：高频路径下用std::string_view(loc.file_name()).substr()替代std::string构造，避免堆分配
跨平台路径与函数名不可信，必须裁剪和替换
file_name() 和 function_name() 在 GCC/Clang/MSVC 下行为差异极大，直接用于 trace tag 会导致字段不一致甚至崩溃：
立即学习“C++免费学习笔记（深入）”；
- GCC 默认
function_name()返回空字符串；Clang 返回"void foo()"；MSVC 返回修饰名（如"?foo@@YAXXZ"），无法做跨语言匹配 -
file_name()可能是绝对路径（/home/user/src/log.cpp）、相对路径（src/log.cpp）或带.前缀（Windows 常见），需统一裁剪为短文件名 - 裁剪必须发生在调用点：定义
const char* short_file_name(const char* full)，用std::filesystem::path(full).filename().c_str()（C++17 起）确保语义正确；若只跑 Linux/macOS，可用strrchr(full, '/')，Windows 下补strrchr(full, '\')分支 - 禁止在 logger.cpp 中对
loc.file_name()做字符串操作——所有路径裁剪必须在调用点完成，否则分布式节点间一致性无法保证
编译器支持与默认参数写法是硬门槛
低版本编译器会返回空 function_name() 或固定行号，导致跨平台追踪失效；且参数写法稍有偏差就会记录错位置：
- GCC 12+、Clang 13+、MSVC 16.8+ 才稳定支持；GCC 10 不支持，Clang 11 部分功能缺失
- CMake 中必须显式启用：
set(CMAKE_CXX_STANDARD 20)+set(CMAKE_CXX_STANDARD_REQUIRED ON) - 参数必须是值传递：
std::source_location loc = std::source_location::current()；不能是const std::source_location&（C++ 不允许绑定临时对象的 const 引用） - 不能写成
std::source_location loc = {}或在函数体内调用std::source_location::current()——那会固定返回该函数定义处的位置
最易被忽略的一点：std::source_location 本身不参与 trace 生命周期管理。它只是个锚点，一旦 trace context 被销毁或跨线程丢失，这个锚点就失去上下文意义——你得确保日志打点和 span 存活在同一个 scope 内，而不是靠它“自动同步”。
