std::source_location 不是严格编译期常量，但它是编译期确定、运行时零开销的 constexpr 对象；相比 FILE 和 __LINE__，它类型安全、可传递、支持列号和函数名，并能用于模板参数等 constexpr 上下文。

std::source_location 是编译期常量吗？

不是严格意义上的编译期常量，但它是**编译期确定、运行时零开销的值对象**。相比 __FILE__ 和 __LINE__ 这类预处理器宏，std::source_location 的关键优势在于：它把源码位置封装成一个类型安全、可传递、可扩展的 constexpr 构造对象，而不仅仅是字符串字面量和整数字面量的拼凑。

编译器在遇到 std::source_location::current() 时，会在调用点直接内联填入当前文件名、行号、列号和函数名（如果支持），不产生函数调用或运行时字符串拷贝。这使得它能参与 constexpr 上下文（比如作为模板参数、数组大小、static_assert 条件），而 __FILE__ 虽是字面量，但类型是 const char*，无法直接用于需要字面量常量的场景。

为什么不能直接用 __FILE__/__LINE__ 替代 source_location？

根本问题在于类型缺失与组合成本高：

• __FILE__ 是 const char*，指向静态存储区，但无法在编译期做长度计算或内容比较（C++20 前）
• __LINE__ 是整型字面量，但每次使用都需手动拼接，容易遗漏或错位
• 无法自然携带 column 或 function_name —— 后者在 C++20 前甚至没有标准方式获取
• 函数签名中若想接收位置信息，只能写多个参数：log(const char* file, int line, const char* func)，调用时必须显式传 __FILE__, __LINE__, __func__，极易出错且不可默认

而 std::source_location 把这些字段打包进一个轻量结构体，支持默认参数：

void log(std::string_view msg, std::source_location loc = std::source_location::current()) {
    std::cerr << loc.file_name() << ":" << loc.line() << " in " << loc.function_name() << " — " << msg << "\n";
}

source_location 在模板/constexpr 场景下的实际能力

这是它真正拉开差距的地方。例如：

• 可用作非类型模板参数（NTTP）—— C++20 起支持 std::source_location 作为模板参数类型（需满足字面量类型要求，GCC 12+ / Clang 14+ 已支持）
• 可在 static_assert 中直接使用 loc.line()，因为它是 constexpr 成员函数返回的字面量整数
• 能构造 constexpr 字符串视图：constexpr auto file = std::source_location::current().file_name();（注意：返回的是 const char*，但指向的是编译期已知的只读内存）

对比之下，__FILE__ 虽也是字面量，但你无法写 static_assert(__LINE__ > 100); —— 因为 __LINE__ 不是 constexpr 表达式（它只是预处理器替换，不参与语义分析）；而 std::source_location::current().line() 是合法的 constexpr 表达式。

容易被忽略的兼容性与陷阱

不是所有编译器版本都“开箱即用”：

• MSVC 从 19.30（VS 2025 17.0）开始完整支持 std::source_location 及其 constexpr 行为
• GCC 需要 -std=c++20 且 ≥11.1；但 function_name() 在 GCC 12 前返回空字符串
• Clang ≥13 支持良好，但早期版本对 column() 返回 0
• 调用 std::source_location::current() 的位置，必须在函数作用域内 —— 不能在命名空间或类定义中直接调用，否则行为未定义

最易踩的坑是误以为 file_name() 返回的是 std::string：它返回的是 const char*，且该指针生命周期绑定于编译单元，不能存为 std::string 并长期持有（除非你明确拷贝）。