Go初级项目只需用go mod：执行go mod init初始化并生成go.mod，配合go.sum锁定依赖；务必运行go mod tidy同步依赖，提交go.mod和go.sum，避免GOPATH模式与网络代理问题。
Go 初级项目不需要用 go mod 以外的版本管理工具——go mod 就是 Go 官方推荐且默认启用的模块版本控制系统，它直接内置于 go 命令中，不是可选插件。
如何初始化一个带版本控制的 Go 项目
只要项目根目录下执行 go mod init，就完成了模块初始化和版本控制起点。这一步会生成 go.mod 文件，记录模块路径和 Go 版本要求。
常见错误：在没有 go.mod 的情况下运行 go build 或 go run，Go 会进入“GOPATH 模式”（已弃用），导致依赖无法正确解析、版本不可控。
- 确保项目根目录下没有
vendor/目录干扰（除非你明确需要 vendor 锁定） - 模块名建议与代码托管地址一致，比如 GitHub 仓库是
github.com/yourname/project，就用go mod init github.com/yourname/project - 如果只是本地练习，模块名可以是任意合法标识符，如
go mod init hello，但不便于后续发布或协作
依赖版本是如何被记录和锁定的
go.mod 记录的是最小版本要求（require），而真正锁定具体版本的是 go.sum 文件。后者由 Go 自动维护，包含每个依赖模块的校验和，防止下载被篡改的包。
常见错误：手动编辑 go.sum 或删除它后不重新运行 go mod tidy，会导致构建失败或校验失败（checksum mismatch）。
- 添加新依赖时，直接写代码 import 并运行
go build，Go 会自动下载并写入go.mod - 清理未使用的依赖：运行
go mod tidy，它会同步go.mod和go.sum，并移除无引用的require行 - 升级某个依赖到指定版本：用
go get example.com/pkg@v1.2.3，Go 会更新go.mod并重算go.sum
为什么不能用 Git tag 替代 go.mod 的版本控制
Git tag 是对代码快照的标记，不描述依赖关系；而 go.mod 描述的是“这个项目在什么依赖组合下可复现构建”。两者职责不同，必须共存，不能互相替代。
常见错误：只打 Git tag 却不更新 go.mod 中的模块版本（如把 module example.com/myapp 改成 module example.com/myapp/v2），会导致其他项目无法通过 go get 正确识别语义化版本。
- 要发布 v2+ 版本，必须更改模块路径，例如从
example.com/myapp改为example.com/myapp/v2 - 主版本号变更后，旧版本和新版本可同时被其他项目导入，互不干扰
- 不要在
go.mod中写死 commit hash（如@abcdef），除非调试需要；长期应使用语义化标签（@v1.5.0）
初级项目最容易忽略的版本陷阱
最常被跳过的动作是：没运行 go mod tidy 就提交代码，导致 go.mod 和实际代码依赖不一致，CI 构建失败或本地能跑线上跑不了。
另一个隐形坑是 GOPROXY 设置。国内开发者若没配代理，go get 可能超时或拉不到包，误以为是版本问题，其实是网络问题。
- 检查当前模块状态：
go list -m all查看所有已解析依赖及其版本 - 临时绕过代理验证问题：
export GOPROXY=direct（慎用，仅调试） - CI 环境中务必显式运行
go mod download，避免构建时首次下载失败 - 不要把
go.sum排除在 Git 提交之外——它是构建可重现的关键证据
go mod init example.com/hello go mod tidy git add go.mod go.sum git commit -m "init module and lock dependencies"
模块路径命名、go.sum 的存在与否、以及每次变更后是否运行 go mod tidy，这三件事决定了初级项目版本控制是否真的生效——它们比 Git 分支策略更直接影响代码能否被别人正确构建。
