std::source_location是C++20引入的轻量结构体，编译期捕获调用点的文件名、行号、函数名和列号；需通过默认参数std::source_location::current()显式传入，否则无法获取调用者位置。
std::source_location 是什么，它能自动记录哪些信息
std::source_location 是 C++20 引入的轻量结构体，不依赖宏展开或运行时堆栈解析，编译期就能捕获调用点的文件名、行号、函数名和列号。它本身不“自动”记录——必须显式传入，但配合默认参数可做到「调用处零侵入」。
关键字段有：file_name()（完整路径，非仅文件名）、line()、function_name()（可能为编译器生成名，如 "void log(const char*, std::source_location)"）、column()。注意：function_name() 不保证是源码中写的函数名，尤其开启优化后可能被内联或重命名。
- Windows MSVC 下
function_name()通常较完整；GCC/Clang 默认输出 mangled 名，需加-fno-mangle-strings（Clang）或依赖 libiberty 解析 -
file_name()返回 const char*，指向静态存储区，无需拷贝，但路径含完整绝对路径，日志中常需截取最后一级，比如用std::filesystem::path(f).filename().string() - 它不包含线程 ID 或时间戳，这些得额外补充
如何在日志函数中设为默认参数并避免隐式构造陷阱
最常见写法是把 std::source_location 作为函数最后一个参数，并赋予默认值 std::source_location::current()：
void log(const char* msg, std::source_location loc = std::source_location::current()) {
fprintf(stderr, "[%s:%d] %s\n", loc.file_name(), loc.line(), msg);
}但要注意：这个默认值是在「调用点」而非「定义点」求值，符合预期。真正容易踩坑的是隐式类型转换——如果你的日志函数重载了多个版本（比如支持 std::string_view、int、const char*），而某个重载没声明 std::source_location 参数，编译器可能选错重载，导致 loc 没被传入。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 务必确保所有日志入口函数（包括模板特化、可变参封装）都显式接收
std::source_location参数 - 不要依赖 ADL 或模板推导自动补全；
log("hello")能工作，但log(42)若没有对应重载，会编译失败或触发意外转换 - 若用宏封装（例如
#define LOG(msg) log(msg)），宏会展开在调用处，std::source_location::current()仍正确；但宏无法转发可变参数，建议直接用函数+默认参数，更类型安全
与传统 __FILE__/__LINE__ 宏相比，性能和可维护性差异在哪
表面看，__FILE__ 和 __LINE__ 是预处理器替换，std::source_location::current() 是编译器内置机制，二者在最终生成的代码上几乎无差别：都是常量字符串地址 + 整数字面量，无运行时开销。
真正区别在可维护性：
- 宏方案需手动拼接，易出错：
fprintf(stderr, "%s:%d %s", __FILE__, __LINE__, msg)—— 如果msg含%会崩溃；而std::source_location把位置信息和业务消息解耦，格式控制更清晰 - 宏无法参与类型系统：你不能对
__FILE__做std::string_view构造或std::filesystem::path转换，除非再套一层宏；而std::source_location是正规类型，可自由组合 - 某些构建系统（如 Bazel）对宏路径处理不一致，
__FILE__可能返回相对路径或 sandbox 路径；std::source_location::file_name()行为由编译器保证，更稳定
生产环境启用时必须检查的三个兼容性细节
不是所有 C++20 特性都开箱即用。启用 std::source_location 前，请确认：
- 编译器最低版本：GCC ≥ 10，Clang ≥ 11，MSVC ≥ 19.28（VS 2019 v16.8）。低于这些版本会报
error: 'source_location' is not a member of 'std' - C++ 标准必须显式指定：
-std=c++20（GCC/Clang）或/std:c++20（MSVC）；仅用-std=gnu++20也可能失败，某些发行版默认不启用实验性特性 - 如果项目混用 C++17 和 C++20 文件，确保日志头文件只被 C++20 编译单元包含；否则
std::source_location在 C++17 模式下不可见，引发链接错误或宏 fallback 冲突
最隐蔽的问题是：某些 CI 环境的交叉编译工具链未同步更新 libstdc++/libc++ 头文件，即使编译器版本达标，<source_location> 头仍可能缺失——此时需升级标准库或改用条件编译 fallback。
