debug/elf 无法直接读取 Go 二进制完整符号表，因默认剥离符号（-ldflags="-s -w"），需手动解析 .dynsym + .dynstr；Symbols() 返回空非 bug，而是因 Go 不生成 .symtab，且 Symbol.Name 需显式用 StringTable().String(int(sym.Name)) 解析。
如何用 debug/elf 读取符号表，而不是直接 panic
Go 的 debug/elf 包本身不提供“一键读符号”函数，File.Symbols() 返回的是 []*Symbol，但很多符号（尤其是 Go 编译生成的二进制）会缺失或被丢弃——因为默认链接时用了 -ldflags="-s -w"，剥离了符号和调试信息。你调用 file.Symbols() 得到空 slice 或极少数符号（如 _main），不是代码写错了，是二进制本身没留。
实操建议：
- 先确认目标文件是否含符号：
readelf -s your_binary | head -20，看有没有NOTYPE或FUNC类型条目 - 若为空，别硬读
Symbols()，改用file.Section(".symtab")+ 手动解析；但注意：Go 默认不生成.symtab，只保留.dynsym（动态符号表），所以得查file.Section(".dynsym") -
.dynsym里的符号 name 是偏移量，必须配合.dynstr节区内容解码，不能直接取sym.Name
Symbol.Name 为什么是空字符串？
因为 Symbol 结构体中的 Name 字段在底层未自动填充——它只是个缓存字段，debug/elf 不会在加载时自动从字符串表拉数据。你看到空字符串，不是 bug，是设计如此。
正确做法是手动拼接：
立即学习“go语言免费学习笔记（深入）”；
- 拿到
.dynsym节区后，用sym.Section.StringTable()获取对应字符串表（通常是.dynstr） - 对每个
sym，调用s, err := sym.Section.StringTable().String(int(sym.Name))提取名称 - 注意
sym.Name是 uint32 偏移，不是索引，且可能为 0（表示无名），需判空
Go 编译的二进制里哪些符号能稳定读到？
Go 工具链对符号处理非常克制：默认不导出函数名，不写 .symtab，也不在 .dynsym 中放私有函数。能读到的通常只有：
-
main.main（如果没加-ldflags="-s"） -
runtime.*系列（如runtime.mstart），但仅当未 strip - 通过
//go:export标记并被 C 调用的函数（会进.dynsym） - CGO 导出的符号（
exported函数、全局变量）
想分析普通 Go 函数调用关系？单靠 debug/elf 读符号表做不到——得结合 DWARF 信息（debug/dwarf 包）或反汇编（debug/pe 不适用，但可用 objdump -d 或 gobindgen 类工具）。
用 ReadSymbols() 还是遍历 .dynsym？
File.Symbols() 内部其实就做了类似遍历 .symtab 或 .dynsym 的事，但它优先找 .symtab，而 Go 二进制基本没有这个节区。所以它常返回空，不是函数失效，是路径不对。
更可靠的做法是绕过 Symbols()，直取动态符号表：
dynsym := file.Section(".dynsym")
if dynsym == nil {
return nil, errors.New("no .dynsym section")
}
strtab := file.Section(".dynstr")
if strtab == nil {
return nil, errors.New("no .dynstr section")
}
// 解析 dynsym 数据，再用 strtab.String() 补名字
这一步没法省——DWARF 和符号表是两套体系，debug/elf 只管 ELF 结构，不负责语义还原。真正做静态分析时，.dynsym 只够列出口函数，函数内控制流、变量、类型仍要靠 DWARF 或 SSA 中间表示。
