tracy避坑：原理讲透再上手
tracy避坑的关键，是别把它当成一键加速器。它只是把程序运行过程摊开给你看，问题还得靠你判断。很多人踩坑，不是工具难，而是没分清采样、埋点、帧边界、构建模式这些底层逻辑。
埋点和采样：别混着看
tracy避坑第一条：采样看到的是“概率上的热点”，埋点看到的是“你标出来的时间段”。Tracy能做混合式分析，但它最有味道的地方，还是手动标记源码后按帧、按线程查看执行过程。官方介绍也强调，它主要关注源码手动标记带来的逐帧检查能力。([wolf.nereid.pl](https://wolf.nereid.pl/projects/tracy-profiler/))
这背后的逻辑很简单：采样适合大海捞鱼，埋点适合拿手电筒照角落。你不知道哪慢，就先采样；你怀疑某几个环节偶发抖动，就上Tracy。最怕的是只埋了两个函数，就下结论说“Tracy没看出问题”，那不是工具失灵，是证据链太短。
实时和离线：用途不一样
实时连接看起来爽，程序一跑，时间线马上刷出来，适合调试阶段边改边看。但实时采集容易让人贪多，一口气跑十几分钟，最后得到一个巨大文件，自己也翻不动。离线捕获更适合复现难、机器不在身边、需要发给同事看的场景。
对比下来，实时模式像在厨房边炒边尝，离线文件像把菜端到桌上慢慢拆。团队协作时，最好约定采集口径：复现场景、运行时长、机器配置、版本号、是否Release构建。这些不写清楚，两个trace文件摆一起也不好比。
粗埋和细埋：别一开始就撒网
很多人用Tracy最容易犯的错，是把每个小函数都加上Zone。看似细，实际噪声巨大。刚开始应该按业务阶段粗埋：Update、Physics、Animation、RenderSubmit、ResourceLoad、ScriptTick。先找到异常大块，再往里面拆。
细埋点适合第二轮，不适合第一轮。比如ResourceLoad稳定占20ms，你再把文件读取、解压、反序列化、GPU上传拆开；如果第一轮就把几百个函数全标了，时间线会像毛线团，老板看不懂，你自己也头大。
Debug和Release：数字不能乱比
tracy避坑里最冤的一类，是拿Debug结果开优化会。Debug构建不开优化，迭代器检查、断言、符号信息都可能改变耗时。它适合看流程，不适合定最终性能结论。要比较优化前后，至少用同一构建类型、同一场景、同一输入数据。
Release也不是万能。过度优化会让函数内联、符号折叠，部分调用关系看起来没那么直观。实战里我常用两套：RelWithDebInfo看真实耗时，Debug看逻辑路径。别指望一份trace同时回答所有问题。
全能和专精：别拿错尺子
Tracy支持CPU、GPU、内存分配、锁等多类分析，官方仓库也列出它覆盖多种语言和图形/计算API的能力。([github.com](https://github.com/wolfpld/tracy)) 但“能看”不等于“每一项都是最强”。看GPU着色器细节，Nsight、Radeon GPU Profiler、RenderDoc可能更合适；看CPU缓存、分支预测，VTune更深。
所以避坑结论很直白：Tracy适合回答“这一帧为什么慢”“线程之间怎么等”“我标出的流程耗时怎么变”；不适合替你做架构判断，也不适合当唯一性能工具。工具箱里留三把尺子，比迷信一把尺子靠谱。
常见问题
tracy避坑最先注意什么？
先少量埋点、固定复现场景、用同一构建模式对比。没有这三条，看到的数字很容易互相打架。
tracy能不能替代VTune？
不能完全替代。Tracy更适合时间线和帧级问题；VTune更适合CPU底层性能、缓存、指令和线程效率分析。
tracy采集文件太大怎么办？
缩短采集时间，减少低价值Zone，只抓复现窗口。能30秒说明问题，就别录5分钟。