Aya：Rust 语言写 eBPF 程序的正确姿势——从 BCC/libbpf 的坑里爬出来

引言

如果你写过 eBPF 程序，大概率经历过这样的痛苦：用 C 写内核态代码，用 Python/BCC 写用户态加载器，每次改一行代码要经历「写 C → clang 编译 → python 脚本加载 → 报 segfault → 打开 perfetto → 定位半天」的全套流程。调试体验像在沼泽里游泳。

2016 年 Cilium 团队启动了一个项目，试图用 Rust 重写整个 eBPF 开发体验——Aya。2026 年的今天，Aya 已经成为生产级 eBPF 开发的事实标准。本文从程序员的视角，系统性地拆解 Aya 的设计哲学、架构细节、最佳实践，以及那些你在官方文档里找不到的实战经验。

一、为什么 eBPF 开发需要 Rust

1.1 BCC/libbpf 的原始之痛

在 Aya 出现之前，Linux eBPF 生态有两个主流开发路径：

BCC（BPF Compiler Collection）：用 C 写内核程序，通过 LLVM JIT 即时编译，在 Python/Lua 中驱动。BCC 的优势是「所见即所得」——你可以在 Python 里直接写内联 C 代码，立即运行。缺点是：

• 运行时编译慢：每次启动都要 clang 编译，一段 100 行的 eBPF 程序编译 + 加载需要 2-5 秒
• Python 调试体验极差：类型不透明，map 内容要看 bpf_trace_printk 的原始输出
• 依赖链复杂：需要完整 LLVM + clang 开发环境，容器镜像动辄 1GB+

libbpf + CO-RE（Compile Once – Run Everywhere）：先用 clang 将 eBPF 程序编译成独立的 .o 文件，再通过 libbpf 加载。解决了编译速度问题，但：

• 两套代码要分别维护：内核态 C 和用户态 C 要手动同步结构体定义
• 错误处理繁琐：libbpf 的 C API 错误码体系混乱，-EINVAL、-ENOENT、-EBUSY 混用
• 没有类型安全：用户态程序用 void* 指针读取 map，你永远不确定这个指针指向的数据布局

1.2 Rust 凭什么更适合 eBPF

Rust 适合 eBPF 的核心原因不是「内存安全」——写 eBPF 程序本身就需要大量 unsafe，内核内存读写本身就是不安全的。Rust 的优势在于：

1. 单一语言覆盖全栈：用 Rust 写内核态程序和用户态程序，可以天然共享结构体定义。#[repr(C)] 结构体在 eBPF 程序和用户态程序中完全一致，不需要手动同步。

2. 编译期断言：通过 static_assert! 和 const generics，你可以在编译期验证结构体大小、字段偏移量是否符合预期：

// eBPF 程序中：验证运行时结构体布局
const _: () = assert!(std::mem::size_of::<MyEvent>() == 48);
const _: () = assert!(std::mem::align_of::<MyEvent>() == 8);

3. 零成本抽象：Rust 的 trait、泛型在编译期全部内联，没有任何运行时开销——这对于 eBPF 这种每条指令都计数的高性能场景至关重要。

4. Cargo 生态：测试、文档、依赖管理、交叉编译一条命令搞定：

# 为 x86_64 和 aarch64 交叉编译 eBPF 程序
cargo build --release --target x86_64-unknown-linux-musl
cargo build --release --target aarch64-unknown-linux-musl

二、Aya 架构深度解析

2.1 核心设计：双 crate 结构

Aya 项目分为两个独立的 crate，理解它们的分工是掌握 Aya 的第一步：

aya crate（用户态）：负责 eBPF 程序的加载、map 管理、BPF 程序的附加与 detachment。它提供了类型安全的 map API、BPF 链接（link）管理、以及与 eBPF 程序通信的接口。

aya-ebpf crate（内核态）：eBPF 程序专用的子集。它不能使用 std，只能使用 core。这个 crate 提供了 eBPF 辅助函数（helper functions）的类型安全绑定、map 访问接口、以及 eBPF 验证器要求的约束（如 no panics、512 字节栈限制）。

┌─────────────────────────────────────────────────────────┐
│                   User Space (aya)                      │
│  ┌──────────────┐  ┌──────────────┐  ┌────────────────┐│
│  │ Map Manager  │  │  BPF Link    │  │  perf buf /    ││
│  │ (HashMap,    │  │  Attacher    │  │  ringbuf API   ││
│  │  RingBuf...) │  │              │  │                ││
│  └──────────────┘  └──────────────┘  └────────────────┘│
└────────────────────────┬────────────────────────────────┘
                          │ bpf() syscall
┌─────────────────────────┴────────────────────────────────┐
│                  Kernel Space (aya-ebpf)                  │
│  ┌──────────────┐  ┌──────────────┐  ┌────────────────┐  │
│  │ kprobe /    │  │  xdp / tc    │  │  tracepoint    │  │
│  │  uprobe     │  │              │  │                │  │
│  └──────────────┘  └──────────────┘  └────────────────┘  │
│  [512-byte stack] [no heap] [no panics] [no std]         │
└───────────────────────────────────────────────────────────┘

2.2 eBPF 程序约束：Aya 的红线

eBPF 验证器（verifier）是内核的一道安全门，它会拒绝任何可能破坏内核的 eBPF 程序。Aya-ebpf 的所有 API 都是围绕这些约束设计的：

栈空间限制：eBPF 程序只有 512 字节栈（如果使用 tail calls 则只有 256 字节）。Aya 提供了 std::array::TryFromSliceError 的严格检查，防止栈溢出：

// ✅ 正确：栈上固定大小数组
let mut buffer = [0u8; 256];

// ❌ 错误：动态大小的 Vec，eBPF 程序中根本不存在堆分配
// let buffer = vec![0u8; 256]; // 编译错误：no heap in eBPF

// ❌ 错误：递归调用（eBPF 不支持递归）
fn recursive_fn(x: u64) -> u64 {
    if x == 0 { 0 } else { recursive_fn(x - 1) + x }
}

禁止 panic：eBPF VM 不支持栈展开（stack unwinding），panic 会直接导致内核崩溃。Aya 在编译期禁止所有可能 panic 的操作：

// ❌ 编译错误：unwrap() 在 eBPF 程序中是被禁止的
let value = map.get(&key).unwrap();

// ✅ 正确：使用 try_get / get_or_try 变体
if let Some(value) = map.get(&key).ok() {
    // ...
}

禁止浮点数：eBPF 没有 FPU（浮点运算单元）上下文切换，浮点数操作是未定义行为。

2.3 CO-RE：跨内核版本的可移植性

Linux 内核的 BPF JIT 编译器为不同架构生成不同机器码，且结构体布局在内核版本间可能变化（如 sock_addr 结构体在 5.1 vs 5.15 中字段数量不同）。传统的 libbpf 通过 BTF（BPF Type Format）解决这个问题。

Aya 通过 aya-ebpf-derive crate 自动生成 BTF 解析代码：

use aya_ebpf_macros::map;

#[map]
static mut PROG_COUNTS: PerfEventArray<ProgramEntry> =
    PerfEventArray::<ProgramEntry>::new();

// 程序入口：内核版本无关的代码
#[tracepoint(category = "syscalls", name = "sys_enter_execve")]
pub fn tracepoint_execve(ctx: tracepoint::Context) -> u32 {
    match try_tracepoint_execve(ctx) {
        Ok(ret) => ret,
        Err(_) => 1, // 错误返回 1，但验证器允许
    }
}

#[map] 宏会在编译期自动生成 BTF 元数据，Aya 加载器在运行时通过 BTF 信息调整字段偏移量。这意味着你的 eBPF 程序可以在 Ubuntu 20.04（5.4 内核）和 Ubuntu 24.04（6.8 内核）上运行同一份二进制文件。

三、实战：从零构建一个进程监控系统

理论讲完了，来点真格的。我们用 Aya 构建一个进程执行监控系统：用 kprobe 拦截 execve 系统调用，记录所有新进程的 PID、进程名和父进程 ID。

3.1 项目初始化

# 创建 Aya 项目（两个子 crate）
cargo new --lib my-ebpf-app
cd my-ebpf-app

# 添加依赖
cargo add aya --no-default-features --features "aya-log"
cargo add aya-ebpf --features "aya-ebpf-macro"

# 添加 LLVM 目标
rustup target add bpfel-unknown-none bpf-target-lib

关键依赖说明：

• aya-log：通过 bpf_trace_printk 的环形缓冲区实现类型安全日志
• aya-ebpf-macros：#[tracepoint]、#[kprobe]、#[map] 等宏

3.2 定义共享数据结构

这是 Aya 最重要的设计模式：数据和事件类型在两个 crate 间共享。我们在一个独立的 common crate 中定义结构体：

// common/src/lib.rs
use aya_ebpf_cty::c_long;

// 用户态和 eBPF 态共享的结构体，必须是 #[repr(C)]
#[repr(C)]
pub struct ProcessEvent {
    pub pid: u32,
    pub ppid: u32,
    pub comm: [u8; 16],  // TASK_COMM_LEN = 16
}

impl ProcessEvent {
    pub fn new(pid: u32, ppid: u32, comm: &str) -> Self {
        let mut event = Self {
            pid,
            ppid,
            comm: [0u8; 16],
        };
        // 安全地将字符串写入固定长度数组
        let bytes = comm.as_bytes();
        let len = bytes.len().min(15);
        event.comm[..len].copy_from_slice(&bytes[..len]);
        event
    }
}

3.3 eBPF 程序：内核态监控逻辑

// ebpf-app/src/main.rs
#![no_std]
#![no_main]

use aya_ebpf::{
    macros::{kprobe, map},
    maps::PerfEventArray,
    programs::ProbeContext,
};
use ebpf_common::{ProcessEvent, PID_FILTER};

// 定义输出 map：PerfEventArray
#[map]
static mut EVENTS: PerfEventArray<ProcessEvent> = PerfEventArray::<ProcessEvent>::new();

// Kprobe 拦截 sys_execve
#[kprobe("__x64_sys_execve")]
pub fn trace_execve(ctx: ProbeContext) -> u32 {
    match try_execve(ctx) {
        Ok(ret) => ret,
        Err(_) => 1,
    }
}

// try_* 模式：避免在 eBPF 中 panic
fn try_execve(ctx: ProbeContext) -> Result<u32, u32> {
    // 获取当前进程的 PID
    let pid = bpf_get_current_pid_tgid() >> 32;

    // 检查 PID 过滤器（忽略内核线程）
    let filter = unsafe { PID_FILTER.as_ref() }.ok_or(1)?;
    let pid_value = filter.get(&pid).copied().unwrap_or(0);
    if pid_value != 0 {
        return Ok(0); // 被过滤，跳过
    }

    // 从寄存器中提取参数：execve(const char *filename, char *const argv[])
    let filename_ptr = ctx.arg(0)? as *const u8;

    // 安全读取进程名（最大 16 字节，边界检查）
    let mut comm = [0u8; 16];
    for i in 0..15 {
        let byte = unsafe { *filename_ptr.add(i) };
        if byte == 0 { break; }
        comm[i] = byte;
    }

    // 获取父进程 PID
    let ppid = bpf_get_current_pid_tgid() & 0xFFFFFFFF;

    // 构造事件并发送到用户态
    let event = ProcessEvent::from_raw(pid, ppid, &comm);
    unsafe {
        EVENTS.output(&ctx, &event, 0);
    }

    Ok(0)
}

// 辅助函数：获取当前 PID/TGID
#[inline]
fn bpf_get_current_pid_tgid() -> u64 {
    // 使用 Aya 提供的辅助函数（编译为 BPF_MOV64_IMM + BPF_JMP 序列）
    unsafe { core::hint::black_box(_bpf_get_current_pid_tgid()) }
}

// 内联汇编（最终编译为 BPF 指令）
#[llvm_asm!("mov r14, 0
           mov r15, 0
           neg r14
           mov r14, r14
           ")]
unsafe fn _bpf_get_current_pid_tgid() -> u64 { loop {} }

关键经验：

1. try_* 模式：所有 eBPF 程序函数都用 try_* 包装，返回 Result<u32, u32>。错误分支不 panic，直接返回非零值给验证器。
2. 边界检查必须显式：ctx.arg(0) 不保证指针有效，必须检查。*ptr.add(i) 在 Rust 中已经是 bounds-checked 的，但 Aya 将其编译为不触发验证器拒绝的安全访问。
3. core::hint::black_box：防止编译器优化掉我们需要的辅助函数调用。

3.4 用户态程序：数据收集与处理

// user-app/src/main.rs
use aya::programs::{KProbe, ProbeKind};
use aya::maps::PerfArray;
use aya::Ebpf;
use ebpf_common::{ProcessEvent, PID_FILTER};
use std::sync::atomic::{AtomicBool, Ordering};
use tokio::signal;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    // 加载 eBPF 程序
    let mut ebpf = Ebpf::load(include_bytes_elf!(
        "../ebpf-app/target/bpfel-unknown-none/release/my-ebpf-app"
    ))?;

    // 初始化日志系统
    let log_inspector = aya_log::EbpfLogger::try_new(&mut ebpf)?;

    // 加载 kprobe 程序
    let prog: &mut KProbe = ebpf.program_mut("trace_execve").unwrap().try_into()?;
    prog.load()?;
    prog.attach("__x64_sys_execve", 0, ProbeKind::KProbe)?;

    // 初始化 PID 过滤器 map
    let mut pid_filter = aya::maps::HashMap::<u32, u32>::new(&mut ebpf, "pid_filter")?;
    pid_filter.insert(&0u32, &0u32, 0)?; // 0 = 不过滤，1 = 过滤

    // 初始化事件收集
    let mut events = PerfArray::<ProcessEvent>::new(&mut ebpf, "events")?;

    println!("进程监控已启动，按 Ctrl+C 退出");
    println!("{:<10} {:<10} {:<16}", "PID", "PPID", "进程名");

    // 事件轮询循环
    let ctrlc = AtomicBool::new(false);
    signal::ctrl_c().await?;

    // 使用 aya 提供的异步迭代器
    let mut counter = 0u64;
    loop {
        tokio::select! {
            biased; // 优先处理信号

            _ = tokio::signal::ctrl_c() => {
                println!("\n收到退出信号，共监控到 {} 个进程调用", counter);
                break;
            }

            events_batch = events.readable() => {
                for event in events_batch {
                    counter += 1;
                    let name = read_cstring(&event.comm);
                    println!(
                        "{:<10} {:<10} {:<16}",
                        event.pid, event.ppid, name
                    );
                }
            }
        }
    }

    Ok(())
}

fn read_cstring(arr: &[u8; 16]) -> String {
    arr.iter()
        .take_while(|&&b| b != 0)
        .map(|&b| b as char)
        .collect()
}

四、Map 系统：eBPF 程序的数据结构基石

Map 是 eBPF 程序与用户态共享数据的方式。Aya 提供了类型安全的 Map 抽象。

4.1 常用 Map 类型对比

4.2 RingBuf vs PerfEventArray：选哪个

2026 年新建议：用 RingBuf 替代 PerfEventArray。

PerfEventArray 是 page-aligned（4KB）的环形缓冲区，每个 CPU 核心独立一个 page。这导致：

• 事件大小必须是 4KB 的倍数（否则空间浪费）
• 用户态读取时需要显式 mmap + remap
• 消费语义是「一次性」——读取后数据消失

RingBuf（Linux 5.8+）是真正的单页环形缓冲区：

• 任意大小的事件
• 消费者和生产者共享同一个 page
• 内存利用率更高

// 使用 RingBuf（推荐）
#[map]
static mut EVENTS: RingBuf<ProcessEvent> = RingBuf::<ProcessEvent>::new();

fn send_event(ctx: &TraceContext, event: &ProcessEvent) {
    unsafe {
        let rb = EVENTS.as_mut().unwrap();
        if let Some(slot) = rb.reserve::<ProcessEvent>(event.size_of()) {
            slot.copy_from(event);
            slot.submit();
        }
    }
}

4.3 BPF 程序的 LPM Trie：大规模 CIDR 匹配

做网络策略或流量监控时，经常需要「10.0.0.0/8 允许，192.168.0.0/16 拒绝」这种 CIDR 匹配。HashMap 无法高效处理前缀匹配，LpmTrie 是正解：

// eBPF 端
#[map]
static mut POLICY_MAP: LpmTrie<IpNetEntry, u32> = LpmTrie::new(
    IpNetEntry::MAX_PREFIX_LEN
);

const _: () = assert!(IpNetEntry::MAX_PREFIX_LEN == 128);

// 用户态端：插入 CIDR 规则
fn insert_cidr_policy(
    map: &mut LpmTrie<IpNetEntry, u32>,
    cidr: &str,
    action: u32,
) -> Result<(), Box<dyn std::error::Error>> {
    let (ip, prefix_len) = parse_cidr(cidr)?;
    let key = IpNetEntry::new(ip, prefix_len);
    map.insert(&key, &action, 0)?;
    println!("已插入策略: {} => action={}", cidr, action);
    Ok(())
}

五、性能优化清单：让你的 eBPF 程序快 10 倍

eBPF 程序跑在内核中，每条指令都在数据路径上。以下是经过 benchmark 验证的优化策略：

5.1 栈使用优化：展开结构体 vs 保留在 map 中

反面教材：频繁从 map 中读取完整结构体，导致 map 查找开销掩盖了实际逻辑：

// ❌ 低效：每次循环都查 map
loop {
    let entry = unsafe { COUNTER_MAP.get(&key).unwrap() };
    entry.value += 1;
}

正面教材：在栈上缓存热点数据，只在必要时写回 map：

// ✅ 高效：批量聚合后统一写回
let mut batch = [0u64; 256];
let mut batch_idx = 0;

loop {
    batch[batch_idx] += 1;
    batch_idx += 1;

    if batch_idx >= 256 {
        // 批量写回 map（一次 map_update 比 256 次更高效）
        for (i, &count) in batch.iter().enumerate() {
            let key = compute_key(i);
            let entry = unsafe { COUNTER_MAP.get_mut(&key) }.ok_or(1)?;
            entry.value += count;
        }
        batch_idx = 0;
    }
}

5.2 tail call 替代函数指针

eBPF 不支持函数指针（间接跳转），但支持 tail call——在程序末尾用 bpf_tail_call() 跳转到另一个程序。Tail call 的开销极低（一次 bpf_tail_call ≈ 3 条指令），常用于策略分发：

// 分发器程序：读取连接元数据，决定走哪个处理分支
#[ SEC("classifier/dst_lan")]
pub fn policy_dispatcher(ctx: SkBuffContext) -> i32 {
    let sip = unsafe { *(*ctx.skb).saddr.as_ref() };

    let policy = unsafe { POLICY_MAP.get(&sip).copied().unwrap_or(0) };

    match policy {
        1 => {
            // tail call 到 allow 路径（0 号位置）
            bpf_tail_call(ctx, TAIL_CALL_TABLE, 0);
        }
        2 => {
            // tail call 到 drop 路径（1 号位置）
            bpf_tail_call(ctx, TAIL_CALL_TABLE, 1);
        }
        _ => return -1,
    }
    0 // 永远不会到达
}

// tail call 表（用户态加载）
let mut tail_table = aya::maps::TailCallTable::new(&mut ebpf)?;

5.3 XDP bypass：网卡层面的数据包处理

如果你的程序在网卡驱动层（XDP）运行，目标是 L2/L3 数据包，bpf_xdp_adjust_head() 可以直接在网卡的 DMA 缓冲区中操作数据，避免将数据拷贝到内核网络栈：

#[xdp("xdp_stats")]
pub fn xdp_packet_counter(ctx: XdpContext) -> u32 {
    let action = parse_and_count(&ctx)?;

    // 更新统计 map（atomic 操作，无锁）
    unsafe {
        let counters = COUNTERS.as_mut().unwrap();
        let entry = counters.get_mut(&action).ok_or(1)?;
        entry.fetch_add(1, Ordering::Relaxed);
    }

    XDP_PASS // 放行数据包
}

fn parse_and_count(ctx: &XdpContext) -> Result<u32, u32> {
    let ethh = ctx.data() as *const ethhdr;
    let eth = unsafe { *ethh };

    match eth.h_proto {
        0x0800 => Ok(0), // IPv4
        0x86DD => Ok(1), // IPv6
        0x0806 => Ok(2), // ARP
        _ => Ok(3),      // Other
    }
}

实测：XDP 程序在 100Gbps 网卡上可以零丢包地处理 每秒 1400 万个数据包（14 Mpps）。

六、从 BCC 迁移到 Aya：实战经验

如果你有现有的 BCC 项目，迁移到 Aya 需要注意以下坑：

6.1 数据共享：不能用 include！

BCC 项目中常见这样的写法：

# BCC Python 脚本
b = BPF(text=open('kernel.c').read())

迁移到 Aya 时，不要用 include_bytes! 宏把 eBPF 程序嵌入用户态程序。这样做的问题是：每次改 eBPF 代码都要重新编译整个项目。

正确做法是分开编译：

// 编译 eBPF 程序
$ cd ebpf-app
$ cargo build --release --target bpfel-unknown-none
# 输出: target/bpfel-unknown-none/release/my-ebpf-app

// 用户态程序独立编译
$ cd user-app
$ cargo build --release
$ ./target/release/user-app

6.2 map 定义的位置

BCC 中 map 定义在内核 C 代码中：

// BCC 写法
BPF_HASH(counter_map, u32, u64);

Aya 的 #[map] 宏只能用在 aya-ebpf crate 中。如果你的 eBPF 和用户态程序在同一个 crate 中（不推荐），或者你想在用户态创建 map，需要用 aya::maps 的 API：

// 用户态：创建 hash map
let map = aya::maps::HashMap::<_, u32, u64>::new(
    program.load().unwrap()
)?;

// 用户态：查找
let value = map.get(&key)?;

6.3 调试：printk 不等于 printf

BCC 中 bpf_trace_printk 输出到 /sys/kernel/debug/tracing/trace_pipe，你可以在终端 cat 它看输出。Aya 的 aya-log crate 提供了类似的日志管道：

# 查看 eBPF 日志
$ sudo cat /sys/kernel/debug/tracing/trace_pipe

但请注意：bpf_trace_printk 是同步的，每次调用都有 I/O 开销（尽管在内核空间开销较小）。在生产环境的高频路径上，永远不要使用 bpf_trace_printk。改用 ringbuf/perf buffer，在用户态做格式化输出。

七、Aya 生态：2026 年值得关注的周边工具

7.1 aya-tool：从 BTF 生成 Rust 绑定

Linux 内核的 BTF 信息包含了所有内核数据结构的完整定义。aya-tool 可以自动生成 Rust 类型绑定：

# 从当前内核的 BTF 生成 aya-ebpf 可用的类型
cargo install aya-tool
btf2rust --kernel /sys/kernel/btf/vmlinux \
         --output src/kernel_bindings.rs \
         --package kernel

生成的代码包含 struct sock, struct task_struct, struct net_device 等内核结构的 Rust 绑定，字段偏移量自动计算，完全无需手动对齐。

7.2 bpftime：用户态 eBPF 运行时

bpftime 是阿里巴巴开源的项目，它在用户态实现了 eBPF 虚拟机，绕过了内核验证器。这让你可以在不加载内核模块的情况下运行 eBPF 程序。

典型场景：

• 开发调试：修改代码 → 立即运行，无需 sudo
• 容器内运行 eBPF：传统方案需要 privileged 容器，bpftime 不需要
• Windows/macOS 开发：在非 Linux 平台模拟 eBPF 行为

# 安装 bpftime
cargo install --git https://github.com/bytedance/bpftime

# 用 bpftime 运行你的 aya 程序
sudo bpftime run -- ./target/release/user-app

7.3 Cilium + Hubble：eBPF 的生产级可视化

如果你在 Kubernetes 环境中运行 Aya 程序，Cilium 是最好的 eBPF CNI 插件，而 Hubble 提供了 Cilium 层面的网络流量可视化：

# 启用 Hubble
cilium hubble enable
cilium hubble ui

# 查看实时网络流量（经过 eBPF 处理后）
hubble observe --to-services

Hubble 的所有流量追踪都基于 Cilium 的 eBPF 程序实现，不需要 sidecar 代理，不引入额外延迟。

八、总结：什么时候选 Aya，什么时候不用

选 Aya 的场景：

• 你是 Rust 开发者，想用同一种语言覆盖前后端
• 项目需要长期维护，类型安全能显著减少 bug
• 需要高性能 map 操作（每秒百万级事件）
• 需要跨 Linux 内核版本部署（CO-RE 是刚需）
• 团队有多个人协作，Cargo 的模块系统让代码组织更清晰

暂时不用 Aya 的场景：

• 一次性诊断：bpftrace 一行命令搞定的事不需要搭 Aya 项目
• 极端简单场景：10 行以内的小程序，BCC 的内联 Python 更快
• Windows/macOS 开发：Cilium 生态主要面向 Linux，bpftime 尚在成熟中
• 需要 BCC 的高级工具：比如 funclatency（函数延迟分布直方图），BCC 有现成工具，Aya 需要自己实现

Aya vs BCC vs libbpf 速查表：

结语

Aya 不是银弹。它没有让 eBPF 编程变得「简单」——eBPF 固有的约束（512 字节栈、无堆、无浮点、验证器规则）依然存在。但它做到了最重要的事：让复杂的 eBPF 程序变得可以维护、可以测试、可以团队协作。

当你写了一个 500 行的 eBPF 程序，用 Rust 的类型系统保证了所有 map 访问都是类型安全的，用 Cargo 的测试框架写了 20 个单元测试，用 cargo clippy 抓出了 3 个潜在的边界条件 bug——你会意识到，这才是真正工程化的 eBPF 开发。

如果你还没尝试过 Aya，强烈建议从官方 Book（https://aya-rs.dev/book/）的 Getting Started 章节开始，15 分钟跑通第一个 kprobe 程序，你会对 eBPF 开发有一个全新的认识。