17370845950

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 里版本没变，或编译报错类型不兼容——常见于语义化版本写法错误或模块路径变更。

• 版本号必须带 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 看清它到底引入了哪些隐式版本。