ebpf本身不监控go的fd泄漏，因无法感知go运行时对os.file或net.conn的生命周期管理；有效方案是procfs主路径（周期读取/proc/self/fd）结合ebpf辅助验证（如抓tcp连接状态），伪fd需谨慎甄别。
eBPF 本身不监控 Go 的 fd 泄漏
eBPF 程序无法直接感知 Go 运行时对 os.File 或 net.Conn 的生命周期管理。Go 的文件描述符创建（如 syscall.Open、net.socket）虽最终落入内核，但 Go runtime 不会为每次 Close() 触发可被 eBPF hook 的固定内核事件；close() 系统调用虽可被 trace，但大量伪 fd（如 anon_inode:[eventpoll]、timerfd）的关闭行为与业务逻辑脱节，单纯统计 close() 次数或失败率无法定位 Go 层泄漏点。
真正有效的组合方案是 procfs + eBPF 辅助验证
生产中必须用两种手段交叉确认：
- 主路径：每 10 秒读取
/proc/self/fd/目录条目数，用os.ReadDir("/proc/self/fd")（Go 1.16+）获取实时 fd 总量，趋势异常上涨即触发告警 - 辅助路径：用 eBPF 验证“是否真有未关闭的 socket”——不是查 Go 代码，而是抓内核层 TCP 连接状态。例如用
cilium hubble observe --pod myapp --type l4 --follow查看是否有大量ESTABLISHED连接长期不进入CLOSE_WAIT或FIN_WAIT2，这说明应用层没调用conn.Close()或http.Response.Body.Close() - 注意：eBPF 抓到的 socket 状态变化（如
TCP_CLOSE）和 Go 的defer f.Close()执行不是一一对应的。一个net.Conn可能复用底层 fd 多次，也可能因 panic 导致defer失效而 fd 悬空——eBPF 看不到这个“悬空”，只看到 fd 还在被内核引用
别在 Go 代码里集成 cilium/ebpf 库来查 fd
试图在 main.go 中 import github.com/cilium/ebpf 并尝试加载自定义程序，只会遇到以下问题：
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
-
permission denied：普通用户进程无权在运行时向内核注入 eBPF 字节码 -
invalid argument：缺少 BTF 信息时，cilium/ebpf无法适配不同内核版本的 struct 偏移，直接 panic - 资源错位：fd 泄漏是进程级资源问题，eBPF map 和程序应由节点级守护进程（如
cilium-agent）统一管理，而非每个 Go 实例各自加载
真要定制追踪（比如想标记某个 HTTP handler 创建的所有 socket），应该用 Go 原生方式：封装 net.Listen / http.Transport，记录 conn.RemoteAddr() 和 runtime.Caller()，再配合周期性 /proc/self/fd/ 扫描比对——eBPF 在这里只负责旁路验证，不参与决策。
最容易被忽略的点：伪 fd 不等于泄漏，但可能掩盖真问题
Go 程序中大量出现 anon_inode:[eventpoll] 或 socket:[1234567] 是正常现象，它们来自 epoll_create1、timerfd_create 等系统调用，由 Go runtime 自动管理。但若发现这些 fd 数量随请求量线性增长且不回落，就说明：
- 第三方库（如某些
fsnotify封装）未调用Watcher.Close() -
http.Client设置了过大的MaxIdleConnsPerHost，连接池长期 hold 住 socket - goroutine 挂起导致
defer conn.Close()永远不执行，而该 socket 又被 epoll 监听，于是同时出现在socket:[]和anon_inode:[eventpoll]列表里
此时仅靠 eBPF 统计 close() 系统调用次数毫无意义——因为根本没走到那一步。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
