std::source_location在C++20中自动捕获编译期确定的文件名、函数名（完整签名）、行号和列号，零运行时开销，但function_name()返回实现定义字符串，且必须用current()获取，禁止手动构造。
std::source_location 在 C++20 中能自动捕获哪些信息
它不是魔法，只是编译器在调用点插入当前文件、函数名、行号、列号的字面量结构体。关键在于：这些值在编译期确定，运行时零开销，但std::source_location::function_name()返回的是实现定义的字符串（常见为完整符号名，如"void foo(int)"），不是你写的裸函数名。
- 必须用
std::source_location::current()获取，不能手动构造（C++20 标准禁止） - GCC/Clang 默认支持；MSVC 从 19.30+ 支持，但需开启
/std:c++20 - 不捕获调用栈，只抓最上层调用点——想埋点“谁调用了这个函数”，得靠它；想查“这个函数被谁调用”，得另加调试符号或 profiler
如何封装成一行日志宏，避免重复写参数
直接在函数里手写std::source_location::current()太啰嗦，且容易漏。用宏包裹是最轻量的方案，但要注意宏展开时机和参数传递陷阱。
- 宏必须用
__VA_OPT__（C++20）或逗号操作符兼容旧标准，否则变参日志会多一个空参数 - 不要把
std::source_location作为函数参数传入——它会被复制，但function_name()可能指向临时字符串缓冲区，生命周期不可控 - 推荐写法：
#define LOG_INFO(...) ::log_impl(__FILE__, __LINE__, __func__, ##__VA_ARGS__)
，内部再转成std::source_location（更可控）或直接用预处理器宏（更兼容） - 如果坚持用
std::source_location::current()，宏里必须写成LOG_AUTO("msg")形式，不能带括号参数，否则current()捕获的是宏展开位置，不是调用位置
std::source_location 和 __FILE__/__LINE__ 的实际差异在哪
表面看都是打桩，但行为边界很不同：前者是类型安全的结构体，后者是裸字符串和整数。这直接影响日志格式统一性和可维护性。
-
__FILE__是绝对路径（取决于编译命令），std::source_location::file_name()是相对路径（Clang/GCC 默认），容易导致日志中路径长度爆炸或难以匹配 -
__func__是纯函数名（如"foo"），std::source_location::function_name()是签名（如"int bar(double) noexcept"），解析成本高，grep 不友好 - 跨编译单元时，
__LINE__稳定，但std::source_location在内联函数中可能指向头文件行号而非调用点——这是最容易踩的坑：你以为打在业务代码，其实打在utils.h第 42 行
为什么全自动埋点在 release 模式下可能失效
不是 bug，是设计取舍。std::source_location::current() 依赖编译器注入信息，而某些优化级别会改变内联决策或消除调用帧，间接影响捕获精度。
立即学习“C++免费学习笔记（深入）”；
- Clang -O2 下，若函数被完全内联，
current()可能回退到调用者位置，甚至报错（罕见） - GCC 12+ 在 -O3 下对
function_name()返回空字符串（已知 issue），需降级到 -O2 或补 fallback - 真正稳定的方案：只对非内联函数（加
[[gnu::noinline]]）或关键路径函数启用std::source_location，其余用__FILE__/__LINE__兜底 - 别指望它替代 symbolication——它不提供地址、不支持堆栈展开，纯属源码级标记
全自动埋点的核心矛盾始终是：编译期信息 vs 运行时意图。std::source_location 给了你一把精准但单向的刻刀，刻哪儿由调用点决定，而不是你写的那个函数体。用之前，先确认你的日志系统是否真需要函数签名，还是只需要“哪个文件哪一行触发了逻辑”。
