std::source_location不能直接用于跨平台分布式日志自动定位，仅能在已有OpenTelemetry等trace框架下对齐日志与span的代码锚点；其current()必须作为默认参数在调用点注入，否则指向封装位置；file_name()和function_name()跨平台不可靠，需手动裁剪路径、禁用函数名聚合；它不携带trace上下文，不可序列化，仅作日志与trace对齐之用。
std::source_location 不能直接用于跨平台分布式日志的“自动定位”，它只提供编译期位置快照，不携带 trace 上下文、无法序列化、且跨编译器行为不一致；真正能用的前提是：你已有分布式 trace 框架（如 OpenTelemetry），而它只是用来对齐日志与 span 的代码锚点。
为什么 std::source_location::current() 总是指向错误行
常见现象是所有日志都显示 logging.cpp:27 或宏定义行，而非业务代码真实调用处。这是因为 std::source_location::current() 是 consteval 函数，返回值在编译期就固化为它被写出的那一行 —— 如果你把它写在函数体里、宏定义里、或中间封装层里，那它永远指向那个位置。
- 错误写法：
void log(const char* msg) { auto loc = std::source_location::current(); /* 固定指向这行 */ } - 错误写法：
#define LOG(msg) log(msg, std::source_location::current())（Clang -O2 下可能提前求值） - 正确写法：必须作为带默认值的函数参数，且调用时不传该参数：
void log(const char* msg, const std::source_location& loc = std::source_location::current()) - 调用时写
log("timeout")即可，编译器会在每个调用点注入真实位置
跨平台路径和函数名为什么不可信
file_name() 返回的是编译器传入的原始路径字符串，Linux/macOS 多为 /home/user/proj/src/log.cpp，Windows 可能是 C:projsrclog.cpp 或带 .srclog.cpp；function_name() 更混乱：GCC 默认为空，Clang 返回 void foo()，MSVC 返回修饰名如 ?foo@@YAXXZ —— 这些字段不能直接用于 trace tag 聚合或服务端解析。
- 短文件名必须在调用点裁剪，不能在 logger.cpp 里统一处理（否则分布式节点间路径逻辑不一致）
- 推荐用
std::filesystem::path(loc.file_name()).filename().c_str()，C++17 起语义可靠 - 若需零开销且限 Linux/macOS，可用
strrchr(loc.file_name(), '/')；Windows 需额外分支处理'\' - 绝对不要依赖
function_name()做跨语言匹配或聚合维度，改用显式宏标签（如LOG_TAG("db_query")）
它和分布式 trace context 怎么配合才不丢信息
std::source_location 本身没有 trace_id、span_id、时间戳，也不能跨进程传输。它唯一合理用途，是在已有 trace 上下文的系统中，让每条日志带上精确代码位置，从而和 trace 日志对齐。
立即学习“C++免费学习笔记（深入）”；
- 日志函数签名应含 trace context 参数：
void log_with_trace(const char* msg, const opentelemetry::trace::SpanContext& ctx, const std::source_location& loc = std::source_location::current()) - 输出格式建议：
[0x1a2b3c][main.cpp:42] DB query timeout，其中 trace_id 来自ctx.trace_id()，位置来自loc - 禁止序列化
std::source_location对象本身 —— 它不含运行时数据，只提取file_name()字符串、line()整数等字段再组合成日志 payload - 禁用 TLS 缓存或静态存储：每个日志调用都必须走
= std::source_location::current()注入，否则位置会固化
最易被忽略的一点：它不是“分布式日志定位”的解法，而是“已有分布式追踪链路下的日志对齐工具”。如果你还没接入 OpenTelemetry 或类似 SDK，先别碰 std::source_location —— 它解决不了 trace 上下文缺失、跨服务传播、采样控制这些根本问题。
