Go模块代理需配置GOPROXY=https://goproxy.cn,direct才能解决timeout和版本匹配问题，direct确保私有仓库直连；go get不更新go.mod通常因不在模块根目录或GO111MODULE未启用；vendor需用-go mod=vendor显式启用。
go get 安装失败：proxy 和 GOPROXY 设置不生效
直接运行 go get github.com/sirupsen/logrus 报错 timeout 或 no matching versions，大概率是 Go 模块代理没配对。Go 1.13+ 默认启用模块代理，但国内直连 proxy.golang.org 不稳定，必须显式配置可信镜像源。
- 临时生效：运行
export GOPROXY=https://goproxy.cn,direct（Linux/macOS）或set GOPROXY=https://goproxy.cn,direct（Windows CMD） - 永久生效：执行
go env -w GOPROXY=https://goproxy.cn,direct（推荐，写入GOENV文件） -
direct是关键——它表示对私有仓库（如公司内网 Git）跳过代理，否则私有模块拉不到 - 验证是否生效：运行
go env GOPROXY，输出应为https://goproxy.cn,direct
go mod init 后 go get 不写入 go.mod？
在已有项目里执行 go get 却发现 go.mod 没更新依赖、go.sum 也没变化，说明当前目录不在模块根路径，或未启用模块模式。
- 先确认是否在模块根目录：检查是否存在
go.mod文件；若无，运行go mod init example.com/myapp（模块名建议用可解析域名，非实际 URL） - 确保环境变量
GOMODCACHE可写，且磁盘空间充足（缓存默认在$GOPATH/pkg/mod） - 避免混用
GO111MODULE=off：运行go env -w GO111MODULE=on强制开启模块支持 - 如果只想记录依赖不立即下载，用
go get -d；想同时下载并构建，去掉-d
vendor 目录失效：go build 忽略本地依赖
项目用了 go mod vendor 生成 vendor/，但执行 go build 仍去远程拉包，甚至报错说找不到 vendor/modules.txt —— 这是因为 Go 默认不自动启用 vendor 模式。
- 必须显式启用：构建时加参数
go build -mod=vendor - 验证 vendor 是否完整：运行
go mod verify，若提示校验失败，说明vendor/和go.mod不一致，需重新go mod vendor - CI/CD 中慎用 vendor：它会锁死所有间接依赖版本，升级主依赖时可能因间接依赖冲突失败，建议仅用于离线环境
-
go list -m all可查看当前解析出的全部模块版本，对比vendor/modules.txt是否一致
升级特定依赖：go get @version 语法踩坑
想把 github.com/spf13/cobra 升到 v1.8.0，运行 go get github.com/spf13/cobra@v1.8.0 后 go.mod 里版本没变，或编译报错类型不兼容——常见于语义化版本写法错误或模块路径变更。
立即学习“go语言免费学习笔记（深入）”；
- 版本号必须带
v前缀：@v1.8.0✅，@1.8.0❌（后者会被当成分支名） - 若模块已发布 v2+，路径通常含
/v2后缀，例如github.com/gorilla/mux/v2，不能漏掉/v2 - 升级后务必运行
go mod tidy清理未引用的依赖，并检查go.sum是否新增哈希行 - 升级大版本前，用
go list -u -m all查看可升级列表，再结合go doc github.com/xxx/yyy看 API 变更说明
go get github.com/sirupsen/logrus@v1.9.3 go mod tidy go list -m github.com/sirupsen/logrus依赖管理真正的麻烦点不在安装，而在版本漂移和间接依赖冲突。一个
go.mod 里看似干净的 require 行，背后可能藏着十几个间接依赖的版本博弈。每次 go get 后，别急着提交，先 go mod graph | grep xxx 看清它到底引入了哪些隐式版本。 
