std::source_location 不提供函数签名，仅记录文件名、行号、列号和编译器生成的简略函数名（如 "main" 或 "_Z3barv"），无法直接获取带参数类型的可读签名；但可配合日志辅助定位调用点。
std::source_location 是什么，它能给你函数签名吗
std::source_location 本身不提供函数签名（比如 void foo(int, std::string)），它只记录编译时的文件名、行号、列号和函数名（function_name() 返回的是编译器生成的简略名，通常是 mangled 名或简单标识符，不是可读签名）。你真正能拿到的只有类似 "main" 或 "_Z3barv" 这种，取决于编译器和是否启用调试信息。
所以别指望靠 std::source_location::function_name() 直接打印出带参数类型的签名——它做不到。但你可以用它配合其他手段，在调试时快速定位「谁在哪儿调用了什么」。
如何用 std::source_location 输出可读的调用点信息
最实用的方式是把它作为日志辅助参数，默认捕获当前上下文，再拼上你自己知道的函数语义信息：
void log_call(const std::string& sig, const std::source_location& loc = std::source_location::current()) {
std::cerr << "[" << loc.file_name() << ":" << loc.line()
<< "] " << sig << " called\n";
}
// 使用时显式传入“人工写的签名”
log_call("MyClass::process(std::vector<int>&)");
-
std::source_location::current()必须是函数最后一个默认参数，且不能被重载覆盖 - 不要试图在 lambda 或模板推导中直接用
std::source_location::current()当默认值——某些编译器（如旧版 GCC）可能不支持或行为异常 - Clang 14+ 和 GCC 12+ 支持，MSVC 2019 16.10+ 支持；低于这些版本会编译失败
为什么 function_name() 在不同编译器下输出差异大
std::source_location::function_name() 的返回值不是标准化的字符串格式，而是编译器实现定义的：
立即学习“C++免费学习笔记（深入）”；
- GCC/Clang 默认返回 mangled 名（如
"_ZNK5MyClass7computeEv"），除非加-fno-mangle-strings（GCC 13+ 实验性支持） - MSVC 返回较接近源码的名称（如
"MyClass::compute"），但依然不含参数列表 - 即使开启
-g，function_name()也不解析 DWARF 符号表——它纯属编译期字面量插入
想还原真实签名，得靠外部工具（如 c++filt）或运行时反射（目前 C++ 标准不支持），std::source_location 不负责这事。
调试时真正有用的组合技巧
把 std::source_location 和断点、条件日志、IDE 调试器联动，比单靠它“打印签名”更有效：
- 在关键路径函数入口加
assert(loc.line() > 0);，触发时 IDE 自动跳转到调用处（而非定义处） - 配合
__builtin_LINE()/__FILE__做兼容 fallback（对不支持std::source_location的旧环境） - 在 GDB 中设置条件断点：
break myfunc if $_caller_is("test_runner")，比依赖function_name()更可靠
记住：它是个轻量级“快照”，不是符号解析器。用错地方，反而让你以为拿到了签名，结果发现只是个空字符串或乱码。
