go mod 是团队协作的底线工具，解决依赖混乱、构建失败和环境不一致问题：每个项目通过 go.mod 和 go.sum 锁定精确版本并校验哈希，go get 行为可控，CI/CD 构建可复现，但需人工核对 go mod tidy 输出。
Go 模块（go mod）不是“锦上添花”的可选项，而是团队协作中避免依赖混乱、构建失败和环境不一致的底线工具。
为什么 go.mod 能让多人共用同一份依赖版本
没有模块时，GOPATH 下所有项目共享全局 src/ 和 pkg/，A 项目升级 github.com/sirupsen/logrus 到 v1.9.0，B 项目可能瞬间编译失败。启用模块后，每个项目自带 go.mod 和 go.sum：
-
go.mod明确记录require github.com/sirupsen/logrus v1.8.1—— 所有人go build都拉这个精确版本 -
go.sum校验每个依赖的哈希值，防止代理篡改或网络污染 - 即使本地
GOPATH里有旧版 logrus，go build也只认go.mod指定的版本
团队成员执行 go get 时行为不再不可控
旧方式下，go get github.com/gorilla/mux 默认拉 master 分支最新提交，不同人执行时间不同，得到的代码可能差几个 commit。模块模式下：
- 默认行为是拉最新 tagged 版本（如
v1.8.0），不是main分支 - 加
@v1.7.4可锁定小版本：go get github.com/gorilla/mux@v1.7.4 - 加
@master或@23a1f2b属于显式“破戒”，必须写进go.mod并提交，全组可见 -
go get -u不再偷偷升级间接依赖，除非加-t或明确指定路径
CI/CD 流水线不再因本地缓存差异而随机失败
过去 CI 机器上 go build 失败，常因：本地开发机有某个 replace、某人手动 git clone 了私有库到 GOPATH、代理配置不一致。模块让构建彻底可复现：
立即学习“go语言免费学习笔记（深入）”；
-
GO111MODULE=on强制启用模块，无视GOPATH状态 -
go mod download会按go.sum逐个校验，缺一个哈希对不上就报错，不靠运气 - 私有模块可通过
GOPROXY=https://proxy.golang.org,direct+GOPRIVATE=git.internal.company.com/*统一走公司代理或直连，不用每人配.netrc - Docker 构建中只需
COPY go.mod go.sum .→go mod download→COPY . .，中间层缓存稳定
FROM golang:1.21 WORKDIR /app COPY go.mod go.sum . RUN GO111MODULE=on go mod download COPY . . RUN GO111MODULE=on go build -o server .
真正容易被忽略的点是：模块不是“设一次就完事”。当团队引入新私有库、升级 major 版本（如 v2 路径变更）、或使用 replace 临时打补丁时，go mod tidy 的输出必须人工核对 —— 它不会警告你 replace 是否已过期，也不会提醒 v2 包是否漏写了 /v2 后缀。
