go get不写入go.mod需先确认在模块根目录且GO111MODULE=on；国内需配置GOPROXY=https://goproxy.cn,direct；vendor须用-go mod=vendor启用；版本指定须匹配路径与语义化格式。
go get 不写入 go.mod？先确认模块根目录和 GO111MODULE 状态
执行 go get github.com/sirupsen/logrus 却发现 go.mod 没更新、go.sum 也没生成，大概率不是命令错了，而是当前目录根本不在 Go 模块范围内。
- 运行
ls -la（macOS/Linux）或dir（Windows）检查当前目录是否存在go.mod文件；没有就不是模块根目录 - 若无
go.mod，先运行go mod init example.com/myapp（模块名建议用可解析域名，非实际 URL） - 检查模块模式是否启用：运行
go env GO111MODULE，输出应为on；若为off或空，执行go env -w GO111MODULE=on - 避免在
$GOPATH/src下新建项目——Go Modules 默认忽略该路径，会退化为 GOPATH 模式
go get @version 语法失效？版本格式和模块路径必须匹配
想升级 github.com/spf13/cobra 到 v1.8.0，运行 go get github.com/spf13/cobra@v1.8.0 后 go.mod 未变更，常见于语义化版本写法错误或模块路径变更。
- 确保版本前缀是
v（如@v1.8.0），不是@1.8.0或@release/v1.8.0 - 某些库主版本 ≥ v2 时，模块路径已变（如
github.com/gorilla/mux/v2），直接@v2.0.0会失败，必须改 import 路径并用新路径go get - 若依赖被其他包间接引入且版本冲突，
go get可能静默降级；此时用go mod graph | grep cobra查来源，再配合go mod edit -require强制指定 - 执行后务必跑一次
go mod tidy，它会清理未用依赖、补全缺失项，并校验go.sum
国内环境 go get 总 timeout？GOPROXY 必须带 direct
直接运行 go get 报 timeout 或 no matching versions，基本是代理配置不完整。Go 1.13+ 默认启用模块代理，但 proxy.golang.org 在国内不稳定，仅设镜像不够。
- 临时生效（当前终端）：
Linux/macOS：运行export GOPROXY=https://goproxy.cn,direct
Windows CMD：运行set GOPROXY=https://goproxy.cn,direct - 永久生效（推荐）：运行
go env -w GOPROXY=https://goproxy.cn,direct，写入GOENV文件 -
direct是关键——它表示对私有仓库（如gitlab.example.com/internal/lib）跳过代理直连；漏掉会导致公司内网模块拉不到 - 验证是否生效：运行
go env GOPROXY，输出必须是https://goproxy.cn,direct，不能只有https://goproxy.cn
vendor 目录生成了但 build 还报错找不到包？-mod=vendor 必须显式加
执行 go mod vendor 生成了 vendor/ 目录，但 go build 仍去远程拉包，甚至提示 vendor/modules.txt: no such file，说明 Go 默认根本不读 vendor。
立即学习“go语言免费学习笔记（深入）”；
- 构建时必须显式启用 vendor 模式：
go build -mod=vendor（注意是-mod=vendor，不是--mod=vendor） - 验证 vendor 完整性：运行
go mod verify，若报校验失败，说明vendor/和go.mod不一致，需重新go mod vendor - CI/CD 中慎用 vendor：它锁死所有间接依赖版本，升级主依赖时可能因间接依赖冲突失败；仅推荐用于离线环境或强审计要求场景
- 检查
vendor/modules.txt是否存在且非空——它是go mod vendor自动生成的依赖清单，缺失说明生成过程异常
真正容易被忽略的是 direct 在 GOPROXY 中的作用，以及 -mod=vendor 必须显式传给构建命令这两点。没配 direct，私有模块永远拉不下来；不加 -mod=vendor，vendor 目录就是个摆设。
