pprof-cpp 编译失败主因是未链接 libprofiler 库，需源码编译 gperftools 并启用 --enable-profiling；ProfilerStart 无效多因环境变量错误、fork/dlopen 过早或容器限制 setitimer。
pprof-cpp 编译不过：找不到 libprofiler 或 PROFILER_ENABLE 未生效
根本原因是 pprof-cpp（即 Google CPU Profiler）不是头文件库，必须链接静态或动态的 libprofiler；而它默认不随 gperftools 安装，得自己编译。常见现象是 #include <gperftools/profiler.h> 能过，但链接时报 undefined reference to ProfilerStart。
- 先确认你装的是完整版 gperftools：Ubuntu/Debian 上用
sudo apt install libgoogle-perftools-dev，但注意该包通常不含libprofiler—— 它只含 tcmalloc 相关库 - 必须从源码编译 gperftools，并显式启用 profiler：
./configure --enable-profiling && make && sudo make install - 编译你的程序时，链接顺序很重要：
-lprofiler必须放在你的目标文件之后，且优先于-lpthread（否则可能符号解析失败） - 如果用 CMake，别只写
find_package(gperftools)，要手动指定find_library(GPERFTOOLS_PROFILER_LIB profiler)并 link
ProfilerStart() 不触发采样：环境变量或初始化时机不对
即使链接成功，ProfilerStart() 也常静默失败——不是崩溃，而是压根没开 profiler。核心原因就两个：环境变量冲突、或在 profiler 初始化前调用了 fork() / dlopen() 等破坏采样上下文的操作。
- 确保没设置
CPUPROFILE=""（空值会禁用）、CPUPROFILE_FREQUENCY值过大（如 1000000Hz 会导致开销爆炸，部分版本直接拒绝启动） - 调用
ProfilerStart("profile.out")必须在 main() 开头、任何线程创建前、且不能在__attribute__((constructor))函数里——后者可能早于 profiler 自身初始化 - 如果你的程序用了
dlopen()加载插件，务必在ProfilerStart()之后再做；否则 profiler 无法 hook 动态符号，采样会漏掉插件里的函数 - 验证是否真启动了：运行后检查
/proc/PID/status中有没有TracerPid: 0（正常）或非零值（被其他 tracer 占用），以及ls -l profile.out*是否有生成
生成的 profile.out 无法用 pprof 解析：格式不匹配或路径问题
pprof 是 Go 写的命令行工具，它默认期望的是「gperftools 格式」，但如果你用的是新版 pprof（比如 go tool pprof），它其实更倾向接收 HTTP 接口或 perf script 输出；老版 pprof（来自 gperftools 包）才原生支持 profile.out。
- 别用
go tool pprof直接读profile.out—— 它会报unrecognized profile format；要用pprof（来自apt install google-perftools或源码编译出的二进制） - 确保
profile.out文件权限可读，且路径中不含空格或 shell 特殊字符（pprof解析器对路径很敏感） - 常用分析命令：
pprof --text ./myapp profile.out（文本火焰图），pprof --svg ./myapp profile.out > profile.svg（需安装 graphviz） - 如果程序是多进程，且用了
fork()，默认 profile.out 会被子进程覆盖；加CPUPROFILE_PER_THREAD=1或手动在子进程中调用ProfilerStart()并指定不同文件名
性能开销与信号干扰：profiler 启动后程序变慢或 hang 住
Google CPU Profiler 使用 setitimer(ITIMER_PROF) + 信号处理，在高频率（默认 100Hz）下对小函数、锁竞争严重或信号密集的程序影响显著。最典型表现是：开启 profiler 后，程序卡在 pthread_cond_wait 或死锁，甚至 SIGPROF 被误投递到错误线程。
立即学习“C++免费学习笔记（深入）”；
- 降低采样频率能缓解：
CPUPROFILE_FREQUENCY=25（单位 Hz），但会牺牲精度；不要设为 1 或 1000+，前者几乎无用，后者可能让程序不可用 - 避免在 signal handler 里调用 malloc / printf / lock —— profiler 的信号 handler 本身是受限的；如果你的代码在
SIGUSR1handler 里做了重操作，和SIGPROF可能冲突 - 某些容器环境（如 Kubernetes）或 seccomp 配置会禁用
setitimer，此时ProfilerStart()返回 false 但不报错；可通过 strace 看是否出现setitimer(2) = -1 EPERM - 真正需要低开销 profiling 时，考虑
perf record -e cycles:u+perf script，它走内核接口，对应用透明
