std::source_location::current() 返回日志函数内部位置是因为在函数体内调用时捕获的是该函数自身的编译位置，而非调用点；正确做法是将其作为带默认值的函数参数，由编译器在调用处自动填充调用点信息。
不用手写 __FILE__ 和 __LINE__，std::source_location 能自动带出调用点信息，但必须在函数参数里显式声明、且不能被内联优化掉——否则拿到的全是日志封装函数自己的位置。
为什么 std::source_location::current() 总是返回日志函数内部的位置？
这是最常踩的坑：直接在日志函数体内调用 std::source_location::current()，它捕获的是该函数被编译时的源码位置，不是调用它的那行代码。
正确做法是把 std::source_location 当作函数参数，默认值设为 std::source_location::current()：
void log_info(const char* msg, std::source_location loc = std::source_location::current()) {
printf("[%s:%d] %s\n", loc.file_name(), loc.line(), msg);
}这样每次调用 log_info("hello") 时，编译器会在调用点自动生成当前的文件、行号、函数名等信息，并传进来。
立即学习“C++免费学习笔记（深入）”；
- 必须是默认参数，不能靠手动传——否则就失去“自动化”意义
- 不能加
inline或__attribute__((always_inline))，否则可能被内联后丢失原始调用位置 - C++20 起支持，MSVC 19.30+、GCC 10+、Clang 11+ 可用；老编译器会编译失败，需加
#if __cpp_lib_source_location守卫
std::source_location 能取到哪些字段？各字段的可靠性如何？
常用字段有四个：file_name()、line()、column()、function_name()。但它们的填充行为不一致：
-
file_name()和line()总是准确，对应调用点的物理位置 -
function_name()是编译器生成的符号名（如"void foo()"），GCC/Clang 通常完整，MSVC 可能截断或不带参数签名 -
column()大部分编译器返回 1（或未实现），别依赖它做精确定位 - 所有字段返回
const char*，生命周期绑定到source_location对象本身，无需额外拷贝
和宏方案比，std::source_location 的实际开销有多大？
它不产生运行时调用，所有信息在编译期填入，本质是一组常量整数和字符串字面量地址。反汇编可见：就是几个 mov 指令加载地址和立即数。
相比传统宏（如 #define LOG(x) printf("%s:%d " x, __FILE__, __LINE__)）：
- 类型安全：宏容易误展开、和逗号表达式冲突；
source_location是正规类型，可重载、可封装进类 - 调试友好：IDE 能跳转到真实调用点，而不是宏定义处
- 唯一代价：每个调用点多传 3–4 个字（典型是 24 字节结构体），但现代 ABI 通常用寄存器传，无栈开销
如果函数已带多个参数，再加一个 source_location 几乎零成本；若原本是无参函数，要小心 ABI 对齐变化（不过实践中极少影响）。
跨编译单元或模板实例化时，位置信息还准吗？
准，而且更可靠。宏在头文件里展开时，__FILE__ 是头文件路径，容易误导；而 std::source_location::current() 始终反映「实际调用该函数的那行代码」的位置。
例如模板函数中使用：
template<typename T>
void report(T value, std::source_location loc = std::source_location::current()) {
std::cout << loc.file_name() << ":" << loc.line() << " → " << value << "\n";
}无论 report(42) 写在 main.cpp 还是 utils.h 里，打印的都是 main.cpp 那一行。
- 注意：如果模板定义在 .cpp 里且未导出，而调用在另一个 TU，链接时可能报错——这不是
source_location的问题，是模板可见性问题 - 静态库场景下，只要调用点能看见模板定义（比如头文件实现），位置就一定准
真正容易被忽略的是：某些构建系统（如 Ninja + GCC 的 -frecord-gcc-switches）或 LTO 模式下，file_name() 可能返回绝对路径而非相对路径，影响日志可读性——需要统一用 std::filesystem::path 截取文件名再输出。
