raii自动计时唯一可靠，因对象生命周期确保异常安全；用constexpr哈希生成稳定上下文id，thread_local存记录，dump时单线程拓扑排序；std::chrono::now()是瓶颈，高频路径需编译期开关。
用 RAII 实现自动计时：为什么 std::chrono + 析构函数是唯一靠谱路径
手动调 start() / stop() 容易漏、难嵌套、一出异常就失效。C++ 唯一自然的解法是靠对象生命周期——进作用域构造，出作用域析构，时间统计完全由编译器保证不丢。
关键不是“怎么计时”，而是“谁来触发计时结束”。RAII 是唯一能 100% 覆盖异常路径的方式。
-
std::chrono::high_resolution_clock::now()是最常用起点，但注意它在某些 Windows 环境下可能被系统节拍器拖慢（QueryPerformanceCounter更稳） - 构造函数存起始时间，析构函数算差值并写入全局
std::unordered_map<:string std::vector>></:string>或线程局部std::vector - 别用
std::clock()：它测的是 CPU 时间，且在多线程下不可靠；也别用std::chrono::steady_clock做跨线程对比——它不保证跨核单调
如何给每个作用域打唯一上下文标签？__func__ 不够，__FILE__ 和 __LINE__ 也不能直接拼
只靠函数名会撞：模板实例化、重载函数、内联展开后都可能同名。真正可区分的上下文必须包含位置信息，但直接拼 __FILE__ ":" STRINGIFY(__LINE__) 会导致每次编译生成新字符串，无法聚合统计。
- 推荐方案：用
constexpr哈希把__FILE__、__LINE__、__func__编译期合成一个uint64_tID（比如 FNV-1a），运行时用 ID 当 key 查表 - 避免字符串拷贝：不要在析构里做
std::string构造，尤其高频小函数；ID 查表后，格式化输出只在 dump 阶段做 - 宏封装必须带
__COUNTER__或类似机制，否则宏多次展开在同一行会冲突（Clang/GCC 支持__COUNTER__，MSVC 需 fallback 到模板参数推导）
多线程下计时数据怎么不乱？thread_local 不是万能解
thread_local std::vector 能隔离数据，但 dump 时要合并所有线程的数据——如果只是简单 push_back，最终排序和归类会非常痛苦，因为不同线程的调用栈深度、顺序完全不同。
立即学习“C++免费学习笔记（深入）”；
- 每个线程维护自己的
std::vector<timingrecord></timingrecord>，其中TimingRecord包含嵌套深度、父 ID、时间戳、上下文 ID - 禁止在析构中锁全局 map：这会造成严重争用，尤其在 hot path 上；所有写操作严格限定在线程本地
- dump 阶段再用单线程做拓扑排序（按进入时间 + 深度还原调用树），而不是边跑边建树
- 注意：GCC 的
thread_local在动态库中初始化行为不一致，建议用__declspec(thread)（MSVC）或__thread（GCC/Clang）显式声明
性能开销到底多大？实测发现 std::chrono::now() 在 Intel CPU 上约 20–50 ns
这不是理论值，是真实 rdtsc 对标结果。但 50 ns 每次调用，在微秒级函数里就是 5%+ 开销；在纳秒级函数里，直接让测量失真。
- 启用编译器优化（
-O2）后，空作用域的计时对象构造+析构本身约 1–3 ns（不含now()），所以瓶颈永远在时钟调用 - 对高频路径（如 vector push_back 内部循环），必须支持编译期开关：用
if constexpr (kEnableProfiling)把整块逻辑吃掉，而不是 runtimeif - 别信“只在 debug build 开 profiler”——release 下 cache 行为、内联程度全变了，profile 数据没意义；正确做法是构建时通过宏控制是否注入计时代码
最难的不是实现计时，是怎么让上下文 ID 在编译期稳定、线程数据在 dump 时不丢父子关系、以及让开销真正可控——这三个点卡住绝大多数自研 profiler。
