Go二进制体积大主因是默认静态链接全家桶：CGO_ENABLED=1引入libc和cgo DNS、DWARF调试信息占30%~50%、冗余反射元数据；关闭CGO并加-tags netgo可减1~3MB，-ldflags "-s -w"再减1~2MB。
为什么 Go 编译出的二进制这么大？
Go 默认静态链接，把 libc、net DNS 解析逻辑、CGO 支持、调试符号全塞进去了。一个空 main.go 编译出来都 2MB+，不是你代码胖，是默认“全家桶”太实在。
关键影响点：CGO_ENABLED=1（默认开启）会让 Go 链接系统 libc，同时启用 net 包的 cgo 模式（比如用 getaddrinfo），这直接引入几 MB；调试信息（DWARF）占 30%~50% 体积；还有未裁剪的反射元数据和未用的包符号。
关闭 CGO + 强制纯 Go net 解析
这是最立竿见影的一步，能干掉 1~3MB。只要你不依赖 os/user、os/signal 的某些边缘行为，或自定义 resolv.conf 解析逻辑，纯 Go 模式完全够用。
- 编译前执行：
CGO_ENABLED=0 - 确保
net包走纯 Go：加-tags netgo（注意是netgo，不是net） - 如果用了
os/user.Lookup*，得换user.Current()或改用golang.org/x/sys/unix手动调用，否则会 panic
示例命令：CGO_ENABLED=0 go build -tags netgo -o myapp .
剥离调试信息和符号表
go build 默认带完整 DWARF 和符号表，对生产部署毫无用处，只增体积不增功能。
- 加
-ldflags "-s -w"：其中-s去除符号表，-w去除 DWARF 调试信息 - 注意顺序：必须写在
go build后、包路径前，比如go build -ldflags "-s -w" -o app . - 别用
-ldflags="-s -w"（等号后没空格）——旧版 Go 会静默忽略
这一组 flag 通常再省 1~2MB，且不影响运行时 panic 堆栈行号（行号还在，只是没函数名和变量名）。
用 UPX 压缩（谨慎评估）
UPX 对 Go 二进制压缩率高（常压到原大小 40%），但有真实代价：启动变慢（解压开销）、部分杀软误报、某些容器环境（如 gVisor、Firecracker）不支持。
- 先确认目标环境允许：跑
upx --test your_binary看是否校验通过 - 用
upx -9 --lzma（最高压缩，LZMA 算法比默认更小） - 别对调试中的二进制 UPX——它会破坏
pprof符号、delve调试能力
真正上线前才压，CI/CD 流水线里建议分两步产出：一个裸二进制用于调试，一个 UPX 版用于发布。
体积不是越小越好，而是够用且稳定。CGO 关不关、UPX 上不上，得看你的依赖链和部署环境——比如用了 cgo 的 SQLite 驱动，那第一步就绕不开。
