go build -mod=vendor 仍联网是因为未满足三个前提：必须显式加该参数、在module根目录执行、且所有依赖的go.mod和go.sum需完整匹配，否则Go会回源验证。
CI 中 Go 构建慢、体积大、偶发失败，八成不是代码问题，而是依赖管理没对齐构建上下文。
go build -mod=vendor 为什么还在联网
vendor 目录本身不改变模块解析逻辑，Go 仍会按需回退到网络拉取——关键在三个执行前提是否满足：
- 构建命令必须显式加
-mod=vendor，只运行go mod vendor不生效 - 必须在含
go.mod的 module 根目录下执行go build，否则忽略 vendor - 检查
go build -mod=vendor -x输出：若出现git fetch或GET https://，说明某依赖的go.mod文件缺失或校验失败（go.sum不匹配），Go 强制回源验证
go list -m all 显示太多 indirect 模块怎么办
这不是冗余，是 Go 模块机制如实反映实际引用路径。但大量 // indirect 条目会掩盖真正该管的依赖：
- 用
go mod graph | grep 'xxx/pkg'查清谁引入了它，比盲目删indirect更可靠 - 若某
indirect版本异常高（如v1.20.0），说明上游已升级，而你没约束——这正是隐性行为变更的源头 - 执行
go mod tidy可清理未被任何import触达的残留indirect，但别指望它自动收敛版本
如何锁定子依赖版本而不污染上游
不能靠在自己 go.mod 里 require 子依赖来“覆盖”，那只是增加一层间接引用。必须用 replace 或 exclude 控制解析结果：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 临时调试可用
replace golang.org/x/net => golang.org/x/net v0.17.0，但 CI 环境要慎用本地路径替换 - 阻止已知有 bug 的版本被选中，用
exclude golang.org/x/net v0.14.0 - 改完立刻跑
go build -a -v验证是否真生效；光看go list -m all容易误判
构建体积和耗时优化的关键不在“删包”，而在链接期
Go 的依赖去重发生在链接阶段，不是编译阶段。多版本共存不会让源码变多，但会让最终二进制膨胀：
-
go build -ldflags="-s -w"是最简单有效的体积压缩手段，能减小 30%–50% - 符号去重由链接器自动完成，无需手动干预；但前提是各依赖用的是同一份符号定义（即版本收敛后）
- 定期用
go list -m all | grep xxx检查重复引入，再配合go mod graph追路径，比只盯go.mod更准
真正难的不是命令怎么敲，而是某个 indirect 模块悄悄升级后，接口行为变了（比如日志库加了默认 trace 字段），而你的测试完全没覆盖那个路径。
