std::source_location在c++20中通过默认参数由编译器在调用点自动注入位置信息，而非运行时反射；需避免手动传参或用于模板参数、类成员，推荐仅作函数默认参数并用const char*访问字符串。
std::source_location在C++20中怎么获取调用位置
它不是运行时反射，而是编译期插入的隐式参数。只要函数签名里带std::source_location（默认值为std::source_location::current()），编译器就会自动填入调用点的文件、行号、函数名等信息。
常见错误是手动传参：log("msg", std::source_location::current())——这填的是log函数内部的位置，不是调用者位置。正确做法是让编译器自动注入：
void debug_log(const char* msg, const std::source_location loc = std::source_location::current()) {
printf("[%s:%d %s] %s\n", loc.file_name(), loc.line(), loc.function_name(), msg);
}
注意：std::source_location::current()必须作为默认参数，不能在调用处显式传入，否则失去“调用点”语义。
为什么std::source_location比__FILE__/__LINE__更可靠
__FILE__和__LINE__是宏，在内联函数或模板展开后可能指向实现文件而非用户代码；而std::source_location由编译器在**实际调用点**生成，不受内联、模板实例化影响。
使用场景差异明显：
- 宏方案在头文件里被#include多次，
__FILE__会变成头文件路径，容易误导 -
std::source_location始终指向用户调用该函数的那一行，哪怕函数定义在另一个库中 - 它还能拿到
function_name()，而宏只能靠__func__，且__func__不跨平台（MSVC叫__FUNCTION__）
自定义诊断宏时如何避免ODR违规和模板膨胀
直接把std::source_location塞进模板参数或类成员会导致每个调用点生成独立实例，增加二进制体积。更轻量的做法是只在函数参数中用，默认构造开销极小（本质是几个const char*和整数）。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
典型陷阱：
- 写成
template<auto loc="std::source_location::current()"> void log() { ... }</auto>——这是非法的，std::source_location不可作为非类型模板参数 - 在类里存
std::source_location成员——每个对象都冗余保存一份位置信息，没必要 - 用
std::string保存file_name()结果——触发堆分配，违背“轻量级”初衷；应直接用const char*
推荐模式：仅作函数参数，且所有字符串访问都用const char*接口，不拷贝。
GCC/Clang/MSVC对std::source_location的支持现状
不是所有C++20实现都完整支持。GCC 10+、Clang 11+、MSVC 19.30+ 可用，但早期版本有差异：
- Clang 11–13：
function_name()返回空字符串，需升级到14+ - MSVC 19.29：
file_name()返回绝对路径，19.30起可设/sourceLocation:rel改用相对路径 - GCC 10：不支持
column()，返回0；GCC 12+才补全
如果需要列号或稳定函数名，建议加编译器检查：
#if defined(__clang__) && __clang_major__ <p>真正麻烦的不是语法兼容性，而是不同编译器对“调用点”的判定边界略有差异——比如在lambda内调用，有的认为是lambda体，有的认为是lambda声明处。这种差异很难绕过，得靠测试覆盖关键路径。</p>
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
