发布前必须运行go mod tidy，否则冗余依赖会被静态链接进二进制，导致体积膨胀和cve风险；它不是可选操作，而是强制前置步骤，需配合-go mod tidy -v、go list -m all过滤统计及replace锁定关键子依赖，并结合-ldflags "-s -w"压缩体积。
发布前必须运行 go mod tidy，否则冗余依赖会直接打进二进制
不执行这步就构建发布，go.mod 里残留的未使用模块（比如注释掉的 import、仅用于测试的工具库、旧版 SDK）会被静态链接进最终二进制，体积膨胀且可能引入 CVE。它不是“清理可选操作”，而是发布流水线的强制前置步骤。
-
go mod tidy只删掉既没出现在任何.go文件import列表中、也没被其他依赖传递引用的模块 - 若某个包仅靠
import _ "github.com/lib/pq"注册驱动，但代码里没实际调用 DB，tidy会删它——发布前务必确认这类副作用导入仍存在 - 搭配
go mod tidy -v查看哪些模块被移除，重点关注indirect条目是否异常减少
go list -m all 比 go mod graph 更准，但得过滤标准库和本地 replace
想确认精简效果，不能只看 go.mod 行数。真正反映构建时加载模块的是 go list -m all 输出——它包含所有解析出的模块及版本，包括间接依赖。但它的输出混着标准库（如 crypto/tls）和本地 replace 路径，直接统计会失真。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 过滤命令示例：
go list -m all | grep -v '^std$' | grep -v '=> ' | wc -l - 对比发布前后该数值，下降 15% 以上才算有效精简；若变化微小，说明冗余在传递链深层（比如某 ORM 的子依赖带了完整 HTTP 客户端）
- 发现某个
indirect模块版本跳变（如从v1.2.0升到v1.20.0），大概率是上游某依赖升级了它，需用go mod graph | grep定位源头
用 replace 锁定关键子依赖，避免隐性升级污染发布包
发布时最怕的不是多，而是“不该升的升了”。比如日志库 zerolog 的某个 indirect 依赖 golang.org/x/sys 突然从 v0.15.0 升到 v0.20.0，可能带来 syscall 行为变更。这时不能等上游修复，得在自己 go.mod 中显式锁定：
- 先查清谁引入：
go mod graph | grep 'golang.org/x/sys' - 再添加
replace golang.org/x/sys => golang.org/x/sys v0.15.0到go.mod - 注意：replace 后必须再跑一次
go mod tidy，否则go.sum不会更新校验和，CI 构建会因missing go.sum entry失败
构建参数 -ldflags "-s -w" 是发布体积压缩的底线操作
依赖精简只能解决“载入什么”，而 -ldflags "-s -w" 解决“保留什么”。前者减模块数，后者减符号表——两者叠加才能把体积压到最低。不加这个参数，二进制里会保留完整的调试符号和 DWARF 信息，体积常多出 30%~50%。
-
-s删除符号表和调试信息 -
-w跳过 DWARF 调试数据生成 - 典型构建命令：
GOOS=linux GOARCH=amd64 go build -ldflags "-s -w" -o myapp ./cmd/myapp - 注意：加了这两个 flag 后，
pprof和delve将无法工作，仅适用于生产发布包
github.com/valyala/fastjson 和 encoding/json，即使只用其中一个，链接器也不会自动剔除另一个——它们被当作独立符号处理。这种冗余只能靠人工审查 go list -deps 输出，或用 go tool objdump -s "main\." myapp 看实际引用的函数来源。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
