-ldflags="-s -w" 必须与 cgo_enabled=0 配合使用才能有效瘦身，单独用 -s 仅删符号表、-w 在 go 1.20+ 会静默失败；合用才彻底清除符号表和所有调试段，减幅达30%–50%，且 panic 输出不受影响。
-ldflags="-s -w" 必须和 CGO_ENABLED=0 一起用，单独加任何一项都白忙——前者只删符号表或只删调试段，后者不关就会悄悄链接 libc，多出 2–5 MB。
为什么 -ldflags="-s -w" 必须配对使用
单独用 -s 只清掉 .symtab 和 .strtab 段，nm 看不到函数名，但 .debug_* 段还在，体积只减 10%–20%；单独用 -w 在 Go 1.20+ 会静默失败或报错，因为 linker 要求先清符号路径依赖才能安全移除 DWARF 数据。
-
-s -w合用才真正删光符号表 + 所有.debug_*段，实测对含 HTTP/gRPC 的微服务可减 30%–50%（如 14.2 MB → 7.8 MB） -
panic输出不受影响——runtime 保留必要函数名，但delve、gdb、pprof符号解析会失效 - Windows 上
-w不生效，只靠-s减幅有限，别指望单靠它瘦身 - 漏引号是高频错误：
go build -ldflags=-s -w main.go中的-w会被 shell 当成go build自己的参数，直接报错
CGO_ENABLED=0 不是“可选”，是体积下限关键
只要没写 C.xxx 或 // #include，就该关 CGO。否则 net、os/user 等包在某些系统上会 fallback 到 cgo，隐式链接 libc，体积膨胀且破坏 Alpine 兼容性。
- 现象：本地编译出的二进制运行
ldd ./app显示依赖libc.so→ CGO 意外启用 - 关掉后，
net包自动走纯 Go DNS 解析（读/etc/resolv.conf），行为一致，无兼容风险 - 验证是否生效：
ldd ./service输出not a dynamic executable才算成功 -
GODEBUG=netdns=go可强制 DNS 走纯 Go 实现，避免关 CGO 后连不上 HTTPS（极少数场景需显式设）
-trimpath 不减体积，但不加会埋坑
-trimpath 把源码绝对路径（如 /home/user/go/src/github.com/myorg/service）替换成空字符串，缩短符号表里冗余字符串长度——这让 -s 剥离得更干净，间接提升瘦身效果。
- 更重要的是构建确定性：不同 CI 节点、不同用户目录下构建出的二进制哈希值一致，Docker 层缓存和镜像签名才可靠
- 它不影响
panic输出（Go 1.20+ 默认已隐藏绝对路径），但能防止静态分析工具因路径差异误判 - 建议始终启用：
CGO_ENABLED=0 go build -trimpath -ldflags="-s -w" -o service .
UPX 压缩要过三关，否则运行即崩
UPX 对 Go 二进制压缩率通常只有 30%–60%，而且极易翻车。不是“加了就小”，而是“过了这几关才敢上”。
- 第一关：必须是
CGO_ENABLED=0+-ldflags="-s -w"+-buildmode=exe（禁用 PIE），否则解包后大概率segmentation fault - 第二关：别对
go test -c产物或含//go:cgo_import_dynamic的程序用 UPX，失败率极高 - 第三关：压缩后必须实测运行，
./app -h能跑通才算数，不能只看文件大小 -
upx --best --lzma ./app比默认算法稍好一点，但云环境（如 AWS Lambda）可能拒绝加载解包后的内存页
真正容易被忽略的点是：-trimpath 看似无关紧要，但它让 -s 剥离更彻底，同时保障构建可重现——CI/CD 流水线里一旦缺失，相同代码在不同机器上产出的二进制哈希值不同，镜像层缓存全废。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
