std::source_location::current() 作为默认参数可自动捕获调用点位置，因其由编译器在调用处注入而非运行时调用；手动传__FILE__/__LINE__或封装/宏转发均会导致位置失真；短文件名宜用strrchr或std::filesystem::path提取，需注意跨平台与性能；Clang 13+、GCC 12+、MSVC 16.8+支持较可靠，但function_name()和column()行为因编译器而异；它不保证日志内容线程安全。
直接用 std::source_location::current() 作为函数默认参数，就能让日志自动带出真实调用点的文件、行号和函数名；手动传 __FILE__ 和 __LINE__ 是过时做法，容易错位、难维护。
为什么 log("msg") 能打出 main.cpp:42 而不是 logging.cpp:15？
因为 std::source_location::current() 不是运行时函数调用，而是编译器在每个调用点“现场注入”的常量结构体。它只在声明为默认参数时生效，且必须写成 = std::source_location::current() 形式。
- 不能提前保存：比如
static auto loc = std::source_location::current()，这会固定在定义处（如全局或构造函数里）的位置 - 不能二次封装：写个中间函数再调用
log_impl(msg, loc)，loc就变成中间函数的位置了 - 不能用宏转发：比如
#define LOG(m) log(m)，宏展开后调用点就塌缩到宏定义行 - 必须保持一层直接调用：日志函数签名里直接带默认参数，调用方不传参
如何安全提取短文件名（避免 /home/ci/project/src/util.h 刷屏）？
std::source_location::file_name() 返回的是 const char*，通常是绝对路径，硬切字符串风险高——不同构建环境路径分隔符和深度都不一致。
- Linux/macOS 下最轻量：用
strrchr(full, '/')找最后一个/，返回其后部分 - Windows 兼容需加
#ifdef _WIN32分支处理'\' - 若已用 C++17，可用
std::filesystem::path(full).filename().c_str()，但注意它可能触发堆分配（尤其在频繁日志场景） - 别在日志函数里反复调用
std::filesystem—— 开销不可忽略，建议封装成 inline 工具函数并缓存结果（如果路径不变）
哪些编译器版本真正可靠支持？
不是所有标称“支持 C++20”的编译器都能正确填充 function_name() 或非零 column()，更别说 CI 环境下静默降级的问题。
立即学习“C++免费学习笔记（深入）”；
- Clang 13+：
function_name()返回可读名（未修饰），column()仍常为 0 - GCC 12+：稳定返回完整路径和有效行号，
function_name()是修饰名（需c++filt解析） - MSVC 16.8+（VS2019）：支持完整字段，但默认输出修饰名；加
/Zc:__cplusplus可改善 - 旧版本（如 GCC 10、Clang 11）可能编译通过但返回空字符串或 0 行号——务必在目标环境中实测
log("test")输出
最易被忽略的一点：它不解决日志内容本身的线程安全，只保证位置信息准确；如果你把 loc.file_name() 存进一个非线程安全的缓冲区再异步写入，位置对了，内容可能乱序或覆盖。
