Go二进制默认静态链接运行时导致体积大，-ldflags="-s -w"是最有效的瘦身组合：-s移除符号表，-w移除DWARF调试信息，二者合用可减小30%–50%体积，且必须配对使用才能见效。
为什么 go build 出来的二进制动辄十几MB？
Go 默认静态链接所有依赖（包括调试符号、反射信息、测试代码），哪怕只写一行 fmt.Println("hello")，也会打包 runtime、gc、调度器等完整运行时。这不是 bug，是设计使然——但上线部署时，这些冗余部分确实没用。
-
-ldflags="-s -w"是最基础的瘦身组合：-s去掉符号表，-w去掉 DWARF 调试信息；两者合用通常能砍掉 30%–50% 体积 - 别在 CI/CD 里漏掉
-w：没有它，-s效果大打折扣，因为 DWARF 本身占空间更大 - 注意：加了
-w后，pprof堆栈会丢失函数名和行号，线上排障要权衡
-ldflags 中哪些参数真正影响体积，哪些只是“看起来有用”？
很多教程堆砌一堆 -ldflags 参数，但真正起效的就几个；其余要么无效，要么已过时。
- 有效且常用：
-s、-w、-buildmode=pie（对体积影响小，但某些发行版强制要求） - 基本无效：
-extldflags "-static"（Go 默认就是静态链接，这个 flag 对体积无影响） - 已被废弃：
-gcflags "-l"（关闭内联）——它可能让体积略增，且严重损害性能，别用 - 有副作用但可用：
-ldflags="-X main.version=1.2.3"这类字符串注入，只要值不长，体积影响可忽略
启用 Go 1.21+ 的 zstd 压缩后，为什么体积反而变大了？
Go 1.21 引入了 -ldflags="-compressdwarf=zstd"，目标是压缩 DWARF；但如果你已经用了 -w，DWARF 已被完全移除，这个 flag 就毫无作用，还可能因编译器路径判断异常导致构建失败。
- 只在必须保留调试信息（比如内部 debug 构建）时才考虑
-compressdwarf - 生产构建永远优先用
-w，而不是压缩 DWARF - 验证方法：构建后执行
file your-binary，如果显示 “not stripped”，说明-s没生效；再用readelf -S your-binary | grep -i debug看是否还有.debug_*段
CGO 关闭后体积下降不明显？检查你是否真关掉了
CGO_ENABLED=0 能避免链接 libc，对 Alpine 镜像或无 libc 环境很重要，但它对体积影响有限——除非你的项目实际调用了 C 代码（比如 net 包在某些系统上会 fallback 到 cgo）。
立即学习“go语言免费学习笔记（深入）”；
- 确认方式：构建后运行
ldd your-binary，输出 “not a dynamic executable” 才算真正关闭成功 - 常见陷阱：没设
CGO_ENABLED=0就直接跑go build，结果链接了系统 libc，二进制变大且失去跨平台性 - 如果你用
os/user或net包，在某些 Linux 发行版上仍可能隐式触发 cgo；加CGO_ENABLED=0并配合GODEBUG=netdns=go可彻底规避
-s 和 -w。 
