module指令必须是go.mod第一行（注释除外），定义模块唯一路径，决定import解析、依赖校验和版本发布，路径须与实际import路径完全一致，不可为本地相对路径或以/结尾。
module 声明必须是 go.mod 的第一行（注释除外）
module 指令定义整个模块的导入路径，它不是可选标签，而是 Go 工具链解析 import 路径、校验依赖、发布版本的唯一依据。如果它前面有空行、空白符或非注释内容，go mod tidy 会直接报错：go.mod:1: unknown directive "require"。
- 路径不能以
/结尾（如module github.com/user/repo/→ 错误；应为module github.com/user/repo） - 不能是本地相对路径（如
module ./mylib或module myapp），否则go get无法解析，他人也无法 import - 路径需与实际代码被引用时的 import 路径完全一致；改名后未同步更新所有
import语句，编译会报import path does not match module path
require 行里的版本号必须可解析，且 // indirect 不可手动删
require 列出的是直接依赖，但 Go 允许写语义化版本（v1.9.3）、伪版本（v0.23.0-20240522172620-85d65e11e3f1），甚至主干快照（master 或 main + incompatible）。但不能写 latest 或模糊版本号，否则 go mod tidy 会拒绝处理。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
// indirect是 Go 自动标记的间接依赖，表示该包没被你的代码直接import，而是某直接依赖内部用到的 - 手动删除
// indirect行没用：下次go mod tidy会重新加回来，还可能选错版本 - 想升级某个间接依赖？先查谁在用它：
go mod graph | grep 'pkg-name'，再用go get example.com/pkg@v1.2.3提升为直接依赖
replace 和 exclude 只对当前模块生效，上线前必须清理
replace 和 exclude 是调试专用机制，不传播给下游模块。它们只影响当前 go.mod 的构建行为，CI 或他人拉取代码时若缺失本地路径或配置，就会失败。
-
replace github.com/old/lib => ./fix中的./fix是相对于go.mod所在目录的路径，且目标目录必须含合法go.mod - 多个
replace映射到同一本地路径 → Go 报错：replaced by multiple modules - 长期用
replace替换标准库或核心生态包（如golang.org/x/sys）极易引发隐性不兼容，尤其在跨 Go 版本构建时 -
exclude极少使用，仅当某依赖版本存在已知严重 bug 且无替代方案时才考虑；它不阻止其他依赖显式 require 该版本，所以不一定能解决问题
go 指令声明最小 Go 版本，影响语法可用性和工具行为
go 1.26 这类指令不是“建议升级”，而是模块兼容性契约。它决定哪些语言特性（如泛型约束、clear() 函数、类型别名）能被启用，也影响 go list -m all 输出格式、go mod graph 的边规则等。
- 若代码用了 Go 1.22+ 新增的
type T = U语法，但go.mod写着go 1.21，go build会直接报错 - 低于声明版本的 Go 工具链运行
go mod tidy可能失败，尤其是遇到~版本比较符或新字段时 -
go指令不强制你升级 Go，但团队协作中应确保 CI 和本地开发环境的 Go 版本 ≥ 此值
go.sum 不是缓存文件——它是安全契约，删了重生成等于放弃校验。任何绕过它的操作（比如删 go.sum 后 go mod download）都会埋下供应链风险。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
