Go程序的符号表是编译器写入二进制的地址映射记录，须用go tool nm等工具直接读取：T为函数、D为已初始化数据、B为未初始化数据，-s剥离符号表、-w剥离DWARF，二者独立且缺一不可支撑可观测性。
Go程序的符号表不是靠“语言学习技巧”分析出来的，而是靠工具链和调试库直接读取的。试图用自然语言学习那一套去“理解”符号表，会浪费大量时间且得不到准确结果。
go tool nm 是最直接的符号查看方式
它不依赖源码或文档，只读二进制文件里的符号段，输出函数、变量名及其地址和类型标记。
-
go tool nm默认显示所有符号，包括 runtime 和标准库的，容易干扰判断；加-n按地址排序，加-size显示大小，能快速定位大函数或全局变量 - 符号类型标记很重要：
T是函数（text），D是已初始化数据（如main.AppVersion被-ldflags -X注入后就变成D），B是未初始化数据（bss），U表示未定义（外部引用） - 如果看到大量形如
runtime.*或reflect.*的符号，说明没 strip，但不代表业务逻辑可读——Go 编译器默认不导出局部变量或内联函数名
debug/gosym 解析符号需配合 DWARF 信息
仅靠 gosym 的 SymTable 无法还原源码行号或参数名，必须有编译时保留的调试信息（即未加 -ldflags=-s 或 -gcflags=-l）。
-
SymTable.Lookup("main.main")能拿到函数起始地址和大小，但若二进制被 strip 过，Lookup返回 nil -
SymTable.Line(pc)依赖 DWARF 的.debug_line段，缺失时返回ok=false，不是 bug，是预期行为 - 不要试图用
gosym去“猜”变量作用域——它不存作用域树，go/types.Scope是编译期结构，运行时不落地到二进制里
混淆或剥离符号前，先确认哪些符号真有必要暴露
很多团队一上来就加 -ldflags=-s -w，结果发现 pprof 火焰图全变 runtime.goexit，监控告警失效。
立即学习“go语言免费学习笔记（深入）”；
-
-s剥离符号表，-w剥离 DWARF，两者都开等于放弃所有基于符号的可观测性 - 真正该保护的是业务敏感字段（如
payment.Process、auth.TokenValidator），可用go:linkname隐藏或重命名，比全局 strip 更精准 - CI 构建时用
go tool nm -size app | grep -E '^(D|T) main\.' | sort -k2nr快速检查主包导出符号，比人工翻日志高效得多
符号表不是文本，没法“读懂”；它是编译器写进二进制的一组地址映射记录。想分析它，得用对工具，而不是套用语言学习的套路。最容易被忽略的点是：DWARF 和符号表是两套独立系统，一个删了另一个还在，但少了任何一个，调试能力就断一截。
