perf 默认行为易掩盖真实瓶颈，采样前须确认：二进制含debug_info、perf_event_paranoid≤1、进程允许ptrace；cpu密集型应选cycles/instructions事件并计算ipc。
perf 不是“能用就行”的工具，它默认行为往往掩盖真实瓶颈。直接跑 perf record -g ./app 很可能采不到关键函数、看不到符号、误判热点——尤其在生产环境或优化后期。
采样前必须确认的三件事
没做这三步就开 perf record，90% 的报告会误导你：
- 目标二进制是否含调试符号？
file ./myapp看输出里有没有with debug_info；没有就补装debuginfo包（如 CentOS 用debuginfo-install glibc-2.28-XX） - 内核是否启用
perf_event_paranoid？运行cat /proc/sys/kernel/perf_event_paranoid，值 >1 会禁用用户态采样；临时放开：echo 0 | sudo tee /proc/sys/kernel/perf_event_paranoid - 进程是否被
ptrace限制？容器环境（尤其是 rootless Podman 或某些 Kubernetes 安全策略）常默认禁用ptrace，报错Operation not permitted就是这个原因；需加--cap-add=SYS_PTRACE或改安全上下文
perf record 的参数组合不能拍脑袋
高频采样（如 -F 999）在高负载进程上会导致严重干扰；低频（-F 10）又可能漏掉短时爆发热点。关键是按问题类型选事件 + 频率：
- CPU 密集型瓶颈：用
perf record -g -F 99 -e cycles,instructions ./app，之后算 IPC = instructions / cycles，IPC - 内存延迟嫌疑：改用
perf mem record -g -a -- sleep 10，它自动启用mem-loads和地址采样，比手动配-e mem-loads,mem-stores更可靠 - 锁竞争定位：必须显式启用 tracepoint：
perf record -e lock:lock_acquire,lock:lock_release -g -p <pid></pid>，否则perf report里根本看不到锁事件 - 避免默认
cycles事件被硬件节流干扰：对 Intel CPU，可换用更稳定的cpu/event=0x00c0,umask=0x00,name=inst_retired_any/（即 retired instructions）
perf report 里看什么、不看什么
默认 perf report 显示的是“带子树聚合”的调用链，容易把底层库函数（如 malloc、memcpy）的开销错误归到上层业务函数名下：
- 先加
--no-children：看清原始采样分布，确认热点是否真在你的代码里，而不是被libc吃掉了 - 用
-F symbol,dso显式看模块归属：perf report -F symbol,dso --no-children，区分myapp、libstdc++.so.6、kernel的占比 - 别信“Top Down”树状图：它依赖 CPU 微架构模型（如 Intel TopDown），不同型号解释差异大；优先看 raw sample count 和
period字段 - 火焰图不是万能的：
perf script | FlameGraph/stackcollapse-perf.pl | FlameGraph/flamegraph.pl适合快速扫视，但丢失了perf report支持的交互式下钻（→/← 键）和符号过滤能力
遇到符号缺失或地址乱码怎么办
看到一堆 [unknown] 或 0x7f8a1b2c3d4e，不是 perf 坏了，而是符号解析链断了：
- 检查
/proc/<pid>/maps</pid>里对应地址段是否标记为r-xp（可执行）且有映射文件路径；若显示[anon]，说明是 JIT 代码（Java/JS/V8）或 mmap 分配的可执行内存，需额外处理 - 动态链接库未加载符号？运行
perf report --symfs /path/to/debug/build/指向含符号的构建目录 - Go 程序默认 strip 符号：编译时加
-gcflags="all=-N -l"，或用go tool objdump -s "main\." ./mygoapp辅助对照 - 内核模块符号缺失：确保安装了对应内核版本的
kmod-debuginfo，并验证/lib/modules/$(uname -r)/build/存在
真正卡住人的从来不是“怎么启动 perf”，而是采样数据出来后，分不清是你的代码慢、系统调用慢、还是硬件在拖后腿。符号链、事件语义、聚合逻辑这三环，漏一环结论就偏。
