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 把这些字段打包进一个轻量结构体，支持默认参数：
立即学习“C++免费学习笔记（深入）”；
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 2022 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 并长期持有（除非你明确拷贝）。
