go项目依赖瘦身需从依赖源头和构建产出双管齐下：查清间接依赖来源（如go mod why）、替换全家桶框架、禁用cgo、加-ldflags="-s -w"、容器使用distroless镜像并upx压缩。
Go 项目依赖体积大，通常不是因为某个包本身臃肿，而是 go.mod 里躺着一堆没被实际调用的间接依赖——它们被层层 transitive 引入，又没人主动清理。真正有效的精简，得从“依赖源头”和“构建产出”两个地方同时动手，而不是删几行 go.mod 就完事。
查清每个依赖到底是谁拉进来的
很多包看似必要，其实只是某个测试工具、旧版中间件或已弃用模块带进来的“幽灵依赖”。不查清楚就删，容易 break 构建。
- 运行
go mod why -m github.com/some/unused-package，看输出里是哪个 import 路径触发的；如果显示(main module does not need it)或来自_test.go或cmd/xxx外的废弃子目录，基本可判定为冗余 - 重点关注带
// indirect标记的依赖项——它们没被主模块直接 import，全靠别人“顺手带上”，最容易成为体积黑洞 - 用
go list -m all | grep -E "(v0\.|v9[0-9])"快速筛出版本异常（如v0.1.0或v99.0.0）的包，大概率是孤儿或 fork 分支
别让“全家桶”框架悄悄塞进 80% 你不用的功能
像 gin、echo、gorm 这类框架自带日志、配置、中间件、模板甚至 CLI 工具，但你的 HTTP 服务可能只用了路由和 JSON 解析两块。
- 用标准库替代：路由用
net/http+http.ServeMux，JSON 用encoding/json，避免引入完整 Web 框架 - 换更专注的库：比如用
sqlc生成类型安全 SQL，替代需要 runtime 反射的 ORM；用zerolog替代带 UI 和 color 输出的logrus - 检查
replace和exclude是否长期残留——它们常为临时 hack 加入，后续忘了清理，反而阻碍依赖收敛
编译时关掉 CGO 并裁剪符号表
默认开启 CGO_ENABLED=1 会让 Go 链接 libc，导致二进制依赖系统库，不仅体积涨，还破坏静态部署能力。
- 构建前设环境变量：
CGO_ENABLED=0，确保生成纯静态二进制（尤其容器场景） - 加链接器参数：
go build -ldflags="-s -w"，去掉 DWARF 符号表和调试信息，体积常降 30%–50% - 避免用
-gcflags="-l -N"关闭内联和优化——这会让未导出但未调用的函数也被打包进去
容器镜像里别留 build-time 垃圾
就算二进制只有 12MB，基础镜像选错（比如 golang:alpine 或 ubuntu:latest），最终镜像也能飙到 100MB+。
- Dockerfile 用多阶段构建，build stage 安装
upx，对最终二进制执行upx --best --lzma（注意部分安全扫描会告警） - runtime stage 用
gcr.io/distroless/static:nonroot，它不含 shell、证书、包管理器，攻击面小、体积轻（通常 -
COPY只复制构建产物和必要 config，别COPY . .或把go.mod、vendor/、测试文件一起塞进去
最易被忽略的是：go mod tidy 只清理 import 图里的“死依赖”，但不会动那些被 init() 函数或反射隐式引用的包——这类依赖得靠人工审计或工具（如 go-dep-graph）识别。体积压到极限时，这点往往卡住最后 10%。
