std::source_location 仅适用于为已有分布式 trace 添加代码位置锚点，不可替代 OpenTelemetry/Zipkin 的 trace context；它不可序列化、无 trace_id、跨平台路径与函数名不一致，且 current() 在编译期固化，须通过带默认参数的函数调用才能获取真实位置。
std::source_location 不能替代 OpenTelemetry 或 Zipkin 的 trace context，它只适合在已有分布式 trace 链路中为日志添加精准代码位置锚点。 直接把它塞进 HTTP header、gRPC metadata 或日志结构体里传给下游服务，会失败——它没有 trace_id、不能序列化、跨平台路径和函数名也不一致。
为什么 std::source_location::current() 总是指向 logging.cpp 而不是业务代码行
因为 std::source_location::current() 是 consteval 函数，值在编译期就固化为它被写出的那一行。常见错误包括：
- 在封装函数体内调用：
auto loc = std::source_location::current();→ 永远返回该函数定义行 - 用宏包装：
#define LOG(m) log(m, std::source_location::current())→ 展开后位置塌缩到宏定义处 - 提前缓存为成员变量或 TLS 变量 → 所有日志都复用同一个位置
正确做法只有一种：函数参数带默认值，且调用时不传参。
void log_with_trace(const char* msg,
const opentelemetry::trace::SpanContext& ctx,
const std::source_location& loc = std::source_location::current());
调用时写 log_with_trace("timeout", current_span_context())，编译器会在每个调用点注入真实位置。
跨平台短文件名裁剪必须在调用点完成
loc.file_name() 返回的路径格式因平台和构建系统而异：GCC 可能是 /home/user/src/db.cpp，MSVC 可能是 C:projsrcdb.cpp，CI 构建还可能带 ./ 前缀。统一裁剪不能靠运行时逻辑，必须在每处 log_with_trace 调用处完成，否则分布式节点间无法对齐。
- 推荐方案（C++17 起）：
std::filesystem::path(loc.file_name()).filename().c_str()，语义清晰、自动处理分隔符 - 零开销方案（Linux/macOS）：
strrchr(loc.file_name(), '/')后取子串 - Windows 兼容需额外判
'\'：#ifdef _WIN32分支 - 绝对禁止在 logger 实现里做字符串操作——高频日志下
std::string构造会触发堆分配
function_name() 在 GCC/Clang/MSVC 上完全不可信
loc.function_name() 跨编译器行为差异极大，不能用于 trace tag 聚合或服务端解析：
- GCC 默认返回空字符串
"" - Clang 返回带签名的
"void handle_request()" - MSVC 返回修饰名如
"?handle_request@@YAXXZ"
解决方案很直接：
- 禁用
function_name()作为任何 trace 字段（比如 Span attribute 中的"function"键） - 仅依赖
loc.file_name()和loc.line()—— 这两个字段在所有主流编译器上都稳定非空 - 若需函数标识，改用
__func__宏（C++11 起），并确保编译器启用调试信息（-g//Zi）
它和 OpenTelemetry 的 span context 必须绑定在同一调用点
std::source_location 本身不感知线程、协程或请求 scope，也不会自动关联当前 span。你必须手动从运行时上下文中提取 trace ID，并和位置信息拼接输出：
- 获取当前 span：
opentelemetry::context::RuntimeContext::GetCurrent() - 提取 trace ID：
ctx.GetTraceId().to_string() - 输出格式建议：
[0x1a2b3c][db.cpp:42] DB query timeout - 禁止将
std::source_location和 trace context 分开传递，或在不同函数中分别获取——位置和 trace ID 必须来自同一调用点，否则日志与链路脱节
最易被忽略的一点：裁剪路径、拼接 trace ID、格式化字符串，这三步必须都在内联日志函数体内完成，且不能引入任何堆分配。一旦放到 logger.cpp 里做通用处理，就等于放弃跨平台一致性与性能控制权。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
