应将 std::source_location 作为默认参数声明在日志函数中，并用宏包装调用，确保位置信息准确捕获调用点；避免显式传参、提前拼接消息或在 constexpr 函数中使用。
std::source_location 在日志宏里怎么用才不丢位置信息？
直接在函数体里调用 std::source_location::current() 会记录该调用点，而不是日志调用点——这恰恰是多数人踩坑的地方。必须把 std::source_location 作为默认参数塞进日志函数，且默认值得写在声明里（不能只在定义里），否则宏展开后无法捕获调用者位置。
- 日志函数声明必须带默认参数：
void log(const char* msg, std::source_location loc = std::source_location::current()) - 调用时不能显式传参，否则覆盖掉自动推导的位置；宏里直接调用函数即可，不要加括号传参
- 如果函数定义在头文件外（比如 .cpp 里），声明必须在头文件中，且默认参数只能出现在声明处，否则编译器看不到
- Clang 和 GCC 12+、MSVC 19.30+ 支持；GCC 11 不支持默认参数推导，会固定记录到函数定义行
为什么用宏包装 std::source_location 更可靠？
函数默认参数依赖调用点展开，但某些场景（如内联限制、模板实例化、链接时优化）可能破坏位置准确性；宏能确保每次展开都原地生成 std::source_location::current()，完全绑定到用户写的那行日志语句。
- 推荐写法：
#define LOG(msg) do { log(msg, std::source_location::current()); } while(0) - 避免用
std::format或字符串拼接提前计算消息内容——宏展开时表达式未求值，std::source_location才真正反映调用位置 - 不要在宏里调用带默认参数的函数再传
std::source_location::current()，多此一举还可能被优化掉 - 宏名大写（如
LOG）可提醒使用者：这是文本替换，不是普通函数调用
std::source_location::file_name() 返回路径太长或含相对路径怎么办？
file_name() 返回的是编译器传递的原始路径字符串，可能是绝对路径，也可能是相对于构建目录的路径，取决于编译命令（如 -frecord-gcc-switches 或 CMake 的 set(CMAKE_CXX_FLAGS "-g")）。它不做任何裁剪或标准化。
- 常见现象：日志里出现
/home/user/project/src/util/log.cpp或../src/util/log.cpp，不利于快速定位 - 安全截取文件名的方法是找最后一个
/或：std::string_view(fname).substr(fname.find_last_of("/\") + 1) - 别用
std::filesystem::path处理——它不是constexpr，不能在常量表达式上下文中用，而std::source_location构造发生在编译期附近 - 如果用 Ninja + CMake，可通过
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fmacro-prefix-map=${CMAKE_SOURCE_DIR}=")缩短路径前缀
std::source_location 会影响性能吗？
几乎不。它的三个字段（file_name、function_name、line、column）都是编译期常量，构造开销为零；运行时只是读几个字面量地址和整数。但要注意间接成本。
立即学习“C++免费学习笔记（深入）”；
- 如果日志函数被频繁调用且开启调试符号（
-g），file_name()返回的字符串常量会增大二进制体积——每个唯一文件名存一份 - 启用 LTO 后，编译器可能把
std::source_location::current()内联并折叠，实际无额外指令 - 真正拖慢日志的是后续的格式化、IO 或锁竞争，不是
std::source_location本身 - Release 模式下关闭日志宏（如
#ifdef DEBUG_LOG）比纠结source_location开销更有效
最易被忽略的一点：std::source_location::current() 在 constexpr 函数里不能用——它不是字面量构造函数，也不满足 immediate function 要求。所以别试图在编译期日志或 static_assert 里塞它。
