go二进制体积大是默认行为，生产构建必须用cgo_enabled=0、-trimpath、-ldflags="-s -w"（二者缺一不可），upx需配合-buildmode=exe才安全。
Go 编译出的二进制体积大，不是配置错了，而是默认行为：它把 runtime、反射表、调试符号、甚至 libc（如果 CGO 开启）全塞进去了。一个空 main 函数在 Linux 下也能到 2MB+，这不是 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 不只是为 Alpine，更是为体积
只要没显式调 C.xxx 或写 // #include，就该关 CGO。否则 linker 会悄悄拉入 libc 符号、getaddrinfo 兼容层、字符集转换代码，多占 1–2MB。
- 现象：本地 macOS 编译出的二进制
ldd ./app显示依赖libc.so→ CGO 意外启用 - 关掉后，
net包自动 fallback 到纯 Go DNS 解析（读/etc/resolv.conf），行为一致，无兼容风险 - Alpine 镜像里若没关 CGO，会直接报
exec format error——musl 和 glibc ABI 不兼容
-trimpath 不减体积，但不加会埋坑
-trimpath 本身不压缩字节，但它干掉源码绝对路径（比如 /home/user/project/cmd/app/main.go），避免这些长字符串被编译进符号表或调试段残留，间接防止体积意外膨胀。
- CI/CD 中不同机器构建，若没
-trimpath，相同代码生成的二进制哈希值可能不同，镜像层缓存失效 - 它不影响
panic输出的文件名（Go 1.20+ 默认已隐藏绝对路径），但能让pprof的 symbol 表更干净 - 建议始终带上：命令顺序应为
CGO_ENABLED=0 go build -trimpath -ldflags="-s -w" -o app ./main.go
UPX 压缩要过三关，否则白忙活
UPX 对 Go 二进制压缩率通常只有 30%–60%，而且极易翻车。不是“加了就小”，而是“过了这几关才敢上”。
- 第一关：必须是
CGO_ENABLED=0+-ldflags="-s -w"+-buildmode=exe（禁用 PIE），否则 UPX 解包后大概率segmentation fault - 第二关：别对
go test -c产物或含//go:cgo_import_dynamic的程序用 UPX，失败率极高 - 第三关：压缩后必须实测运行，
./app --help成功不等于正常——某些 TLS 初始化逻辑在 UPX 解压后内存布局偏移，首次 HTTP 请求才暴露问题
真正难优化的点不在参数，而在依赖本身：用了 crypto/tls 或 net/http，哪怕参数全对，体积也难低于 4MB，因为 ASN.1 解析器、证书验证链、HTTP/2 状态机这些是硬代码。这时候与其硬压，不如检查有没有误引 golang.org/x/net/proxy 或 database/sql 这类带重型 init 的包——它们会强制链接整套驱动栈。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
