go mod vendor 不减小二进制体积，因为 vendor 仅复制源码、不控制链接裁剪；真正影响体积的是实际 import 的包及是否启用 -ldflags="-s -w"、CGO_ENABLED=0 等编译优化。
为什么 go mod vendor 后二进制体积没变小？
直接执行 go mod vendor 不会减小最终编译出的二进制大小。vendor 只是把依赖源码复制到本地，go build 依然会全量编译所有被 import 的包（包括未使用的符号），而 Go 的链接器默认不裁剪未引用的代码。
- vendor 是为构建可重现性服务的，不是为瘦身设计的
- 真正影响二进制大小的是：哪些包被实际链接进可执行文件，以及是否启用符号/调试信息裁剪
- 常见误操作：以为删掉
vendor/或改用replace就能缩小体积——其实只要 import 语句存在，相关包就可能被拉入
如何让 go build 排除未使用的依赖？
Go 本身没有“tree-shaking”机制，但可通过控制 import 路径和构建 tag 实现逻辑上排除无关代码。关键点在于：避免隐式导入、拆分模块职责、用构建约束隔离平台/功能代码。
- 检查
go list -f '{{.Deps}}' .输出，确认是否有意外引入的重型依赖（比如golang.org/x/sys被间接拉入） - 把非核心功能（如 Prometheus metrics、pprof、debug handlers）用
//go:build debug包裹，并在生产构建时加-tags=prod - 慎用通配符导入：
_ "net/http/pprof"会强制链接整个 pprof，改用按需注册方式（如只在需要时调用pprof.Register()） - 第三方库若提供 “lite” 子模块（如
github.com/golang/protobuf/proto lite），优先使用其轻量路径而非主包
哪些 build 参数能真实压缩二进制？
go build 的几个关键参数对体积影响显著，但效果取决于代码结构和依赖特性，不是简单叠加就有用。
-
-ldflags="-s -w"：去掉符号表和 DWARF 调试信息，通常能减少 30%~50% 体积（-s删除符号表，-w禁用 DWARF） -
-trimpath：清除编译路径信息，避免把本地 GOPATH 或 module 路径写进二进制（尤其影响 strip 后效果） -
-buildmode=pie：生成位置无关可执行文件，但会略微增大体积，仅在安全合规场景启用 - 注意：
-gcflags="-l"（禁用内联）反而可能增大体积，除非用于调试符号定位，否则不推荐
依赖替换和最小化导入的实际操作
很多体积问题根源是依赖链中某个包悄悄引入了标准库外的重型组件（比如 encoding/json 没问题，但某些 ORM 会带入 database/sql + 驱动 + context + sync/atomic 大量间接依赖）。
立即学习“go语言免费学习笔记（深入）”；
- 用
go mod graph | grep xxx追踪某包是如何被引入的，再决定是否用replace替换为更轻的实现（例如用github.com/tidwall/gjson替代完整encoding/json+ struct 解析） - 避免在
main包里 import 工具类包（如github.com/spf13/cobra的子命令如果不用，就不要 import 对应文件） - 检查
go.sum中是否存在重复版本的同一模块（不同版本会被同时保留），用go mod tidy清理冗余项 - 交叉编译时指定目标平台（如
GOOS=linux GOARCH=amd64）可避免嵌入其他平台的 syscall 表，比默认构建略小
最易被忽略的是：即使你没写 import，某些库内部用了 init() 函数或全局变量初始化，也会触发整个包链接。这类依赖必须从源头规避，而不是靠 build 参数硬压。
