在 Go 项目里，依赖管理往往决定了协作效率和后续维护成本。很多人知道 go mod 能用，但对“什么时候初始化、什么时候加版本、什么时候清理依赖”并不总是清楚。下面按日常开发流程，把 go mod 最常用的命令和适用场景整理一遍，方便你快速建立一套可执行的判断方法。
为什么 Go 项目现在都用 go mod
包管理工具早已是主流语言开发中的基础设施，用来处理依赖安装、版本控制和更新维护。像 Java 有 Maven，Python 有 pip，PHP 有 composer，而在 Go 生态里，当前最成熟、最通用的方案就是 go mod。
go mod 从 Go 1.11 开始引入，目的就是解决项目依赖版本管理混乱的问题。现在它已经是 Go 项目的标准配置，几乎所有现代 Go 工程都会围绕 go.mod 和 go.sum 来组织依赖。
如何初始化一个 go mod 项目
如果一个项目还没有启用 go mod，第一步就是在项目目录执行初始化命令：
go mod init example.com/group/demo这条命令会把当前项目声明为一个模块，并生成 go.mod 文件。模块名通常使用仓库路径风格，便于后续导入和发布。
生成结果类似下面这样：
module example.com/group/demo
go 1.23.4这里的 module 表示当前模块路径，go 1.23.4 表示该模块使用的 Go 版本信息。实际开发里，只要项目准备进入依赖管理阶段，就应该尽早完成这一步。
添加依赖时该怎么用 go get
完成初始化后，就可以通过 go get 把项目需要的依赖加入模块管理中。例如：
go get github.com/spf13/cobra这会把 github.com/spf13/cobra 加入当前项目依赖。如果你需要锁定一个明确版本，也可以直接在命令后面带上版本号：
go get github.com/spf13/cobra@v1.1.1如果希望拉取最新版，则可以写成：
go get github.com/spf13/cobra@latest这几种写法的区别，核心在于你是否需要可预期的版本结果。个人练习或快速验证时，用默认版本或 latest 往往更直接；但在团队项目或生产环境里，明确指定版本通常更稳妥。
如果要更新已有依赖，可以加入 -u 参数：
go get -u github.com/spf13/cobra这条命令适合你确认要升级依赖时使用，但升级前最好结合项目测试结果一起判断，避免因为上游版本变化带来兼容性问题。
为什么 go mod tidy 很重要
在依赖管理里，最容易被忽略但又最实用的命令之一，就是 go mod tidy。它的作用不只是“清理”，而是同时完成依赖补全与整理。
go mod tidy 会自动检查项目代码中真正使用到的模块，并执行几类操作：
- 移除未使用的依赖项
- 添加缺失的依赖项
- 更新
go.sum文件
换句话说，如果代码里引用了某个包，但 go.mod 里还没有对应记录，tidy 会补上；如果某些依赖已经不再被使用，它也会把它们移除。同时，go.sum 也会随之更新，用来保证依赖校验信息完整可追踪。
这也是为什么很多团队会把 go mod tidy 作为提交代码前的常规动作。它能减少冗余依赖残留，让模块文件保持干净，也更方便其他人接手项目。
除了 init、get、tidy，还有哪些常用命令
如果你想系统查看 go mod 提供了哪些能力，可以直接执行：
go help mod这条命令会列出所有 go mod 子命令。原文中提到的几个高频项包括：
download：下载所有依赖到缓存edit：从工具或脚本修改go.modgraph：打印依赖关系图init：在当前目录初始化 modtidy：添加丢失的和移除无用的依赖模块vendor：将依赖存放到vendor目录verify：校验依赖的哈希值why：解释为什么依赖某个模块
如果只从入门和日常开发角度看，优先掌握 init、get、tidy 就已经能覆盖大部分场景；而当你需要排查依赖来源、生成 vendor 目录、验证依赖完整性时，再继续使用 graph、why、verify 等命令会更合适。
写在最后
go mod 已经成为 Go 项目里事实上的标准依赖管理工具。它从模块初始化、依赖引入、版本更新到校验整理，提供了一套完整流程。
对 Go 开发者来说，真正重要的不只是记住命令，而是知道这些命令分别解决什么问题：新项目先用 go mod init，引入依赖用 go get，整理状态用 go mod tidy，需要扩展排查时再借助其他子命令。把这条链路理顺，项目的可维护性和稳定性都会明显提高。
