std::source_location无法获取完整函数签名，仅提供裸函数名、文件路径、行号和列号；完整签名需借助__pretty_function__或__funcsig__等编译器扩展实现。
std::source_location 能否获取函数签名
std::source_location 本身不提供函数名或类型信息，它只记录编译时的文件路径、行号、列号和函数名（function_name() 返回的是编译器生成的裸名字符串，如 "foo" 或 "test_func"），**不包含命名空间、参数列表、返回类型或模板特化信息**。所谓“完整命名空间的签名”，必须靠其他机制补全。
如何拼出带命名空间的函数名
手动拼接是常见做法：把当前作用域的命名空间前缀 + source_location::function_name() 字符串连起来。但 C++ 没有运行时反射，无法自动推导当前命名空间，只能靠开发者显式传入或宏辅助。
- 最稳妥方式是在日志宏中用
__PRETTY_FUNCTION__（GCC/Clang）或__FUNCSIG__（MSVC），它们天然包含命名空间、参数、const 限定等，例如：#define LOG_LOC() do { \ auto loc = std::source_location::current(); \ std::cerr - 若坚持用
std::source_location，可配合宏展开当前作用域——比如在命名空间ns::detail内写LOG_HERE("ns::detail::")，再拼接loc.function_name()；但容易漏写、难维护 -
__FUNCTION__和__func__只返回不带命名空间的函数名，不可靠
__PRETTY_FUNCTION__ 的兼容性与陷阱
它不是标准特性，但 GCC、Clang、MSVC 都支持，只是格式不同：GCC/Clang 输出类似 "void ns::detail::process<int>(const std::vector<int>&)"</int></int>，MSVC 输出 "void __cdecl ns::detail::process<int>(const class std::vector<int std::allocator> > &)"</int></int>。实际使用需注意：
- 内容含空格、括号、尖括号，直接用于日志没问题，但不适合解析或结构化处理
- 模板实例化名可能极长，影响日志可读性或性能（尤其高频调用）
- 开启 LTO 或某些优化后，部分编译器可能简化名字（如去掉模板参数），行为不保证稳定
- 不能在 constexpr 上下文中使用（非字面量）
真正需要签名时该怎么做
如果目标是统一打印“可识别、可跳转、带上下文”的调用点，别只依赖 std::source_location。更实用的组合是：
- 用
std::source_location提供精准文件/行号定位（编辑器能跳转） - 用
__PRETTY_FUNCTION__补充语义上下文（命名空间+签名） - 对关键函数，手动定义静态字符串常量（如
static constexpr char sig[] = "ns::service::handle_request(int, bool)";），避免宏膨胀和编译器差异 - 避免在 hot path 上拼接字符串——先判断日志等级再构造，否则
__PRETTY_FUNCTION__的字符串构造开销不可忽略
没人能单靠 std::source_location 拿到“完整签名”，它的设计初衷就是轻量定位，不是替代函数名反射。想省事就用宏包一层 __PRETTY_FUNCTION__，想可控就分层组合，别指望一个标准类解决所有元信息需求。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
