必须同时使用 -s -w 才能彻底移除符号表和 .debug_* 段，减幅30%–60%且不影响 panic；CGO_ENABLED=0 是体积下限前提，否则引入 libc 等冗余依赖；GOOS/GOARCH 和 -trimpath 需显式指定以避免交叉残留和路径膨胀；UPX 非首选，应优先优化构建链路。
go build -ldflags="-s -w" 必须一起用，不能只写一个
单独加 -s 只删 ELF 符号表（.symtab、.strtab），nm 看不到函数名，但 panic 仍能打出文件名和行号；单独加 -w 在 Go 1.20+ 会失败或静默无效——linker 要求先清符号表，否则 DWARF 段清理不干净。-s -w 合用才能彻底移除 .debug_* 段和符号表，实测减幅 30%–60%，且不影响 panic 输出。
高频错误是漏引号：go build -ldflags=-s -w main.go 中的 -w 会被 shell 当成 go build 自己的参数，直接报错。必须写成 -ldflags="-s -w"。
CGO_ENABLED=0 不是可选项，是体积下限前提
只要没显式调 C.xxx 或写 // #include，就该关 CGO。否则 linker 会悄悄拉入 libc 符号、DNS 兼容层、字符集转换代码，多占 1–2 MB。
-
ldd ./app显示依赖libc.so→ CGO 意外启用 - 关掉后，
net包自动 fallback 到纯 Go DNS 解析（读/etc/resolv.conf），行为一致，无兼容风险 - Alpine 镜像里若没关 CGO，会直接报
exec format error（musl 和 glibc ABI 不兼容）
GOOS/GOARCH 和 -trimpath 必须显式指定
不写 GOOS/GOARCH 容易在 macOS 上构建 Linux 二进制时引入交叉编译残留符号；-trimpath 本身不直接减体积，但它把源码绝对路径（如 /home/user/project/cmd/app/main.go）从符号表中剥离，避免长字符串膨胀二进制，也防止 CI/CD 中不同机器构建出哈希不一致的镜像层。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
验证是否生效：file ./app 应输出 stripped；再跑 readelf -S ./app | grep '\.debug'，结果为空才确认成功。
别碰 UPX，除非你清楚它不解决根本问题
UPX 对已用 -s -w 剥离的 Go 二进制压缩率通常只有 30%–60%，且极易翻车：
- 可能被杀软误报
- CI/CD 流水线里难审计
- 启动有微小延迟
- 签名失效、pprof 符号解析更差
真正该压的是构建链路本身：从 CGO_ENABLED=0 开始，到 -trimpath 收尾，中间穿插 -ldflags="-s -w"。UPX 是补救手段，不是默认动作。
