c++20 中应直接用 std::source_location::current() 获取函数名、文件名和行号，它是编译器在调用点注入的 constexpr 对象；注意 gcc 下 function_name() 为空是正常实现行为，且默认参数必须出现在调用点才准确。
怎么在 C++20 里拿到当前函数名、文件名和行号
直接用 std::source_location::current()，它不是宏，是编译器在调用点自动注入的 constexpr 对象。别手写 __FILE__ 或 __LINE__ 宏组合——那既不类型安全，也不能跨平台保留列号或函数名。
常见错误是试图在非内联函数里传参时“缓存” location：比如写成 void log(std::source_location loc = std::source_location::current())，然后在另一个函数里调用它却不传参——这时 loc 记录的是 log 函数入口的位置，不是调用方位置。必须确保默认参数直接出现在调用点。
- 只对
inline函数或模板函数可靠；普通函数的默认参数值由定义处决定，不是调用处 - Clang/GCC/MSVC 都支持，但 GCC 10+、Clang 11+、MSVC 19.29+ 起才稳定；老版本可能返回空字符串或全 0 行号
- 如果函数被内联展开，
source_location::current()仍指向原始调用点，不是内联后生成的汇编位置
为什么 source_location 的 function_name() 在 GCC 下常为空
因为 GCC 默认不生成函数符号名到调试信息的映射供 source_location 使用，它只填了 file_name() 和 line()，function_name() 返回空字符串。这不是 bug，是实现选择。
MSVC 和较新 Clang（14+）通常能返回合理的函数名（如 "main" 或 "foo(int)"），但 GCC 目前没计划补全——它把这事留给 backtrace 或 DWARF 解析工具做。
立即学习“C++免费学习笔记（深入）”；
- 别依赖
function_name()做日志分类或路由；它在 GCC 下不可靠，连if (!loc.function_name()[0])都可能误判 - 若真需要函数名，宁可用宏包装：
#define LOG() do { log_impl(__func__, __FILE__, __LINE__); } while(0) - 注意
__func__是 C99/C++11 标准特性，比source_location::function_name()兼容性好得多
source_location 会影响性能吗
几乎不。它不触发任何运行时开销：所有字段（file_name、line、column、function_name）都是编译期字面量，存在只读段里，构造只是取地址+常量加载。
唯一例外是某些调试构建中启用了 -grecord-gcc-switches 或类似选项，会让编译器多塞几个字符串字面量——但那是调试信息体积问题，不影响执行速度。
- 别为了“省开销”把
source_location改成可选参数再手动传；默认参数本身无成本，手动传反而增加调用约定负担 - 如果函数被频繁调用（比如每帧上万次的渲染回调），可以考虑只在
DEBUG下启用source_location参数，发布版删掉——但这不是因为性能，而是减少二进制体积和避免误导性日志 - 它的 size 是 4 个
size_t（通常 32 字节），传参走寄存器或栈都极轻量；别把它和std::string或异常对象混淆
什么时候不该用 source_location::current()
当你需要的是栈回溯（比如崩溃时打印完整调用链），而不是单点位置信息。它只告诉你“这行代码在哪”，不告诉你“谁调了我”。
也别在模板元编程或 constexpr 上下文外强行用它做编译期分支——虽然它标了 constexpr，但字段内容（尤其是 function_name()）在不同编译器/模式下行为不一致，没法安全用于 if constexpr。
- 日志、断言、测试失败报告这类“记录触发点”的场景很合适
- 想替代
assert的行号？可以，但记得加上__VA_OPT__宏适配 C++17 项目，否则老标准会编译失败 - 若需跨线程传递位置信息，要小心：
source_location是值类型，拷贝安全，但它的字符串指针指向静态存储期内存，不用额外管理生命周期
function_name() 为空不是配置问题，是它本来就不填；还有，默认参数必须落在调用点，不是定义点——这两点踩一次就够记半年。 
