Go二进制体积大90%源于冗余依赖和未裁剪编译，核心优化是：先用go list -m all排查漏网依赖，再设CGO_ENABLED=0禁用libc链接，最后加-ldflags="-s -w"剥离符号与调试信息。
Go 二进制体积大，90%不是代码本身的问题，而是依赖没管住、编译没裁剪。 直接上手段比分析原因更有效——先砍掉冗余依赖，再压缩构建产出，最后确认是否真被用了。
go mod tidy 为什么没清掉那些包？
它只删 go.mod 中「未被 import 语句引用」的模块，但不检查你是否在运行时反射加载、或通过字符串拼接调用（比如插件式日志后端、ORM 的驱动注册）。常见漏网之鱼：
- 测试专用依赖（如
github.com/stretchr/testify）被// +build test或_test.go引入，但主模块仍保留其 require 条目 - CI 脚本里执行了
go get安装工具（如golangci-lint），结果误写进go.mod -
replace指向本地路径但对应目录已删除，go mod tidy不报错也不清理
实操建议：运行 go list -m all | grep -v 'standard\|main' 手动扫一遍，对版本号异常（如 v0.0.0-2020...）、包名含 tools / cmd / example 的条目重点查 go mod why。
CGO_ENABLED=0 不是万能，但必须关
默认开启 CGO 会让 Go 链接器悄悄拉入 libc、libpthread 等系统库，导致二进制无法跨 CentOS 版本运行，且体积多出 2–5MB。尤其在容器部署时，这个开关决定你用不用 distroless 镜像。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 设环境变量：
CGO_ENABLED=0再执行go build - 若项目真用到了
cgo（如调用 SQLite C API），必须显式声明#cgo LDFLAGS: -lsqlite3并确保目标系统有对应 .so；否则直接报undefined reference to sqlite3_* - 某些包（如
net包的 DNS 解析）在 CGO 关闭时会 fallback 到纯 Go 实现，行为略有差异（比如不读/etc/resolv.conf的 search 域）
-ldflags="-s -w" 为什么有时只减 10%？
这两个标志分别移除符号表（-s）和调试信息（-w），对小项目效果明显，但大项目体积主要来自重复的函数体和未裁剪的依赖代码。此时需确认：
- 是否启用了 Go 1.22+ 的默认死代码消除？旧版本需加
-gcflags="-trimpath"辅助 -
go list -f '{{.Deps}}' .输出中是否存在大量重复模块（如golang.org/x/sys出现 5 次不同版本）？这时得靠replace统一 - 是否误用了
go:embed嵌入了未压缩的前端资源（如整个web/dist）？这类内容不会被-s -w影响
go mod vendor 已过时，但某些场景还得用
官方不推荐，但在两类场景下仍是刚需：
- 离线构建环境（如军工、金融内网），没有 GOPROXY，又不允许镜像带完整
go.sum校验链 - 审计要求「所有源码可追溯」，vendor 目录能直接提供每个依赖的 commit hash 和 patch 内容
注意：启用后必须加 -mod=vendor 构建，否则 Go 仍会尝试联网解析 module path；且 go mod vendor 不会自动更新 vendor/ 下子模块的 go.mod，需手动同步或脚本校验。
真正卡体积的从来不是单个包大小，而是依赖图里那些「谁都在用、但没人敢动」的间接依赖——它们藏在 go.sum 最底下几行，版本号飘忽，go mod why 输出一堆箭头。盯住这些，比反复调 -ldflags 有用得多。
