Go二进制体积大因默认静态链接运行时、标准库及调试信息；可通过CGO_ENABLED=0、-ldflags="-s -w"裁剪符号与调试数据，再酌情使用UPX压缩。
为什么 Go 编译出来的二进制这么大？
Go 默认静态链接，把运行时、标准库甚至调试信息全塞进一个文件里，所以哪怕 fmt.Println("hello") 也能编出 2MB+ 的可执行文件。这不是 bug，是设计使然——但生产环境往往不需要调试符号、CGO 支持或全部反射能力。
用 -ldflags 去掉调试信息和符号表
这是最立竿见影的一步。Go 的链接器支持大量裁剪选项，核心是 -ldflags：
-
-s：去掉符号表和调试信息（strip效果），体积通常降 30%~50% -
-w：去掉 DWARF 调试数据（对 gdb/lldb 无效，但不影响运行） - 两者常一起用：
go build -ldflags="-s -w" main.go - 注意：
-s和-w会禁用 panic 时的源码行号，只留函数名；线上日志若依赖精确位置，得权衡
禁用 CGO 和非必要插件支持
只要没显式调用 C 代码（比如用 net 包的 DNS 解析、os/user 查用户信息），就该关掉 CGO。否则会静态链接 libc，体积暴增且破坏纯静态特性：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 编译前设环境变量：
CGO_ENABLED=0 go build -ldflags="-s -w" main.go - 检查是否真禁用了：
ldd your_binary应输出not a dynamic executable - 某些包（如
net）在 CGO 关闭后会 fallback 到纯 Go 实现（netgo），行为一致但 DNS 解析可能变慢
用 UPX 压缩（谨慎评估）
UPX 是通用可执行文件压缩器，对 Go 二进制效果明显（常压到原大小 40%~60%），但有实际限制：
立即学习“go语言免费学习笔记（深入）”；
- 不是所有平台都支持：Linux x86_64/ARM64 可靠；macOS 因签名机制基本不可用；Windows 需关闭 ASLR 才能解压运行
- 启动会慢几毫秒（解压开销），高频率短命进程（如 CLI 工具）影响明显
- 部分安全扫描工具会告警“加壳”，CI/CD 流水线或合规审查可能卡住
- 用法：
upx --best your_binary，别加--lzma（Go 二进制 LZMA 解压更慢）
真正要瘦身，优先做前三步；UPX 是锦上添花，不是必选项。很多团队卡在 CGO_ENABLED=0 和 -ldflags="-s -w" 没配对，结果白忙活半天。
