std::source_location是C++20引入的类型，用于在编译期自动捕获调用点的文件名、行号、函数名和列号，避免手动传入__FILE__、__LINE__等宏；它类型安全、可作默认参数，但必须在最外层函数中直接调用current()才能准确定位。
std::source_location 是什么，它能省掉哪些手动传参
它不是宏，但效果类似——std::source_location::current() 在编译期自动捕获调用点的文件名、行号、函数名和列号，避免你在每个日志调用处手写 __FILE__、__LINE__、__FUNCTION__。关键在于：它不依赖宏展开，类型安全，可作为函数参数默认值直接注入。
常见错误是试图在非内联函数里“提前获取”位置信息——比如在包装函数里调用 std::source_location::current()，结果记录的是包装函数的位置，而非真实调用点。必须让 std::source_location 的获取发生在最外层日志入口函数（或 inline 函数）中。
- 正确做法：把
std::source_location loc = std::source_location::current()作为函数最后一个默认参数 - 错误做法：在中间层函数里先存一个
loc，再传给真正写日志的函数 - 注意：C++20 起支持，GCC 10+、Clang 11+、MSVC 19.29+ 可用；老编译器需退回到宏方案
如何设计日志函数签名，兼顾简洁与信息完整
典型日志接口如 log_info(const char* fmt, ...) 不再合适——std::source_location 需显式出现在参数列表，且应放在末尾以便默认构造。推荐使用可变参数模板 + std::format（C++20）或 fmt::format（更成熟）来统一格式化逻辑。
示例签名：
template<typename... Args><br>void log_info(std::string_view msg, const Args&&... args,<br> std::source_location loc = std::source_location::current());
立即学习“C++免费学习笔记（深入）”；
- 不要把
loc放在参数开头或中间，否则调用时必须显式传入，失去“自动”意义 - 如果已有旧版宏日志（如
LOG_INFO("x=%d", x)），不能直接替换为模板函数——宏会展开成带位置信息的调用，而模板函数不会自动触发宏展开；需同步迁移调用点或保留宏 wrapper -
std::source_location构造开销极小（本质是几个 const char* 和整数），但频繁拷贝仍不必要；建议按值传递（它本身是 trivially copyable）
std::source_location 与宏共存时的兼容陷阱
很多项目同时存在宏日志和新式 C++ 日志函数。若你用宏包裹 std::source_location 函数（如 #define LOG_INFO(...) log_info(__VA_ARGS__)），宏展开后 std::source_location::current() 会定位到宏定义处，而非调用处——这是最常踩的坑。
解决办法只有一种：宏必须展开成带 std::source_location::current() 的完整调用。例如：
#define LOG_INFO(...) ::log_info(__VA_ARGS__, std::source_location::current())
- 宏里不能只调用函数名，必须把
std::source_location::current()显式写进去 - 如果项目用
__FILE__等传统宏生成字符串，注意std::source_location::file_name()返回的是const char*，可能指向只读段，不可修改；而__FILE__也是 const，行为一致 - 混合使用时，确保宏和函数最终输出的字段名一致（如都叫
file、line），否则日志解析器会混乱
性能和可移植性边界在哪
std::source_location 本身无运行时开销，但它的字段（尤其是 file_name()）在某些编译器下可能指向调试信息中的路径，而非预处理后的绝对/相对路径。GCC 默认输出绝对路径，Clang 可能受 -frecord-gcc-switches 或构建系统影响。
这意味着：日志里看到的文件路径可能很长（如 /home/user/project/src/log.cpp），也可能被裁剪（如仅 src/log.cpp），取决于编译器和构建配置。无法保证跨平台一致。
- 不要在日志中直接用
loc.file_name()做文件名匹配或路由判断——路径格式不稳定 - 若需精简显示，建议在日志格式化阶段做一次
std::string_view截取（如找最后一个/后的内容），而不是依赖std::source_location自带逻辑 - Windows 上 MSVC 的
function_name()返回的是修饰名（mangled），需用__FUNCSIG__宏替代；而std::source_location::function_name()在 MSVC 2019+ 才返回可读名，旧版仍为空字符串
实际用起来，最难的不是写对语法，而是让所有团队成员理解：这个东西只有“在第一层调用点上直接用”才有效。一旦封装进工具函数、间接调用、或混用宏又不重写，位置信息就失效了。
