最有效方法是同时使用 -ldflags="-s -w" 和 CGO_ENABLED=0：-s 删除符号表，-w 删除 DWARF 调试信息，二者缺一不可；CGO_ENABLED=0 避免静态链接 libc，可减少 1–2MB 体积。
用 -ldflags 去掉调试信息最有效
Go 默认编译出的二进制包含完整 DWARF 调试符号，占体积大且生产环境完全不需要。直接加 -ldflags="-s -w" 就能砍掉 30%–50%：其中 -s 删除符号表，-w 删除 DWARF 信息。
常见错误是只写 -s 或只写 -w，两者必须一起用才彻底；单独用 -w 在较新 Go 版本（1.20+）可能报错，因为符号表还存在，DWARF 移除失败。
go build -ldflags="-s -w" main.go- 交叉编译时同样生效：
GOOS=linux GOARCH=amd64 go build -ldflags="-s -w" main.go - 如果用了
go install，需加-ldflags到命令末尾，不能放在-buildvcs=false之类参数中间
关闭 CGO 可避免链接 libc 带来的膨胀
只要代码里没显式调 C.xxx 或 import "C"，就该关掉 CGO。否则默认会静态链接 libc 相关符号（尤其在 Alpine 上用 musl），体积多出 1–2MB。
典型现象是：本地 macOS 编译出来 12MB，丢到 Docker 里跑 ldd ./app 却显示依赖 libc.so —— 这说明 CGO 意外启用了。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 编译前设环境变量：
CGO_ENABLED=0 go build -ldflags="-s -w" main.go - 检查是否生效：用
file ./app看输出是否含statically linked - 若项目依赖了
net包（如用 DNS 解析），关 CGO 后默认走纯 Go DNS 解析，行为一致但不依赖系统库
用 UPX 压缩对 Go 二进制效果有限但可尝试
UPX 对 Go 的压缩率通常只有 20%–30%，远不如对 C/C++ 二进制显著，而且部分云环境（如 AWS Lambda、某些容器运行时）禁止执行 UPX 解包后的内存页，会直接拒绝加载。
不是所有 Go 二进制都能被 UPX 正常压缩：启用 -buildmode=pie 或使用了某些 TLS/加密相关 syscall 的程序，UPX 可能报 NotCompressibleException。
- 先确认基础体积已用
-ldflags和CGO_ENABLED=0优化过，再考虑 UPX - 压缩命令：
upx --best --lzma ./app（--lzma比默认算法稍好一点） - 验证能否运行：
./app --help，别只看压缩完大小
模块依赖太多时，go mod vendor 反而可能增大体积
vendor 不影响编译后体积，但容易让人误以为“把依赖收进来就能控制”，其实 Go 编译器只打包实际引用的代码。真正要减体积，得从源头删掉没用的 import，尤其是那些带 init 函数或隐式注册的模块（比如某些日志、metrics、pprof 包）。
一个常见坑：写了 _ "net/http/pprof"，哪怕没开 pprof server，也会把整套 HTTP 处理逻辑和模板引擎打进二进制。
- 用
go list -f '{{.Deps}}' . | tr ' ' '\n' | sort -u查看真实依赖树 - 搜索代码里所有
import _行，逐个判断是否必要 - 用
go tool compile -S main.go 2>&1 | grep -E "(CALL|TEXT.*runtime|TEXT.*reflect)"粗略看哪些底层包被实际引入
真正起效的永远是那几行 -ldflags 和 CGO_ENABLED=0，其他手段要么收益低，要么引入新风险。别在 UPX 或 vendor 上花太多时间，优先确保这两项稳稳落地。
