Go项目瘦身需从依赖来源和编译产出双管齐下：优先标准库、查清依赖来源、替换“全家桶”框架；执行go mod tidy清理冗余依赖；编译时禁用CGO、加-ldflags="-s -w"，容器用distroless镜像并UPX压缩。
Go 项目依赖体积大，通常不是因为单个包太大，而是层层嵌套引入了大量未使用的间接依赖。真正有效的瘦身，得从“依赖来源”和“编译产出”两个层面同时下手，而不是只盯着 go.mod 删几行。
精简依赖引入源头
很多体积膨胀，源于一开始选错了库。
- 优先用标准库：比如路由用
net/http+ 简单ServeMux，别一上来就拉gin或echo；JSON 解析直接用encoding/json，不用功能重叠的第三方序列化库。 - 查清每个依赖为何存在：运行
go mod why 包名，看它是被谁间接拉进来的。如果输出显示是某个已弃用模块或测试工具引入的，就该考虑替换或隔离。 - 警惕“全家桶”框架：某些 ORM 或 Web 框架自带日志、配置、中间件等，但你可能只用了其中 20%。换成更专注的库（如
sqlc替代全功能 ORM，zerolog替代带 UI 的日志库），能显著减少隐式依赖。
清理未使用和过时依赖
go.mod 里躺着的不等于当前项目真在用的。
Json Schema Toolkit
下载
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
- 定期执行
go mod tidy，它会删掉go.mod中未被引用的模块，并补全缺失依赖。建议在 CI 中加go mod tidy -check防止误提交冗余项。 - 用
go list -m all查看完整依赖树，重点关注版本号异常高或明显偏离主干（如 v0.x 或 v99.0.0）的包，它们常是孤儿依赖或已被弃用。 - 手动检查
replace和exclude语句——它们有时为临时修复引入，却长期残留，反而阻碍模块更新和清理。
编译阶段剔除无用代码
Go 编译器默认会做函数内联和死代码消除，但前提是代码确实没被调用。
- 确保
CGO_ENABLED=0编译纯静态二进制（尤其容器部署），避免引入 libc 相关依赖。 - 启用构建裁剪标志：
go build -ldflags="-s -w"，去掉符号表和调试信息，体积通常减少 20%–30%。 - 如果项目含未导出但未调用的函数（如
pkga.Bar()从未被任何地方调用），Go 1.22+ 默认不会打包进去——无需额外工具，但要确认没用-gcflags="-l -N"关闭优化。
容器镜像再压缩（上线前最后一道关）
即使二进制够小，基础镜像选错，体积照样翻倍。
- 用
gcr.io/distroless/static:nonroot这类 distroless 镜像作 base，不含 shell、包管理器、证书等，攻击面小、体积轻。 - 多阶段构建中，在中间 stage 安装
upx，对最终二进制执行upx --best --lzma压缩（注意：部分安全扫描工具会对 UPX 打包的二进制报可疑，需提前评估）。 - 避免把整个
./COPY 进镜像，只 COPY 构建产物和必要配置，不带源码、测试文件、go.mod等无关内容。
基本上就这些。不复杂但容易忽略——关键在养成定期审查的习惯，而不是等发布前才紧急“砍包”。
