std::source_location 是什么，能拿到哪些信息？
std::source_location 是 C++20 引入的轻量结构体，用于在编译期捕获调用点的源码位置。它不依赖运行时调试信息或符号表，也不需要宏展开以外的额外开销——本质上是编译器在调用 std::source_location::current() 时，把当前行号、文件名、函数名等字面量直接塞进对象里。
它能稳定获取四项信息：file_name()、line()、column()、function_name()。注意：function_name() 返回的是声明该调用点的函数名（即日志语句所在函数），不是调用栈上层的函数；且不同编译器对函数名的格式处理不同（如 GCC 带完整签名，MSVC 通常只给未修饰名）。
如何在日志函数中自动捕获调用位置？
必须用默认参数 + std::source_location::current()，且该参数不能是 const 引用（否则无法绑定临时对象）。典型写法如下：
void log(const char* msg, const std::source_location loc = std::source_location::current()) {
std::cerr << "[" << loc.file_name() << ":" << loc.line()
<< "] " << loc.function_name() << " - " << msg << "\n";
}调用时完全透明：log("user logged in"); 就会输出类似 [main.cpp:42] main - user logged in 的内容。关键点：
立即学习“C++免费学习笔记（深入）”；
- 参数必须有默认值，且只能是
std::source_location::current()调用（不能是变量或自定义表达式） - 不能写成
const std::source_location& loc = ...—— 编译器不允许绑定到临时对象的非 const 引用 - 如果函数是模板或内联的，
current()捕获的是实际调用点，不是实例化点或头文件里的定义位置
为什么有时 file_name() 返回空或奇怪路径？
file_name() 返回的是编译器传入的 __FILE__ 字符串，行为完全取决于编译器和构建配置：
- Clang/GCC 默认返回相对路径（相对于当前工作目录），若构建系统没设好工作目录，可能显示
../src/log.h或甚至./log.h - MSVC 默认返回绝对路径，但可通过
/FC编译选项强制为相对路径 - 某些构建工具（如 Bazel、Ninja）可能重写
__FILE__，导致路径不可读；CMake 中可加set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -frecord-gcc-switches")辅助调试，但这不影响source_location - 如果看到空字符串或乱码，大概率是用了自定义预处理器宏覆盖了
__FILE__，或链接了不兼容的旧版标准库（如 libstdc++ 11 以下不支持source_location）
和传统 __FILE__/__LINE__ 宏比有什么坑？
表面看 std::source_location 更“现代”，但实际使用中容易忽略三点限制：
- 它无法在宏里手动传递——比如你想封装成
LOG_INFO("msg")，仍得靠宏展开调用log("msg", std::source_location::current())，否则宏展开后位置信息就错位了 - 不支持跨平台统一函数名格式：GCC 返回
void foo(int)，Clang 可能返回foo，MSVC 返回?foo@@YAXH@Z（除非加/Gz或用__FUNCSIG__替代） - 某些嵌入式或裁剪版 STL（如 libc++ for bare metal）可能未实现该类型，编译时报
‘source_location’ is not a member of ‘std’—— 此时需检查__cpp_lib_source_location宏是否定义，或降级回宏方案
真正省事的场景只有一个：你控制所有日志入口，且只用普通函数包装，不做复杂宏抽象。否则，__FILE__ 和 __LINE__ 依然更可控。
