go module是go官方从1.13起强制启用的原生依赖管理体系，取代并废弃了gopath和vendor；其核心特性包括mvs版本选择、go.mod/go.sum契约保障、主版本路径隔离及私有仓库tag严格校验。
Go Module 不是“另一个包管理器”，它是 Go 官方从 Go 1.13 起强制启用的原生依赖管理体系，GOPATH 和 vendor 已被明确废弃——不是推荐不用，而是不再支持多版本共存、无校验、无锁定等关键能力。
为什么 go get 在 Go Module 下行为完全不同
go get 在 GOPATH 模式下只是下载源码到 $GOPATH/src，不记录版本，也不约束依赖树；而在 Go Module 下，它会修改 go.mod，触发最小版本选择（MVS）算法，并自动更新 go.sum 校验和。
- 执行
go get github.com/gin-gonic/gin@v1.9.1会写入精确版本，而非默认拉 master - 省略版本（如
go get github.com/gin-gonic/gin）将按 MVS 规则选满足所有依赖的最低兼容版本，不是最新版 - 若项目已有
go.mod，go get不再影响全局$GOPATH，只作用于当前模块 - 旧版
go get -u全局升级依赖的行为在 Module 模式下已被禁用，必须显式指定模块路径和版本
go.mod 和 go.sum 是不可删减的“契约文件”
go.mod 不是配置文件，而是模块的声明契约；go.sum 不是日志，而是每个依赖内容的密码学指纹。删掉它们等于放弃构建可重现性。
-
go.mod中的require行包含直接依赖 + 间接依赖（// indirect标记），删除某行可能破坏构建，即使该包未被显式 import -
go.sum每行对应一个模块的zip文件哈希，缺失或不匹配会导致go build报错：verifying github.com/xxx/yyy@v1.2.3: checksum mismatch -
go mod tidy会同步增删go.mod和go.sum，但不会自动修复被篡改的哈希值——需手动go mod download或删pkg/mod/cache后重试
主版本号必须体现在 import path 中
Go Module 对语义化版本（SemVer）的主版本变更做了硬性路径隔离：v2+ 版本必须在 import path 末尾加 /v2，否则会被视为 v1 分支的非兼容更新，导致冲突。
- 错误写法：
import "github.com/go-playground/validator"（v10 版本实际路径是github.com/go-playground/validator/v10） - 正确写法：
import "github.com/go-playground/validator/v10"，且go.mod中 require 也必须带/v10 - 不带路径后缀的 import 会被 Go 工具链降级为 v0/v1，无法加载 v2+ 模块，且
go list -m all会显示indirect异常 - 私有仓库同样适用此规则，例如
git.example.com/mylib/v3必须与 tagv3.1.0匹配，不能靠replace绕过
真正容易被忽略的不是语法细节，而是模块路径和 Git tag 的严格一致性——go mod download 依赖的是远程仓库的 tag 名，不是分支名，也不是 commit hash（除非用伪版本）。一旦 tag 写错、漏打、或用了非 SemVer 格式（如 1.2.3 缺少 v 前缀），整个依赖链就会卡在解析阶段，且错误提示极不直观。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
