该用bcc而非bpftrace的场景是需精细控制eBPF生命周期、复用C逻辑或嵌入Python/C++应用时；bpftrace仅适合一次性命令行探针。
什么时候该用 bcc，而不是 bpftrace
bcc 适合需要精细控制 eBPF 程序生命周期、频繁复用 C 风格逻辑、或要嵌入到 Python/C++ 应用里的场景。比如你要写一个持续采集 TCP 重传事件并聚合进 Prometheus 的守护进程，bcc 提供的 BPF 类和 perf_buffer 接口能直接对接业务逻辑；而 bpftrace 更像“一次性命令行探针”，写完就跑，不便于状态维护或复杂数据结构处理。
常见错误现象：用 bpftrace 尝试做跨事件状态跟踪（比如匹配 tcp_sendmsg 和后续的 tcp_retransmit_skb），结果发现没有变量持久化能力，脚本卡死或输出错乱。
-
bcc支持自定义 map 类型（如LRU_HASH）、用户态回调函数、多阶段加载，bpftrace只支持固定几种内置 map（hist,count,sum） -
bcc编译依赖完整内核头文件（/lib/modules/$(uname -r)/build），bpftrace只需运行时内核 BTF 或调试信息 -
bcc的 Python 绑定在容器里容易因ctypes加载失败报ImportError: libbcc.so；bpftrace是静态链接二进制，更轻量
libbpf-tools 和 bcc 的根本区别在哪
libbpf-tools 是纯 C 实现、基于 libbpf + BTF + CO-RE 的工具集，目标是“一次编译、到处运行”；bcc 是运行时 JIT 编译，每次启动都要解析 C 代码、生成 eBPF 字节码、再加载，对内核版本强敏感。
典型使用场景：你在 CentOS 7（内核 3.10）上没法用 bcc 运行 biolatency，因为缺少 bpf_probe_read_kernel 等 helper；但 libbpf-tools/biolatency 如果有对应 BTF，就能直接跑——前提是你的内核开启了 CONFIG_DEBUG_INFO_BTF=y。
-
libbpf-tools不依赖 clang/LLVM 运行时，部署包体积小（单个可执行文件），bcc需要安装python3-bcc+clang+ 内核头 -
libbpf-tools的错误提示更底层（比如libbpf: failed to load object: Invalid argument），往往指向 BTF 缺失或 CO-RE 重定位失败；bcc报错更“友好”但可能掩盖真实问题（如把struct sock成员偏移算错归为“unknown field”） -
libbpf-tools默认不带 Python 接口，想二次开发得自己写libbpf调用；bcc天然支持 Python 脚本热改逻辑
为什么 bpftrace 的 tracepoint 比 kprobe 更稳
因为 tracepoint 是内核预定义的稳定钩子点，接口契约明确；kprobe 是动态插桩函数入口，一旦内核函数签名变更（比如加了参数、改了 inline 行为），bpftrace 的 kprobe:do_sys_open 就可能找不到符号，或者读取寄存器出错导致 invalid memory access。
常见错误现象：在较新内核（6.1+）上用 bpftrace -e 'kprobe:tcp_v4_connect { printf("hit\n"); }' 无输出，但换成 tracepoint:net:inet_connect 就立刻生效——后者由内核维护 ABI 兼容性，前者依赖具体函数实现细节。
-
tracepoint性能开销更低（无寄存器保存/恢复），且不会因函数内联失效 -
tracepoint参数类型固定（通过/sys/kernel/debug/tracing/events/<cat>/<event>/format查），kprobe得靠ptregs手动解析，容易错位 - 不是所有函数都有对应
tracepoint，查可用列表用ls /sys/kernel/debug/tracing/events/，缺的话只能退回到kprobe或换bcc做条件判断
libbpf-tools 启动失败最常见的三个原因
不是代码写错了，而是环境没对齐。最常卡在 BTF、CO-RE 和权限三块。
典型错误信息：libbpf: failed to find valid kernel BTF、libbpf: Error in bpf_object__load_xattr: Permission denied、libbpf: prog 'xxx': failed to apply relocations。
- BTF 缺失：检查
/sys/kernel/btf/vmlinux是否存在，不存在就装kernel-debuginfo包（RHEL/CentOS）或linux-image-extra-$(uname -r)（Ubuntu） - CO-RE 重定位失败：说明目标内核结构体布局和编译时差异太大，尝试加
#define LIBBPF_FORCE_COERCE或降级到更接近的内核版本重新编译 - 权限不足：普通用户无法加载部分 program type（如
tracing），需sudo或配置/proc/sys/kernel/unprivileged_bpf_disabled=0（注意安全影响）
bpftrace -l | grep tcp 看 tracepoint 是否覆盖你要的路径，再试 libbpf-tools/biosnoop 能不能跑通，最后才决定要不要上 bcc 写定制逻辑。BTF 和 CO-RE 这些词听着高级，但卡住的时候，往往就是少装了一个 debuginfo 包。 
