核心思路是利用raii在作用域进出时自动记录并计算高精度时间差，必须用std::chrono::high_resolution_clock保证纳秒级精度，通过__line__生成唯一变量名避免冲突，输出延迟至析构末尾以减小干扰。
用 std::chrono + RAII 实现自动计时
核心思路是：在作用域进入时记录起始时间，离开时自动计算差值并输出。不依赖全局变量或手动调用，靠对象生命周期保证准确性。
常见错误是直接用 clock() 或 std::time(0)——精度太低（秒级），且无法体现函数内局部耗时；还有人用宏展开后漏掉大括号，导致作用域错位。
- 必须用
std::chrono::high_resolution_clock，它是 C++11 起最可靠的高精度时钟 - 计时对象需定义在作用域开头，且不能被
if/for等语句隐式限制作用域（否则析构提前） - 宏里用
__func__和__LINE__比硬编码字符串更安全，避免同名函数混淆
#define TIME_SCOPE() \
auto _timer_start = std::chrono::high_resolution_clock::now(); \
struct TimerGuard { \
std::chrono::time_point<std::chrono::high_resolution_clock> start; \
const char* func; int line; \
TimerGuard(const char* f, int l) : start(std::chrono::high_resolution_clock::now()), func(f), line(l) {} \
~TimerGuard() { \
auto end = std::chrono::high_resolution_clock::now(); \
auto us = std::chrono::duration_cast<std::chrono::microseconds>(end - start).count(); \
fprintf(stderr, "[TIME] %s:%d → %ld μs\n", func, line, us); \
} \
} _timer_guard(__func__, __LINE__);
为什么不用 std::chrono::steady_clock？
steady_clock 确实更“稳”（不受系统时间调整影响），但它的分辨率在某些平台（尤其是 Windows + MinGW）可能只有 15ms，而 high_resolution_clock 在大多数现代系统上能到纳秒级——对性能分析更重要的是精度，不是“是否可逆”。
实际测试中，steady_clock 在 Linux 上通常和 high_resolution_clock 是同一个类型；但在 Windows MSVC 下，high_resolution_clock 映射到 QueryPerformanceCounter，steady_clock 可能退化为 system_clock 的封装。
立即学习“C++免费学习笔记（深入）”；
- 用
std::chrono::high_resolution_clock::is_steady可以运行时确认是否稳定（多数情况为true） - 如果真需要绝对单调+高精度，应改用平台 API（如
clock_gettime(CLOCK_MONOTONIC, ...)），但跨平台成本高 - 宏里别写
static_assert强制检查——会破坏头文件包含顺序，引发 ODR 问题
宏展开后变量名冲突怎么办？
原始宏若直接定义 _timer_start 和 _timer_guard，嵌套作用域或多次使用会重定义报错。C++ 没有内置的 unique macro token，得靠预处理器技巧。
典型错误是用 __COUNTER__——它虽能生成递增数，但 GCC/Clang 行为一致，MSVC 不支持；更稳妥的是组合 __LINE__ 和 __COUNTER__（如有），或直接用 __LINE__ 加前缀。
- 把变量名改成
_timer_start_##__LINE__和_timer_guard_##__LINE__，利用行号隔离 - 注意：
##连接符要求前后都是宏参数，所以需再包一层（例如用TIME_SCOPE_IMPL(__LINE__)） - 不要用
__FILE__做后缀——路径含斜杠或空格会导致编译失败
#define TIME_SCOPE_IMPL(line) \
auto _timer_start_##line = std::chrono::high_resolution_clock::now(); \
struct TimerGuard_##line { \
/* ... */ \
} _timer_guard_##line(__func__, line);
#define TIME_SCOPE() TIME_SCOPE_IMPL(__LINE__)
输出打点影响真实耗时，怎么减小干扰？
fprintf 到 stderr 看似轻量，但实际会触发锁、格式化、IO 缓冲等开销，尤其在高频小函数里，测出来的时间可能比真实逻辑慢 2–10 倍。
这不是“要不要打日志”的问题，而是“什么时候打、打多少”的权衡。关键在于：计时本身要快，输出可延迟或聚合。
- 计时阶段只存
start/end时间点，不做任何 IO；析构里只做微秒换算，fprintf放最后（已是最小化） - 如果发现
fprintf占比过高，可改用write(2, ...)绕过 libc 缓冲，但需自己实现数字转字符串（推荐用std::to_chars） - 生产环境建议关闭该宏（用
#ifdef DEBUG_TIMING包裹），或把输出重定向到内存 buffer 批量刷出
真正难的不是写对一次，而是确保每次插入都保持作用域干净、无副作用、不拖慢目标代码——越想精确，越得小心宏的呼吸感。
