go二进制文件默认内嵌符号表，记录函数、全局变量等包级实体的名称、地址和类型，支撑nm、delve、pprof等工具；它不包含局部变量，-x仅修改string类型全局变量值，-s/-w剥离后gosym等功能失效。
main.main）、全局变量（如 main.AppVersion）、类型名等实体的名称、内存地址、大小和类别（Func / Var / Type）。它直接支撑 go tool nm、delve、pprof 和逆向分析工具的工作。
为什么 go tool nm 能看到 main.main 却看不到局部变量？
符号表只保留**包级作用域可见的命名实体**：导出/非导出的函数、全局变量、类型定义。局部变量、参数、临时对象在编译后被优化掉或仅存在于栈帧中，不进入符号表。
常见错误现象：go tool nm app | grep "myLocalVar" 返回空——这不是命令用错，是它本就不该存在。
使用场景：排查函数是否被内联、确认变量是否被编译器优化为常量、验证 -ldflags="-X" 是否生效。
要点：
-
nm输出中的T表示文本段（函数），D表示已初始化数据，B表示未初始化数据（bss） - Go 的符号名带完整包路径，比如
bytes.(*Buffer).WriteString，不是简单的WriteString - 启用
-gcflags="-l"禁用内联后，更多函数名会出现在符号表中
-ldflags="-X" 修改的是符号表里的哪个部分？
它只作用于**字符串类型的全局变量符号**，且该变量必须满足两个条件：已声明（哪怕未初始化）、类型为 string。
参数差异：-X 后跟 importpath.name=value，例如 -X main.AppVersion=v1.2.3；不能用于 int、struct 或未导出包中的变量。
容易踩的坑：
- 变量声明时写了初始值（
var AppVersion = "dev"），-X仍会覆盖，但若声明为var AppVersion string（零值），-X才真正“注入” - 如果包路径写错（比如写成
mian.AppVersion），构建不会报错，但运行时仍是空字符串 -
-X不影响符号表结构，只修改对应Var符号的运行时内存值
剥离符号表后，debug/gosym 还能用吗？
不能。一旦用 go build -ldflags="-s -w" 剥离，gosym.Load() 会返回 nil, error，因为 -s 删除了 Go 符号表节（.gosymtab），-w 删除了 DWARF 调试信息。
性能 / 兼容性影响：剥离后二进制体积减小约 5–15%，启动速度无变化，但所有依赖符号解析的功能全部失效：
— runtime.FuncForPC().Name() 返回空字符串
— pprof 无法显示函数名，只显示地址（如 0x456789）
— delve 无法设置函数断点，只能按地址断点
建议：仅在发布生产镜像前剥离，开发和测试环境务必保留。
