必须同时使用 -ldflags="-s -w" 才能彻底移除符号表和 dwarf 调试信息，单独用 -s 保留函数名致 panic 日志冗余，单独用 -w 在 go 1.20+ 会因依赖符号表被清空而报 linker 错误。
Go 框架项目编译出的二进制动辄 10MB+，不是你代码写得重，而是默认打包把 runtime、反射表、调试符号、libc 兼容层全塞进去了。必须用 CGO_ENABLED=0 + -ldflags="-s -w" + -trimpath 三者组合，缺一不可。
为什么 -ldflags="-s -w" 必须一起用，单独加没用
单独 -s 只删 ELF 的 .symtab 和 .strtab，panic 日志里还能看到函数名；单独 -w 在 Go 1.20+ 会直接报 linker 错误——因为 DWARF 清理依赖符号表先清空。只有合用才真正移除所有 .debug_* 段和符号表，实测减幅 30%–50%。
高频翻车点：
-
go build -ldflags=-s -w main.go：shell 把-w当成go build自己的参数，报错 -
go build -ldflags="-s" main.go：DWARF 段还在，体积几乎不掉 - 验证是否生效：
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 意外启用 - Docker 中
exec format error→ Alpine 的 musl 和 glibc ABI 不兼容 - 关掉后
net包自动 fallback 到纯 Go DNS 解析（读/etc/resolv.conf），行为一致，无兼容风险
-trimpath 不减字节，但不加会埋雷
-trimpath 本身不压缩体积，但它干掉源码绝对路径（比如 /home/user/project/cmd/app/main.go）——这些长字符串会被编译进符号表或调试段残留，间接导致体积膨胀。
更关键的是确定性构建问题：
- CI/CD 不同机器构建，没
-trimpath会导致相同代码生成不同哈希值，镜像层缓存失效 - pprof symbol 表里文件路径干净，避免调试时定位混乱
- 它不影响 panic 输出的文件名（Go 1.20+ 默认已隐藏绝对路径），但让 stack trace 更可读
UPX 压缩不是“加了就小”，要过三关才敢上
UPX 对 Go 二进制压缩率通常仅 30%–60%，而且极易翻车。别只看体积数字，运行失败就白忙活。
必须满足的条件：
- 前置条件：已用
CGO_ENABLED=0+-ldflags="-s -w"+-trimpath构建出 stripped 二进制 - 禁用 PIE：
-buildmode=exe（默认buildmode=pie会让 UPX 解包后 panic “failed to map stack”） - 避开敏感模块：含
//go:cgo_import_dynamic或大量 TLS/ASN.1 使用的程序，UPX 常报NotCompressibleException
命令示例：upx --best --lzma ./myapp；验证必须实测：./myapp --help && echo ok，不能只看 ls -lh。
容易被忽略的点：框架项目常暗引 net/http、crypto/tls、encoding/json，它们自带大量反射和 ASN.1 解析器——这时体积下降不如预期是正常的，不是参数没生效，而是 Go 运行时和标准库本身的开销无法靠链接器参数消除。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
