确认二进制内容需用 file 检查是否静态链接，再用 go tool nm 查符号大小；必须同时加 -ldflags="-s -w" 删除符号表和 DWARF 信息；关闭 CGO 可显著减体积，UPX 压缩效果有限且有兼容风险。
怎么确认二进制里到底塞了什么
直接看文件大小没用，得拆开看符号和依赖。先用 file ./app 确认是否静态链接——输出含 statically linked 才算干净；如果出现 dynamic 或列出 libc.so，说明 CGO_ENABLED=1 意外生效了。
再跑 go tool nm -size -sort size ./app | head -20，能按大小倒序列出前 20 个符号（函数/变量），常会暴露“谁偷偷占了最多空间”。比如看到大量 encoding/json.* 或 net/http.*，就该查代码里有没有没删的 _ "net/http/pprof" 或冗余的 JSON 序列化逻辑。
常见误判点：以为 go mod vendor 能减体积——其实它只影响构建过程，不改变最终二进制内容；真正起作用的是编译时实际引用的代码路径。
必须同时用 -s 和 -w，缺一不可
-ldflags="-s -w" 是最基础、最有效的体积削减手段，但很多人只写一个参数。
立即学习“go语言免费学习笔记（深入）”；
-
-s删除符号表（symbol table），去掉函数名、变量名等可读信息 -
-w删除 DWARF 调试信息（调试行号、源码路径、变量类型等） - 单独用
-w在 Go 1.20+ 会失败，报错类似cannot remove DWARF info: symbol table still present，因为符号表还在，DWARF 移除被拦截 - 命令要写成完整形式：
go build -ldflags="-s -w" -o app main.go，不能拆成两个-ldflags
关掉 CGO 是体积跳变的关键一步
本地 macOS 编译出 12MB，扔进 Alpine 容器里 ldd ./app 却显示依赖 libc.so？这就是 CGO_ENABLED=1 在背后悄悄干活——哪怕你一行 C 代码都没写。
只要没显式调用 C.xxx 或 import "C"，就该强制关闭：
- 编译前设环境变量：
CGO_ENABLED=0 go build -ldflags="-s -w" -o app main.go - 效果立竿见影：通常砍掉 1–2MB，尤其在 Alpine 镜像中避免 musl libc 静态膨胀
- 注意副作用：关掉后
net包走纯 Go DNS 解析（默认行为），不影响功能；但若用了os/user查系统用户，可能返回空或错误（需改用第三方纯 Go 实现）
UPX 压缩不是银弹，慎用
UPX 对 Go 二进制压缩率低（20%–30%），且有兼容性风险。
先确认已用 CGO_ENABLED=0 和 -ldflags="-s -w" 优化过，再试：
- 命令：
upx --best --lzma ./app（--lzma比默认稍好） - 必须验证能否运行：
./app --help，不能只看压缩后大小 - 某些场景会失败：启用
-buildmode=pie、或代码里用了syscall.Syscall等底层 TLS 相关调用时，UPX 可能报NotCompressibleException - AWS Lambda、Kubernetes 容器运行时等环境可能拒绝加载 UPX 解包后的内存页，直接 crash
真正省体积的起点永远是代码本身：删掉没用的 import，尤其警惕带 init 函数的包（比如 _ "expvar"、_ "net/http/pprof"），它们哪怕没调用也会把整套逻辑打进二进制。
