go modules是当前唯一强制且标准的依赖管理方式，go 1.16起默认启用、彻底取代gopath与vendor；其核心在于go.mod标识模块身份、go mod tidy执行最小版本选择并同步实际import、go.sum提供不可绕过的校验安全锁。
Go Modules 是唯一需要掌握的依赖管理方式
现在写 Go 项目，go mod 不是“可选方案”，而是强制路径。Go 1.16 起已完全移除对 GOPATH 模式的支持，GO111MODULE=auto 在非 GOPATH 目录下也会自动启用模块模式。你不需要再纠结要不要用、怎么切换，只要项目里有 go.mod，就按 Modules 规则走——这是当前所有 CI/CD、IDE、代理服务（如 proxy.golang.org）默认适配的唯一标准。
为什么 GOPATH 和 vendor 都该被彻底遗忘
这两个机制不是“过时”，而是存在根本性缺陷，无法支撑现代协作开发：
-
GOPATH：所有项目共享$GOPATH/src，依赖无版本、无隔离。比如github.com/sirupsen/logrus曾从 v1.0 升级到 v2.0 并改包路径，但 GOPATH 下只能存一个版本，A 项目用 v1、B 项目用 v2 就必然冲突 -
vendor：虽能本地化依赖，但go get -u无法指定版本，govendor sync等工具手动维护易出错，且vendor/目录体积膨胀（一个中型项目常达 200MB+），Git 提交和克隆成本陡增 - 二者都不生成校验文件，
go.sum不存在，无法验证下载包是否被篡改或损坏
go mod init 和 go mod tidy 的真实作用
go mod init 不是“创建空模块”，而是为当前目录打上模块身份；go mod tidy 也不是“整理依赖”，而是执行最小版本选择（MVS）并同步 go.mod 与实际 import 使用情况：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
go mod init example.com/myapp会生成go.mod，其中module行必须与后续import路径一致，否则编译报错import path does not match module path -
go mod tidy会扫描全部.go文件中的import，自动补全缺失的require，同时删掉未被引用的依赖——它不看go get历史，只看代码里真正 import 了什么 - 若已有旧依赖被删，但
go.sum还留着其校验和，go mod tidy不会清理它；需手动运行go mod verify或删go.sum后重跑tidy
go.sum 文件不是“备份”，而是安全锁
go.sum 记录每个模块版本的哈希值，不是为了容灾，而是防止依赖被中间人替换或镜像源污染：
- 首次
go mod download时，Go 会向GOSUMDB（默认sum.golang.org）查询校验和；若不匹配，构建直接失败，不会静默覆盖 - 私有模块（如
git.internal.company/project）若未配置GOPRIVATE，Go 仍会尝试向公共 sumdb 查询，导致拉取失败；必须设置GOPRIVATE=*.internal.company -
go.sum中每行格式为module@version h1:xxx，其中h1:是 SHA256 校验和前缀；手动修改它会导致go build报错checksum mismatch
真正容易被忽略的是：模块路径、go.mod 版本声明、go.sum 校验三者必须严格咬合，任何一方被人工绕过（比如删 go.sum 后不重跑 tidy），都可能在不同环境触发不可重现的构建失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
