Go Mod 是 Go 1.11+ 默认且必须的依赖管理方式，初始化需用 go mod init 指定唯一模块路径，go get 要指定版本避免语义化版本错误，go.sum 不可手动编辑以保障构建可重现性。
Go Mod 是 Go 1.11+ 官方模块系统的核心，不是可选插件，而是现代 Go 项目默认且必须的依赖管理方式。不启用 go mod 的项目在跨团队协作、CI 构建或升级 Go 版本时大概率会失败。
如何正确初始化一个 Go 模块
关键不在“要不要用”，而在于“何时初始化、用什么参数”。项目根目录下执行：go mod init example.com/myapp —— 这里的模块路径（example.com/myapp）不是随便起的，它会成为所有 import 语句的前缀，也影响 go get 解析远程包的行为。
- 如果项目已存在
vendor/或旧版Gopkg.lock，先删掉再 init，否则可能触发隐式 vendor 模式 - 模块路径不必对应真实域名，但要全局唯一；本地开发可用
myproject，但发布到 GitHub 就应设为github.com/username/repo - 执行后生成
go.mod文件，其中go 1.x行声明最小 Go 版本，会影响编译器对新语法的支持判断
go get 添加/升级依赖时的常见陷阱
go get 不只是下载包，它会修改 go.mod 和 go.sum，并可能触发隐式升级整个依赖树。错误用法如 go get github.com/sirupsen/logrus 会导致拉取最新主版本（v2+），而该包 v2 要求模块路径含 /v2 后缀，否则编译报错 unknown revision v2.x.x。
- 指定精确版本：
go get github.com/sirupsen/logrus@v1.9.3 - 升级到某大版本最新：
go get github.com/sirupsen/logrus@v1 - 降级或清理未使用依赖：
go mod tidy（自动删掉go.mod中未被引用的 require，同时补全间接依赖） - 禁止自动升级间接依赖：在
go.mod顶部加// indirect注释无用，真正控制权在go.sum校验和与go list -m all输出
GO111MODULE 环境变量的真实作用场景
这个变量只在两种情况下需要手动设置：在 GOPATH/src 下开发旧项目，或想临时禁用模块模式调试兼容性问题。Go 1.16+ 默认开启 GO111MODULE=on，无论是否在 GOPATH 内。
立即学习“go语言免费学习笔记（深入）”；
-
GO111MODULE=off：完全退回到 GOPATH 模式，go mod命令不可用，go build忽略go.mod -
GO111MODULE=auto（默认值）：仅当当前目录或上级存在go.mod时启用模块模式 - CI 脚本中不要 export 它 —— 显式设为
on更可靠，避免因工作目录位置导致行为不一致
go.sum 文件为什么不能手动编辑
go.sum 不是锁文件，而是每个依赖模块的校验和快照，由 Go 工具链自动生成并验证。手动删行、改哈希、或合并冲突都可能导致 go build 报错 checksum mismatch，尤其在多人协作时。
- 解决冲突：保留双方的行（
go mod允许多行同名模块不同版本），然后运行go mod download重新计算 - 验证完整性：
go mod verify检查本地缓存包是否被篡改 - 清除校验和缓存：
go clean -modcache，再go build会重新下载并写入新go.sum
模块路径设计、go.sum 的不可篡改性、以及 go get 对语义化版本的严格解析，这三者共同构成了 Go 依赖可重现性的基础。跳过任一环，看似省事，后续排查构建失败或版本漂移的时间成本远高于初期规范配置。
