go get安装失败主因是GOPROXY未配置或模块模式未启用，需确保go.mod存在、用完整模块路径安装、设置代理，并注意import路径与包名无关、vendor需手动更新、升级时需适配API变更。
go get 安装失败：找不到模块或版本冲突
多数情况下不是网络问题，而是 GOPROXY 或 Go 模块模式没启用。确认项目根目录下有 go.mod 文件；如果没有，先运行 go mod init your-module-name。再执行安装命令时，务必用完整模块路径，比如安装 github.com/spf13/cobra，应运行：
go get github.com/spf13/cobra@v1.8.0
不带 @version 可能拉取最新 commit（非 tag），导致行为不稳定。国内用户需设置代理：
go env -w GOPROXY=https://proxy.golang.org,direct
或更稳妥的国内镜像：
go env -w GOPROXY=https://goproxy.cn,direct
注意：GO111MODULE=on 必须开启（Go 1.16+ 默认开启，旧版本需手动设）。
立即学习“go语言免费学习笔记（深入）”；
import 路径与实际包名不一致
Go 的 import 路径是模块 URL，不是本地文件夹名，也不等于包名（package name）。例如：
import "github.com/go-sql-driver/mysql"
但代码中使用的是 mysql 这个包名：
CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。
db, _ := sql.Open("mysql", dsn)
常见误区：
- 误以为 import 路径末尾必须和
package xxx一致 —— 实际完全无关 - 把
github.com/user/repo/sub当成子模块，其实只是路径分段，是否可单独 import 取决于该路径下是否有go.mod和导出的包 - 用错包名调用函数，如写成
github_com_go_sql_driver_mysql.Open—— Go 不支持这种写法，必须用声明的包别名或默认包名
vendor 目录失效或未更新
启用 vendor 后，go build 默认只读 vendor，但 go get 不会自动同步到 vendor。需要显式执行：
go mod vendor
且注意以下几点：
- 每次
go mod tidy或go get后，vendor 内容可能过期，必须重跑go mod vendor - CI/CD 中若用
-mod=vendor构建，但本地没生成 vendor，会直接报错cannot find module providing package - vendor 不包含测试依赖（
require ... // indirect中带// indirect的条目通常不会进 vendor），如有 test-only 包，需手动go get -u并go mod vendor
升级第三方包时 panic：API 不兼容或类型变更
Go 没有语义化版本强制约束，很多库主版本升级（如 v1 → v2）会改 import 路径，比如：
import "gopkg.in/yaml.v2" → "gopkg.in/yaml.v3"
这类变更不会被 go get -u 自动处理，必须手动改 import 语句并适配接口。典型表现：
-
yaml.Unmarshal返回值从(error)变成([]byte, error) - 结构体字段 tag 名称变化（如
json:"foo"改为yaml:"foo"） - 函数签名增加上下文参数（
context.Context）
建议在 go.mod 中锁定小版本（如 github.com/gorilla/mux v1.8.0），避免意外升级。检查变更最直接的方式是看对应 tag 的 CHANGELOG.md 或比对两个版本的 go list -f '{{.Exports}}' <pkg> 输出。
第三方包的真正难点不在安装，而在理解它如何与你的模块边界交互——尤其是跨 major 版本时 import 路径变、类型不兼容、甚至构建约束（// +build）失效，这些都得一行行核对。
