用途：系统性地减小 Go 编译出的二进制文件与容器镜像体积，并保证功能与可调试性不受损。核心原则是任何优化前先记录基线大小，逐项改动并测量前后差异，最后验证程序可运行、测试通过。
主要能力与步骤：
- 先测量。用 CGO_ENABLED=1 go build -trimpath -o /tmp/base ./cmd/app 建立基线，用 go tool nm -size -sort size 查看符号占用，或用 gsa --web 做包级归因；go version -m 可确认构建标志。容器或归档场景还需测 gzip 后大小。
- 剥离符号与 DWARF：go build -ldflags="-s -w" -trimpath，通常可减 25-35%。panic 与堆栈仍可用，但 dlv/gdb 无法解析源码行，建议保留未剥离副本。
- 关闭内联：加 -gcflags=all=-l，可再减 5-10%，但会损失热路径性能，需先基准测试。
- CGO 与运行时：CGO_ENABLED=0 go build -tags netgo,osusergo -ldflags="-s -w"，三者需配合；关闭 cgo 有时反而变大，须双向测量。
- 构建标签：检查 Makefile、goreleaser、Dockerfile、CI 中的 -tags，剔除不用的驱动、管理界面等可选功能。
- 依赖重量：用工具归因，常见大户包括云厂商 SDK、prometheus/client_golang、反射重的库、未使用的 protobuf 包。
- 嵌入资源：//go:embed 内容不压缩，可减少资源、预压缩或移出二进制。
- 容器镜像：多阶段构建配合 distroless/static 或 scratch，注意 scratch 缺少 CA 证书、/etc/passwd 与时区库。
- UPX 为最后手段，会拖慢启动、破坏 mmap 工具并触发杀软，仅限受限嵌入式目标并需说明理由。
适用场景：发布 CLI、容器化服务、嵌入式目标等对体积敏感的项目。限制：所有收益均需实测，不能凭直觉；剥离与关内联会牺牲调试与性能；关闭 cgo 可能增大体积；UPX 有副作用。资料未提供具体价格、平台或收费信息。