go get 默认修改 go.mod：新增依赖或升级至最新兼容版本；加 -u 升级直接依赖的次/补丁版，-u=patch 仅升补丁版；指定版本需用 @，如 @v1.7.0 或 @master。
Go 1.16+ 默认启用 GO111MODULE=on，go get 不再安装到 $GOPATH/src，而是直接写入当前模块的 go.mod 并下载到 $GOPATH/pkg/mod —— 混用旧 GOPATH 模式和模块模式是绝大多数“找不到包”或“版本不生效”问题的根源。
go get 会修改 go.mod 吗？什么时候加 -u？
默认行为下，go get 会自动更新 go.mod 和 go.sum：
- 运行
go get github.com/gin-gonic/gin：若该依赖未出现在go.mod中，会添加最新 tagged 版本（如v1.9.1）；若已存在，则升级到该模块的最新兼容版本（遵循go.mod中声明的主版本约束） - 加
-u（go get -u github.com/sirupsen/logrus）：强制升级该模块及其所有**直接依赖**到各自最新的次要/补丁版本（但不会跨主版本，比如不会从v1.x升到v2.x） - 加
-u=patch：只升级补丁版本（如v1.8.0 → v1.8.7），跳过次要版本变更 - 不加
-u且模块已存在时，go get实际等价于go get <module>@latest</module>，仍可能升级——它不是“只安装不更新”
如何指定安装特定版本或 commit？
版本标识必须显式写在包路径后，用 @ 分隔，否则一律解析为 @latest：
github-repo-analyzer
下载
当用户提及 GitHub URL，或要求分析、审查、探索或理解任意 GitHub 项目、仓库或代码库时，请使用此技能。触发条件包括以下短语：“分析这个项目”、“看看这个仓库”、“analyze this repo”、“what does this project do”，或消息中包含任何 github.com URL。
-
go get github.com/spf13/cobra@v1.7.0：安装确切 tagged 版本 -
go get github.com/gorilla/mux@master：安装master分支最新提交（注意：若该仓库已启用了 Go Module，master可能不对应任何go.mod声明的主版本，导致构建失败） -
go get github.com/urfave/cli@4c856a5：安装某次 commit（40 位或前 7 位 short hash 均可） -
go get github.com/hashicorp/vault@v1.15.2：带 major 版本号的模块路径需严格匹配其go.mod中定义的 module path（例如vault的 v1.x 是github.com/hashicorp/vault，v2.x 才是github.com/hashicorp/vault/v2）
为什么 go get 后代码里 still can’t import？
常见原因不是命令没执行，而是模块路径、工作目录或版本兼容性出问题：
立即学习“go语言免费学习笔记（深入）”；
- 当前目录没有
go.mod？go get在非模块环境下（GO111MODULE=off或无go.mod文件）会退化为 GOPATH 模式，但现代 Go 已弃用该路径，建议始终在模块根目录操作 - import 路径写错了？例如模块发布为
github.com/go-redis/redis/v9，就必须写import "github.com/go-redis/redis/v9"，漏掉/v9或写成/v8都会报错 - 本地有
replace覆盖？检查go.mod是否含replace github.com/some/pkg => ./local-fork，此时go get不会触碰被 replace 的条目 - 网络或代理问题导致下载了空模块？执行
go list -m all | grep somepkg看是否真出现在依赖树中；再查ls $GOPATH/pkg/mod/cache/download/github.com/some/pkg确认文件是否存在
最易被忽略的一点：go get 安装的是“模块”，不是“包”。你 import 的路径必须与模块的 module 声明完全一致，包括末尾的 /vN；而 go get 后面跟的路径，只是用来定位模块仓库的“导入路径提示”，实际解析依赖仍以模块根目录的 go.mod 为准。
