go编译二进制体积大主因是默认保留调试符号、反射信息等，-s -w可剥离符号表和dwarf调试信息，但需配合禁用cgo、精简标准库、合理使用embed等手段才能显著减小体积。
Go 编译后二进制为什么这么大？
不是代码多，而是默认打包了调试符号、反射类型信息、函数名、行号映射等——这些对生产环境几乎无用，却占体积 30%–60%。尤其是启用 go build 默认行为时，debug 段和 gosymtab 段会完整保留。
go build -ldflags "-s -w" 真的够用吗？
够用，但有前提：它只剥离符号表（-s）和 DWARF 调试信息（-w），不碰其他膨胀源。实际效果取决于你的代码是否依赖反射、CGO、第三方库的调试支持。
-
-s去掉符号表 → 无法用gdb或pprof符号解析（但pprof仍可采样，只是函数名显示为地址） -
-w去掉 DWARF →dlv调试失效，runtime/debug.Stack()行号丢失 - 两者必须一起用才有效；单独用
-s或-w效果打折 - 注意空格和引号：
go build -ldflags="-s -w"和go build -ldflags " -s -w "都合法，但中间不能换行或含不可见字符
比 -s -w 更狠的压缩手段
当 -s -w 后仍超 10MB，说明还有“隐性体积大户”：CGO、标准库未裁剪部分、内联冗余、或者用了 embed 打包大文件。
- 禁用 CGO：
CGO_ENABLED=0 go build -ldflags="-s -w"—— 避免链接 libc，体积常降 2–5MB，且提升静态可移植性 - 精简标准库：避免导入
net/http/httputil、text/template等重型包；用io.WriteString替代fmt.Sprintf可省几百 KB -
embed文件别直接 embed 整个目录：//go:embed assets/*比//go:embed assets更可控，后者会递归包含所有子目录隐藏文件 - 交叉编译目标平台影响大：Linux amd64 二进制通常比 arm64 小 5–10%，因某些汇编优化路径更紧凑
验证是否真压缩成功了
别只看 ls -lh，那只是文件大小；要确认符号和调试段是否真没了。
立即学习“go语言免费学习笔记（深入）”；
- 查符号表：
nm yourbinary | head→ 为空表示-s生效；若有输出，说明没生效或被其他 ldflags 覆盖 - 查 DWARF：
file yourbinary→ 输出不含with debug_info字样才算-w成功 - 看段信息：
readelf -S yourbinary | grep -E "(symtab|debug)"→ 应无匹配结果 - 注意 strip 过的二进制无法用
go tool objdump反汇编函数，这是正常现象，不是失败
最麻烦的是混合了 CGO 和纯 Go 的项目：一个 import "C" 就可能让 -s -w 效果打五折，这时候得先决定要不要彻底切 CGO。
