std::source_location::current() 必须在调用点直接使用，否则日志位置固定于定义处；路径裁剪、标签注入等操作须同步完成，不可延迟至 logger 实现层，否则导致跨节点日志语义断层。
std::source_location 不能自动对齐分布式 trace，它只在你已有 OpenTelemetry 或 Zipkin 上下文的前提下，为日志补上准确的 file:line 锚点；用错位置（比如塞进 trace context、提前缓存、中间转发）会导致所有日志指向同一行。
std::source_location::current() 总是显示 logging.cpp:27 怎么办
这是最常见误用：你在日志函数体里写了 std::source_location::current()，它就永远固定在那一行。编译器不会“猜”你调用它的意图，它只忠实地记录自己被求值的位置。
- 错误写法：
void log(const char* msg) { auto loc = std::source_location::current(); /* 这行就是 loc 的来源 */ } - 正确写法：
void log(const char* msg, const std::source_location& loc = std::source_location::current());，调用时只写log("timeout") - 宏封装更可靠：
#define LOG(msg) ::detail::log_impl((msg), std::source_location::current())，宏展开后current()真正落在用户源码行 - 禁用任何模板转发、
std::function包装或 lambda 捕获——这些都会把位置“上浮”到包装层
跨平台 file_name() 路径太长且格式不一致怎么裁剪
std::source_location::file_name() 返回的是编译器传入的原始路径字符串，Linux 是 /home/ci/src/log.cpp，Windows 可能是 C:projsrclog.cpp，CI 构建还可能带 ./ 前缀。统一裁剪必须发生在调用点，不能交给 logger 实现层处理。
- 推荐零开销方案（限 Linux/macOS）：
const char* last = strrchr(loc.file_name(), '/'); return last ? last + 1 : loc.file_name(); - Windows 兼容分支需额外判断：
strrchr(loc.file_name(), '\')，并取两者偏移更大的结果 - 若项目已用 C++17，可用
std::filesystem::path(loc.file_name()).filename().c_str()，语义明确但有轻微构造开销 - 绝对不要在 logger.cpp 里对
loc.file_name()做std::string构造——高频日志下堆分配会成为瓶颈
为什么不能依赖 function_name() 做 trace tag 聚合
std::source_location::function_name() 在不同编译器下行为完全不可控：GCC 默认返回空字符串，Clang 返回带签名的 void foo(int)，MSVC 返回修饰名如 ?foo@@YAXXZ。它既不能跨语言匹配，也不能用于服务端聚合维度。
立即学习“C++免费学习笔记（深入）”；
- 禁止将
function_name()直接写入 JSON 日志体或 trace tag 字段 - 替代方案：在调用点显式传入轻量标签，例如
LOG_TAG("db_query")宏，或在日志函数签名中加const char* tag参数 - 若必须关联函数语义，应由构建系统（如 CMake）注入
-DLOG_FUNCTION=__func__，再配合宏展开，而非依赖source_location - 记住：
function_name()是调试辅助字段，不是运行时标识符
真正容易被忽略的点是：所有裁剪逻辑（路径、标签、trace ID 提取）必须和 std::source_location::current() 出现在同一调用点。一旦拆到不同函数或编译单元，跨节点日志就无法保证一致性——这不是性能问题，是语义断层。
