std::source_location是C++20引入的轻量结构体，自动记录调用点的文件名、行号、列号和函数符号名；其file_name()、line()、column()、function_name()在编译期捕获，零开销且类型安全。
std::source_location 是什么，它能自动记录哪些信息
std::source_location 是 C++20 引入的轻量结构体，用于在编译期捕获调用点的源码位置。它不依赖运行时栈遍历，也不触发函数内联抑制——只要编译器支持（GCC 10+、Clang 12+、MSVC 19.30+），就能零开销拿到 file_name()、line()、column() 和 function_name()。
注意：function_name() 返回的是编译器生成的符号名（如 "void log(const char*, const std::source_location&)"），不是用户友好的函数签名；若需可读名，得配合宏或调试信息解析，但那已超出 std::source_location 本身能力。
如何用宏封装避免手动传参
直接在每个 log() 调用处写 std::source_location::current() 不仅啰嗦，还容易漏——尤其在条件日志或封装层中。正确做法是用宏自动注入：
#define LOG(msg) log(msg, std::source_location::current())
这样调用 LOG("buffer overflow") 时，宏展开后 std::source_location::current() 在**调用点**求值，而非在 log() 函数体内，确保文件名和行号指向真实出问题的位置。
立即学习“C++免费学习笔记（深入）”；
常见错误包括：
- 把
std::source_location::current()写进函数默认参数（C++20 允许，但多数编译器不支持该场景的准确捕获） - 在内联函数里用默认参数代替宏，结果所有调用都报告内联函数定义处的行号
- 宏里忘了加括号包裹
msg，导致带逗号的字符串字面量（如"err: %d", x）编译失败
与传统 __FILE__ / __LINE__ 相比有什么实际差异
__FILE__ 和 __LINE__ 是预处理指令，类型为 const char* 和 int，而 std::source_location 是类型安全的类类型，支持隐式构造、移动、比较，且字段访问明确（file_name() 返回 std::string_view，不是裸指针）。
关键区别在于语义和可扩展性：
-
__FILE__可能包含绝对路径，file_name()默认也是，但你可以用std::filesystem::path(file_name()).filename().string()安全截取（注意：这会引入<filesystem></filesystem>依赖和运行时开销） -
__LINE__是整数字面量，line()是unsigned int，更易参与模板推导或 constexpr 计算 - 某些日志库（如 spdlog）已提供
SPDLOG_LOGGER_CALL宏，内部就基于std::source_location，升级后无需改业务代码
编译器兼容性和调试体验陷阱
即使开了 -std=c++20，GCC 10–11 默认不启用 std::source_location 的完整支持；必须额外加 -frecord-gcc-switches（非必需）或确认 __cpp_lib_source_location >= 201907L 宏已定义。检查方式：
#if !defined(__cpp_lib_source_location) || __cpp_lib_source_location < 201907L #error "std::source_location not supported" #endif
调试时容易忽略的一点：file_name() 返回的字符串视图生命周期绑定到当前编译单元，若你把它存进异步日志队列并延迟格式化，原始内存可能已失效——必须立即拷贝为 std::string 或确保日志消费与记录同步。
另外，MinGW-w64 在较老版本中对 function_name() 返回空字符串，不是 bug，是 ABI 限制；别依赖它做逻辑分支。
