debug/elf 不自动加载符号表，需手动调用 f.symbols() 或 f.dynamicsymbols() 并确保对应节存在；pie 文件符号地址为相对值，需加基址；open() 成功但 fileheader 为零说明非 elf 或读取不全。
为什么 debug/elf 读不到符号表？
不是 ELF 文件本身有问题，而是默认只加载了基本段头，SymbolTable 这类辅助信息得手动触发解析。Go 的 debug/elf 包不自动加载符号、重定位或调试节，它把控制权交给你——省资源，但也容易漏掉关键步骤。
- 调用
f.Symbols()前，必须确保.symtab或.dynsym节存在且可读；否则返回空切片 +nil错误，不报错也不提示 -
.symtab是静态符号表，通常在未 strip 的可执行文件里；strip 后只剩.dynsym，此时要用f.DynamicSymbols() - 若文件是 PIE（位置无关可执行文件），符号地址是相对的，直接打印
Symbol.Value看起来像 0x0 —— 实际需加上加载基址，而 Go 标准库不提供运行时基址推导
Open() 成功但 f.FileHeader 字段全是零？
常见于打开非 ELF 文件（比如你误传了 .o、.a 或 zip），或者文件被截断、权限不足导致只读到头部几个字节。elf.Open() 只校验魔数和 class 字段，不验证整个结构完整性。
- 检查
f.FileHeader.Class是否为elf.ELFCLASS64或elf.ELFCLASS32；如果是 0，说明魔数不对或读取失败 - 用
file(1)命令确认：运行file your_binary，输出应含ELF 64-bit LSB pie executable类字样 - 注意：
os.Open()返回的*os.File若被提前Close()，后续f.Section或f.Symbols()会静默失败（返回空），不是 panic
怎么安全提取函数入口地址（如 main）？
不能只靠符号名匹配，因为 main 在 Go 二进制中通常被重命名为 main.main，且可能没有全局符号条目（Go 默认隐藏符号）。更可靠的是结合程序头（Phdr）找入口点，再反查符号。
-
f.Entry给出的是虚拟地址（VA），不是文件偏移；要转成文件偏移需遍历f.Progs，找到覆盖该 VA 的Prog，计算VA - Prog.Vaddr + Prog.Off - 符号表里搜
"main.main"比"main"更靠谱，但 Go 1.20+ 开启-buildmode=pie后，main.main可能不出现在.symtab，只在.dynsym中 - 别依赖
Symbol.Size判断函数长度——Go 编译器不保证函数边界对齐，该字段常为 0
解析速度慢，大二进制卡住？
debug/elf 是纯内存解析，不做流式处理。遇到几百 MB 的 debuginfo 文件（如带 DWARF 的 stripped binary），f.Sections 或 f.Symbols() 可能分配大量内存并阻塞几秒。
立即学习“go语言免费学习笔记（深入）”；
- 只加载需要的节：用
f.Section(".text")替代遍历所有f.Sections；避免调用f.Symbols()如果你其实只需要段布局 - 不用
f.ImportedLibraries()和f.DWARF()—— 前者会扫完整个.dynamic节，后者会加载全部 DWARF 数据，开销极大 - 如果只是校验 ELF 结构，用
elf.NewFile(io.LimitReader(r, 1024))配合f.FileHeader就够了，不必读全文
真正麻烦的是混合场景：你既想拿符号，又得处理 PIE + strip + DWARF 压缩（zlib）——这时候标准库就只是起点，debug/elf 不负责解压、不负责重定位修正、也不猜你到底想分析 runtime 还是用户代码。细节全在节名、标志位和你是否愿意多走两步查手册。
