-s和-w必须一起用，因为单独-s仅删符号表、体积降幅有限，单独-w在go 1.20+会因符号表未清空而失败；合用才能彻底移除.debug_*段和符号表，减幅30%–50%，且不影响panic函数名输出。
为什么 -ldflags="-s -w" 必须一起用
单独加 -s 只删符号表（.symtab、.strtab），体积降得有限；单独加 -w 在 Go 1.20+ 会失败——链接器要求符号表先清空，否则 DWARF 段（.debug_*）移除不干净。二者合用才能彻底剥离无用元数据，实测减幅 30%–50%。
-
go build -ldflags="-s -w"是最基础、零副作用的裁剪动作，不影响 panic 输出函数名，但会让runtime.Caller返回???:0 - 漏引号是高频错误：
go build -ldflags=-s -w main.go中的-w被 shell 当作go build自身参数，链接器根本收不到 - 验证是否生效：
file your-binary输出含stripped；再跑readelf -S your-binary | grep '\.debug'，结果为空才算成功
CGO_ENABLED=0 不只是为 Alpine
只要没显式调用 C 函数或写 // #include，就该关 CGO。否则 linker 会悄悄拉入 libc 符号、DNS 兼容层、字符集转换代码，多占 1–2 MB。
- 现象：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）从编译产物中清空，缩短符号表里冗余字符串长度，让 -s 剥离得更干净。
- CI/CD 中不同机器构建，若没
-trimpath，相同代码生成的二进制哈希值可能不同，镜像层缓存失效 - 它不影响
panic输出的文件名（Go 1.20+ 默认已隐藏绝对路径），但能让pprof的 symbol 表更干净 - 建议始终带上，命令顺序应为：
CGO_ENABLED=0 go build -trimpath -ldflags="-s -w" -o app ./main.go
哪些优化要谨慎用
有些参数看似能压体积，但代价明显，容易踩坑：
-
-gcflags="-l"（关闭函数内联）：会让二进制变小一点，但严重拖慢启动和运行性能，GC 压力也会上升 -
upx --best：对 Go 二进制压缩率通常仅 20%–30%，且部分云环境（如 AWS Lambda）禁止执行 UPX 解包后的内存页，会直接拒绝加载 - 删
net/http/pprof或expvar：如果代码里_ "net/http/pprof"，哪怕没开 server，整套 HTTP 处理逻辑也会打进二进制 - 真正该删的是你自己写的、没用的
init()函数或全局变量初始化逻辑——它们会强制链接对应包
runtime.Caller 获取行号，-w 会让它变成 ???:0；又比如你本地调试用 delve，上线前忘了切回带调试信息的构建。这些点不显眼，但上线后才暴露。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
