bpf.Map.Lookup() 是读取 eBPF map 单个键值对的标准方式，需确保键值类型、内存布局与 BPF 端严格一致，值变量须预先分配空间，错误需用 os.IsNotExist 判断键是否存在。
用 bpf.Map.Lookup() 读单个键值对最直接
Go eBPF 程序（比如用 github.com/cilium/ebpf）里，bpf.Map.Lookup() 是读取 map 中某个键对应值的标准方式。它底层调用 bpf_map_lookup_elem() 系统调用，要求键类型、值类型与 map 定义严格匹配。
常见错误是传入未初始化或长度不对的键/值变量——比如 map 键是 uint32，却传了个 int 或没取地址的局部变量；或者值结构体字段顺序/对齐和 BPF 端不一致，导致读出乱码。
- 键必须是指针，且内存布局与 BPF 端定义完全一致（例如 C struct → Go struct 字段顺序、
binary.Write序列化方式要一致） - 值变量需预先分配足够空间（如
var val MyStruct，不能是nil指针） - 返回
nil错误不代表键存在，需配合os.IsNotExist(err)判断是否 key not found
var key uint32 = 1
var val stats_t // 假设这是与 BPF map value 匹配的 Go struct
err := myMap.Lookup(&key, &val)
if err != nil && !os.IsNotExist(err) {
log.Fatal(err)
}
遍历 map 必须用 bpf.Map.NextKey() 配合循环
eBPF map 不支持类似 Go map 的 range 遍历，也没有内置迭代器。正确方式是用 bpf.Map.NextKey() 从空键（或上一个键）开始逐个获取下一个键，直到返回 os.ErrNotExist。
容易忽略的是：首次调用 NextKey(nil, &nextKey) 才能拿到第一个键；后续必须传入上一轮得到的键地址作为第一个参数，否则行为未定义。另外，map 类型影响遍历能力——hash 和 array 支持，但 percpu_hash 或 lru_hash 在某些内核版本下可能不支持完整遍历。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 起始键为
nil，表示“从头开始”；传入非 nil 键时，它必须是 map 中已存在的键（否则可能 panic 或跳过） - 每次调用前确保
nextKey变量已分配且类型匹配（如var nextKey uint32） - 并发读 map 时，
NextKey()不是原子操作，若 map 同时被 BPF 程序修改，可能漏项或重复，建议读前冻结或控制更新节奏
读 percpu_hash map 要额外处理多 CPU 副本
percpu_hash map 的每个 CPU 有自己的 value 副本，Lookup() 默认只读当前 CPU 的副本，而 GetNextKey() 遍历时也只返回键，不附带 CPU 维度信息。想聚合所有 CPU 数据，必须手动轮询每个 CPU 的副本。
关键点在于：value 结构体大小必须是 runtime.NumCPU() 的整数倍，且按 CPU 顺序连续排列；读出来后需按 valueSizePerCPU 拆分，再对每个切片做反序列化。官方库不自动帮你拆，全靠自己算偏移。
- 先用
runtime.NumCPU()获取 CPU 数量 - 分配足够大的字节切片（
make([]byte, map.ValueSize())），再用Lookup()一次性读入 - 用
unsafe.Slice()或手动切片按valueSizePerCPU := map.ValueSize() / runtime.NumCPU()分割 - 每个子切片再
binary.Read()或unsafe.Pointer转成对应结构体
注意 map 类型限制和内核兼容性
不是所有 map 类型都支持任意读操作。例如 hash_of_maps 和 array_of_maps 存的是 fd，Lookup() 返回的是 int 类型 fd 值，不是嵌套 map 内容；prog_array 读出来是 prog fd，不能当数据用。另外，lpm_trie 虽然支持 Lookup()，但不支持 NextKey() 遍历。
内核版本也很关键：5.6+ 才稳定支持 map_in_map 的 Lookup，5.10+ 对 percpu_cgroup_storage 的用户态读取才有完整文档支持。如果 Lookup() 返回 operation not supported，大概率是 map 类型 + 内核组合不被当前 ebpf 库支持。
- 查
/sys/kernel/debug/tracing/events/bpf/或用bpftool map dump确认 map 类型和内容是否符合预期 - 在
go.mod中锁定github.com/cilium/ebpf v0.12.0+，旧版对percpu和ringbuf支持不完整 - 生产环境建议加
map.Iterate()封装（社区有第三方 helper），避免裸写NextKey()循环出错
真正麻烦的不是语法，而是键值结构体在 C 和 Go 两端的内存对齐一致性，以及 percpu map 的多副本聚合逻辑——这两处出问题，日志里几乎只显示“读到零值”或“unexpected EOF”，得靠 bpftool map dump -j 对比原始二进制才定位得准。
