std::source_location是C++20引入的编译期定位结构体，不能直接替代宏，但可通过默认参数机制在函数调用处自动捕获真实位置；需避免手动构造、缓存或跨函数复用，提取文件名应手动截取路径末段，兼容性与编译器版本强相关。
std::source_location 是什么，它真能替代宏吗
std::source_location 是 C++20 引入的轻量结构体，用于在编译期捕获调用点的文件名、函数名、行号和列号。它不是运行时反射，也不依赖 __FILE__ 或 __LINE__ 宏展开，而是由编译器在函数调用时自动填充默认参数——这点很关键：你必须让它作为函数参数（且带默认值），否则拿不到真实调用位置。
常见误区是直接构造：std::source_location::current()，这返回的是该语句所在位置，而非日志调用处。真正有用的写法是让日志函数接收一个默认参数：
void log(const char* msg, std::source_location loc = std::source_location::current());
这样每次调用 log("error") 时，loc 自动绑定到这一行，而不是 log 函数内部的 current() 调用点。
如何安全提取文件名（不带路径）和行号
std::source_location 提供 file_name()，但返回的是完整路径字符串（如 "/home/user/proj/src/main.cpp"），直接打日志会冗长且暴露构建路径。需要截取最后一段文件名。
立即学习“C++免费学习笔记（深入）”；
注意：C++20 没有内置路径解析，别用 std::filesystem::path 做这个——它可能触发动态分配，且在嵌入式或无 std::filesystem 支持的环境下不可用。稳妥做法是手动查找最后一个 / 或 ：
- 用
std::string_view包装loc.file_name()，避免拷贝 - 从后往前找分隔符，用
rfind；Windows 和 POSIX 路径都需兼容 - 若没找到分隔符，整个字符串就是文件名（比如裸文件名传入测试）
示例片段：
std::string_view file(loc.file_name());
size_t last_slash = file.find_last_of("/\");
if (last_slash != std::string_view::npos) {
file.remove_prefix(last_slash + 1);
}
// file 现在是 "main.cpp"
int line = loc.line();为什么不能把 source_location 存起来长期用
std::source_location 对象本身是 trivially copyable，但它的 file_name() 返回的是 const char*，指向编译器生成的只读字符串字面量——这部分内存生命周期与程序相同，所以“存起来”本身不会崩溃。但问题出在语义上：
- 它记录的是“构造时”的调用点，不是“使用时”的位置。如果存成成员变量或全局缓存，后续所有日志都会显示同一个位置
- 多线程下若共享一个预设的
source_location实例，所有线程日志都指向初始化那一行，完全失去追踪意义 - 某些编译器（如早期 GCC 11）对
std::source_location::current()的内联优化不完善，可能导致内联函数中捕获的位置偏移
结论：必须每次日志调用都生成新的 std::source_location 实例，通过默认参数机制完成，不要缓存、不要复用、不要跨函数传递原始实例。
兼容性与性能要注意的几个硬伤
不是所有 C++20 编译器都完整支持 std::source_location，尤其在交叉编译或旧工具链中：
- Clang 11+、GCC 12+、MSVC 19.30+ 支持较稳；GCC 11 只支持基本字段，
function_name()可能为空 - 启用
-std=c++20不够，还需确认标准库实现（libstdc++ 12+ / libc++ 13+ / MSVC STL 已同步） - 性能上几乎零开销：无函数调用、无栈遍历、无 RTTI，纯编译期常量注入；但频繁构造
std::string_view截取文件名会有少量计算成本，建议在日志等级为 debug 时才解析，error/warn 级可只记完整路径
最易被忽略的一点：如果你的日志宏里还混用了 __FILE__，而函数又同时接受 std::source_location，两个位置可能不一致——因为宏展开发生在预处理阶段，而 source_location 是编译阶段行为。统一用后者，删掉宏。
