应使用宏包裹std::source_location::current()以确保记录调用点而非函数定义处的文件与行号；宏内避免多余语句或换行，推荐用std::filesystem::path裁剪路径，其运行时开销可忽略。
std::source_location 在日志宏里怎么写才不崩？
直接用 std::source_location::current() 生成日志上下文是安全的，但必须在宏里调用——如果把它塞进普通函数参数，行号会固定成那个函数的定义位置，而不是调用点。这是最常踩的坑。
- 必须用宏包裹，否则
std::source_location::current()拿到的是函数内部的行号，不是日志调用处 - 宏里不要加额外语句或换行，避免预处理器展开异常（尤其在 Windows + MSVC 下容易出错）
- Clang 和 GCC 10+、MSVC 2019 16.8+ 才真正稳定支持；老版本可能静默退化为默认构造值（
line = 1）
示例宏定义：
#define LOG_INFO(msg)
do {
auto loc = std::source_location::current();
fprintf(stderr, "[%s:%d] %s
", loc.file_name(), loc.line(), msg);
} while(0)为什么不能把 source_location 当函数参数传？
因为 std::source_location::current() 是编译期求值的：它在**调用点**被展开，记录该处的文件、行、列和函数名。一旦你写成 log_impl("msg", std::source_location::current())，这个 current() 就在 log_impl 调用表达式所在行执行——看起来没问题，但实际调用栈上它已经脱离原始上下文。
- 如果
log_impl是 inline 函数，部分编译器（如旧版 GCC）仍可能把current()绑定到内联后的位置，导致行号漂移 - 非 inline 函数必然固定为调用语句那行，而非原始日志宏展开点
- 正确做法是让
source_location在宏体内“当场出生”，再传给底层日志函数（可带const std::source_location&参数）
file_name() 返回的路径太长，怎么截取文件名？
std::source_location::file_name() 返回的是完整绝对路径（取决于编译器如何传入），Windows 下常见 "D:/proj/src/main.cpp"，Linux 下可能是 "/home/user/proj/src/main.cpp"。它不提供内置裁剪，得自己处理。
立即学习“C++免费学习笔记（深入）”；
- 别用
std::string::rfind('\')或rfind('/')然后 substr —— Windows 下两种分隔符都可能出现，且某些构建系统（如 Bazel）可能用正斜杠模拟反斜杠语义 - 更稳妥是用
std::filesystem::path(file_name()).filename().string()，但要注意：C++17<filesystem></filesystem>在部分嵌入式或精简环境不可用 - 轻量替代：从末尾向前扫描，跳过所有
'/'和'\'，找到第一个非分隔符位置开始截取（几行手写逻辑比引入 fs 更可控）
和 __FILE__ / __LINE__ 相比，source_location 有啥实际代价？
几乎没有运行时代价：std::source_location 是 trivially copyable 的 POD 类型，三个整数字段（line、column、scope_len）+ 一个 const char*（指向只读段里的字符串字面量）。它的构造完全在编译期完成，不会产生函数调用或内存分配。
- 相比
__FILE__（char* 字面量）和__LINE__（整数字面量），它多存了函数名和列号，体积略增，但现代日志库通常只用 file + line，可忽略 - 真正要注意的是：如果你把
source_location存进日志队列或跨线程传递，确保它引用的file_name()字符串生命周期足够长——它指向编译器生成的只读字符串，只要程序没卸载就一直有效 - 调试时注意：GDB/Lldb 对
source_location成员变量的显示支持尚不统一，有时需手动打印loc.file_name()而非直接 print loc
真正麻烦的从来不是怎么记下位置，而是当多个宏嵌套、模板实例化层层展开时，你得确定最终落到哪一层的 source_location 才是你想 debug 的那一行。
