std::source_location是C++20引入的轻量结构体，提供line()、column()、file_name()和function_name()四个编译期捕获的源码位置信息，需通过默认参数传递以准确获取调用点而非定义点位置。
std::source_location 是什么，它能拿到哪些信息
std::source_location 是 C++20 引入的轻量结构体，用于在编译期捕获调用点的源码位置。它不依赖运行时栈遍历，也不触发异常或额外开销，本质是编译器内建支持的“静态快照”。你能拿到的是四个 int 类型字段：line()、column()、file_name() 和 function_name() —— 注意，function_name() 返回的是声明点的函数名（不是调用点），且内容由编译器决定（GCC 通常返回 mangled 名，Clang/MSVC 更倾向 demangled，但不保证）。
如何正确传参：必须用默认参数 + 静态推导
直接调用 std::source_location::current() 拿到的是该语句所在位置，不是调用者位置。要获取调用点信息，必须把它设为函数的**默认参数**，让编译器在每个调用处自动填入当前上下文：
void log(const char* msg, std::source_location loc = std::source_location::current()) {
printf("[%s:%d] %s\n", loc.file_name(), loc.line(), msg);
}关键点：
- 不能写成
std::source_location loc = std::source_location::current()在函数体内 —— 这样永远返回log函数内部的位置 - 不能通过指针/引用传递（如
const std::source_location&）再转发 —— 默认参数机制只在首次调用点展开，转发会丢失原始调用信息 - 模板函数中也能用，但需确保默认参数出现在模板声明里，而非特化或实例化后补
常见误用和兼容性陷阱
几个容易踩的坑：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
-
std::source_location::current()在 constexpr 上下文中不可用（比如static_assert内部），会报错 “not a constant expression” - 某些旧版标准库（如 libstdc++ 11 之前）未实现该类型，链接时可能提示 undefined reference to
std::source_location::current()—— 确保 GCC ≥ 10 / Clang ≥ 11 / MSVC ≥ 19.29，并开启-std=c++20 - Windows 下
file_name()返回的是绝对路径（含盘符），Linux/macOS 通常是相对路径，若用于日志归一化需自行截取 basename - 宏封装时要小心：如果写成
#define LOG(x) log(x, std::source_location::current())，那拿到的就是宏展开位置，不是调用宏的位置；正确做法是定义带默认参数的内联函数再被宏调用
替代方案对比：宏 vs __builtin_FILE__ 等
有人会想用 __FILE__、__LINE__ 宏拼接，但它们是预处理阶段字符串字面量，无法统一成结构体，也不能跨平台控制列号或函数名。而 std::source_location 的优势在于类型安全、可拷贝、可作为参数透传，且未来标准可能扩展字段（如 column() 已存在但部分编译器未填充）。不过要注意：它仍无法替代调试器或 backtrace，拿不到调用栈，只有一层调用点。
真正复杂的场景（比如需要多层回溯、动态过滤文件名、或兼容 C++17 项目），还是得靠宏 + 编译器内置函数（如 __builtin_FUNCTION()）或第三方库（如 Boost.Stacktrace），std::source_location 只解决“这一行是谁调的”这个最小闭环问题。
