Go二进制体积大是因默认打包runtime、反射表、调试符号及libc（若CGO启用），空main可达2.1MB；必须用-ldflags="-s -w"组合清除符号表和DWARF段，配合CGO_ENABLED=0和-trimpath才能安全压缩30%–50%，并避免ABI兼容与镜像缓存问题。
Go 编译出的二进制文件大，不是你写错了，而是默认把 runtime、反射表、调试符号、甚至 libc（如果 CGO 开启）全塞进去了。一个空 main 函数在 Linux 下也能到 2.1 MB，这不是 bug，但上线前必须压。
为什么 -ldflags="-s -w" 必须一起用
单独用 -s 只删符号表（.symtab、.strtab），nm 看不到函数名，但 panic 还能打出来；单独用 -w 在 Go 1.20+ 会失败——linker 要求先清空符号表，否则 DWARF 段清理不干净。
-s -w 合用才能彻底移除 .debug_* 段和符号表，实测减幅 30%–50%，且不影响运行时 panic 输出。
- 漏引号是高频错误：
go build -ldflags=-s -w main.go中的-w会被 shell 当成go build自己的参数，直接报错 - 验证是否生效：
file ./app应输出stripped；再跑readelf -S ./app | grep '\.debug'，结果为空才确认成功
CGO_ENABLED=0 是体积压缩的前提，不是可选项
只要没显式调 C.xxx 或写 // #include，就该关 CGO。否则 linker 会悄悄拉入 libc 符号、getaddrinfo 兼容层、字符集转换代码，多占 1–2 MB。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
现象：ldd ./app 显示依赖 libc.so → CGO 意外启用；关掉后，net 包自动 fallback 到纯 Go DNS 解析（读 /etc/resolv.conf），行为一致，无兼容风险。
- Alpine 镜像里若没关 CGO，会直接报
exec format error—— musl 和 glibc ABI 不兼容 - 本地 macOS 编译出的二进制若
ldd报错，说明它根本不是动态链接目标，此时应改用otool -L查看依赖
构建命令顺序不能乱：从 CGO_ENABLED=0 开始，到 -trimpath 收尾
推荐完整命令：
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -trimpath -ldflags="-s -w" -o app ./main.go
-trimpath 本身不减体积，但它干掉源码绝对路径（比如 /home/user/project/cmd/app/main.go），避免这些长字符串被编译进符号表或调试段残留，间接防止体积意外膨胀。
- CI/CD 中不同机器构建，若没
-trimpath，相同代码生成的二进制哈希值可能不同，镜像层缓存失效 - 它不影响 panic 输出的文件名（Go 1.20+ 默认已隐藏绝对路径），但能让
pprof的 symbol 表更干净 - 不要省略
GOOS/GOARCH：不显式指定会导致交叉编译残留，尤其在 macOS 上构建 Linux 二进制时容易引入额外符号
别碰 UPX，除非你过了这三关
UPX 对 Go 二进制压缩率通常只有 30%–60%，而且极易翻车。不是“加了就小”，而是“过了这几关才敢上”：
- 第一关：必须是
CGO_ENABLED=0+-ldflags="-s -w"+-buildmode=exe（禁用 PIE），否则 UPX 解包后大概率segmentation fault - 第二关：确认你的程序没用
runtime/debug.ReadBuildInfo或任何依赖构建 ID 的逻辑（-buildid=会破坏它） - 第三关：CI/CD 流水线里要审计 UPX 版本和签名，部分安全扫描工具会将 UPX 压缩体标记为可疑
真正该优先做的，是检查 .dockerignore 是否漏掉了 testdata/、node_modules/ 或 vendor/ —— 构建上下文变大，会让 builder 阶段 COPY 时一并拖进去，最终镜像多出几十 MB，比所有编译参数加起来影响都大。
