go mod init 必须在项目根目录执行，模块路径需为全局唯一语义化路径（如github.com/yourname/myapp），不可用main或空字符串，否则破坏import解析与依赖一致性。
go mod init 必须在项目根目录执行，且模块路径不能是 main
模块路径不是 URL，也不是随便起的名字；它会成为 import 语句的前缀，一旦发布 v1.x 就不可随意变更。用 main 或空字符串初始化（如 go mod init main）会导致后续无法被其他模块正确引用，也违反 Go 工具链对导入路径的解析逻辑。
正确做法是使用具备语义的路径，比如 go mod init github.com/yourname/myapp 或公司内部域名格式 go mod init corp.example.com/project。即使该路径当前不可访问，也不影响本地构建——Go 只关心路径唯一性与一致性。
- 模块路径应与 Git 仓库地址保持逻辑一致（便于他人
go get） - 避免使用纯数字、下划线开头、或含特殊符号的路径名
- 如果项目是 monorepo 中的一个子服务，路径可为
corp.example.com/services/user，而非统一用顶层路径
go get @vX.Y.Z 是添加/降级依赖的唯一可控方式
直接写 go get github.com/some/lib 会拉取 latest（可能是 pre-release 或 main 分支），而 go get -u 更危险：它按 MVS 算法自动升级所有间接依赖，极易引入破坏性变更。生产项目中，版本必须显式声明。
真正安全的操作只有两种：
立即学习“go语言免费学习笔记（深入）”；
-
go get github.com/some/lib@v1.2.3—— 精确指定语义化版本 -
go get github.com/some/lib@v1.2—— 允许 patch 升级（如 v1.2.0 → v1.2.5），但不跨 minor
不要依赖 @latest，尤其在 CI 流水线中；它本质是 unstable alias，Go 官方文档明确建议避免用于生产环境。
go mod tidy 不只是“清理”，它决定最终依赖快照
go mod tidy 的作用远不止删掉未引用的 require 行。它会：
- 扫描全部
.go文件，补全代码中实际 import 但未记录在go.mod中的依赖 - 递归计算传递依赖，将它们写入
go.sum并校验哈希 - 移除
go.mod中已无 import 引用的require条目（包括间接依赖的冗余声明）
关键点：每次提交前必须运行 go mod tidy，然后把更新后的 go.mod 和 go.sum 一起提交。跳过这步，或者只提交 go.mod 而忽略 go.sum，会导致不同机器构建结果不一致——因为 go.sum 是内容校验依据，不是可选文件。
replace 和 exclude 是临时手段，不是版本管理方案
replace 常用于开发阶段对接 fork 或本地调试分支，例如：
replace github.com/old/lib => ./fixes/local-patch
但它不会改变远程依赖的真实版本号，也不能替代 go get 操作；exclude 更应谨慎使用，仅限绕过已知严重漏洞的间接依赖（如某个深层依赖里有 CVE），且必须附带注释说明原因和预计移除时间。
这两条指令都不会被 go get 或 go mod vendor 继承，意味着：
- CI 环境若未启用
GO111MODULE=on或未加载 replace 规则，构建会失败 - 发布到私有模块仓库时，replace 不会被下游自动继承，必须手动同步
- exclude 可能掩盖真实依赖问题，长期存在会降低可维护性
真正需要稳定版本控制的地方，应该用 go get @vX.Y.Z 锁定，而不是靠 replace 掩盖。
