std::source_location 不能用于分布式 trace 上下文传播，仅适用于日志与 trace 行级对齐；误用导致位置固定在封装函数处，需内联调用并避免中间层转发，裁剪路径须在调用点完成。
std::source_location 不能直接用于分布式构建系统的 trace 上下文传播，它只提供编译期快照，不携带 trace_id、span_id 或时间戳；真正能用的场景是：在已有 OpenTelemetry SDK 注入 trace context 的前提下，为每条日志打上精准的 file_name() 和 line() 锚点，实现日志与 trace 的行级对齐。
为什么 std::source_location::current() 在构建系统里总显示 build.cpp:15？
这是最常误用的点：你在日志封装函数内部写 std::source_location::current()，它就永远固定在那个函数定义处。构建系统（如 Bazel、CMake + Ninja）本身不改变这一行为——问题出在调用链层级。
- 构建脚本调用的是你写的
log_info("build started")，但如果这个函数被中间层（比如BuildLogger::write()）转发一次，std::source_location就变成BuildLogger.cpp里的行号，不是用户 BUILD 文件或 CMakeLists.txt 所在行 - 模板函数、lambda 包装、甚至
std::function回调都会截断调用点，导致位置信息“上浮”失败 - CI 构建节点上若启用 LTO 或跨编译单元内联，
std::source_location仍能保持准确，但前提是函数签名中必须显式声明默认参数，且不能被编译器优化掉调用点语义
如何让日志同时带 trace ID 和源码位置（零开销方案）
关键不在 std::source_location 本身，而在它和 opentelemetry::trace::SpanContext 的绑定时机。必须确保两者都在同一调用点注入，否则日志会和 trace 断连。
- 定义内联日志函数：
inline void log_trace(const char* msg, const opentelemetry::trace::SpanContext& ctx, const std::source_location& loc = std::source_location::current()) - 在函数体内用
ctx.trace_id().to_string()拿 trace ID，用loc.file_name()和loc.line()拿位置——不要提前提取或缓存loc - 调用时必须直接写
log_trace("linking failed", current_span_context())，不传第三个参数；手动传std::source_location::current()会导致所有日志挤在头文件某一行 - 避免任何 TLS 缓存或静态局部变量保存
std::source_location，它一旦构造完成，位置就固化了
跨平台构建中 file_name() 路径裁剪必须发生在调用点
std::source_location::file_name() 返回绝对路径，而不同 CI 环境（Linux CI runner、macOS self-hosted、Windows Azure Pipelines）路径结构差异极大：/home/builder/workspace/src/main.cpp vs C:gent_workssrcmain.cpp。硬切字符串会崩，统一裁剪逻辑必须在调用点执行。
立即学习“C++免费学习笔记（深入）”；
- 推荐轻量方案（无
std::filesystem开销）：const char* short_file_name(const char* full) { const char* p = strrchr(full, '/'); return p ? p + 1 : (p = strrchr(full, '\')) ? p + 1 : full; } - 若已用 C++17+ 且不介意轻微开销，可用
std::filesystem::path(full).filename().c_str()，但注意c_str()返回指针生命周期绑定到临时std::string，需立刻使用或拷贝 - 绝对不要在 logger 实现文件里对
loc.file_name()做std::string构造——高频构建日志下隐式堆分配会拖慢整个 pipeline - Clang 13+、GCC 12+、MSVC 16.8+ 对
file_name()支持稳定，但function_name()在 GCC 下常为空，别依赖它做构建阶段聚合
真正难的不是获取位置，而是保证它不被任何一层封装吞掉——从 BUILD 规则触发、到 CMake 配置加载、再到最终编译命令执行，只要中间多一个函数跳转，std::source_location 就不再指向原始意图位置。它本质是个“单跳快照”，设计时就得按“一跳直达”来约束调用链。
