Go Modules 是 Go 项目依赖管理的唯一推荐方式，必须用 go mod init 初始化模块，依赖变更须通过 go get，每次修改后需运行 go mod tidy 同步依赖并校验 go.sum。
Go Modules 是当前 Go 项目构建依赖的唯一推荐方式，没有替代方案，也不应尝试绕过它。
go mod init 必须在项目根目录执行
模块初始化不是“可选步骤”，而是构建依赖的前提。如果项目已有 go.mod，go build、go test 等命令才会按模块语义解析依赖；否则会 fallback 到 GOPATH 模式（已弃用），或直接报错 no required module provides package。
- 执行前确认当前路径是项目根目录（即未来放
go.mod的地方），且该目录下没有嵌套其他模块 - 模块路径建议与代码托管地址一致，例如：
go mod init github.com/yourname/project，避免用本地路径如go mod init ./src - 若项目已存在
import语句但未初始化模块，go mod init会自动扫描并写入基础依赖，但不会下载——需后续触发
go get 是添加/更新依赖的唯一标准入口
go get 不仅下载包，还会修改 go.mod 和 go.sum，是唯一被 Go 工具链认可的依赖变更方式。手动编辑 go.mod 或用 go mod edit 属于高级操作，日常开发应避免。
- 添加新依赖：
go get github.com/gin-gonic/gin@v1.9.1（带版本更安全） - 升级已有依赖：
go get -u github.com/sirupsen/logrus（默认升到最新兼容次版本） - 降级或切 commit：
go get github.com/xxx/yyy@abcd123或@v0.0.0-20230101000000-abcd123 - 执行后立即运行
go mod tidy，清理冗余 require 并补全间接依赖
go mod tidy 是每次变更后的必做动作
它不只是“整理”，而是强制同步三者：源码中的 import、go.mod 中的 require、以及实际需要参与构建的全部依赖（包括 transitive 依赖）。跳过这步，CI 构建很可能失败。
- CI 流水线中必须包含
go mod tidy -v，并检查退出码；若输出新增/删除行，说明go.mod未提交 - 本地开发时，每次
git add前应确保go.mod和go.sum已被go mod tidy更新且无差异 - 若
go mod tidy报错missing go.sum entry，说明依赖校验失败，通常因代理或网络问题导致 zip 下载不完整，需清缓存：go clean -modcache后重试
vendor 目录只在特定构建环境才有意义
绝大多数场景下，go mod vendor 是冗余甚至有害的操作。Go 官方明确建议：库（library）项目禁止提交 vendor/；只有封闭构建环境（如离线 CI、Air-Gapped 部署）的应用（application）才考虑启用。
- 启用 vendor 后必须加
-mod=vendor参数编译：go build -mod=vendor，否则仍走$GOPATH/pkg/mod - vendor 不解决版本冲突，反而掩盖
go.sum校验逻辑，增加调试成本 - 2026 年主流云 CI（GitHub Actions、GitLab CI）均已支持 proxy 缓存和模块并行下载，vendor 带来的“确定性”优势已基本消失
真正容易被忽略的是 go.sum 文件的校验行为：它不是“锁文件”，而是一份动态哈希清单。只要依赖包内容不变，哪怕换镜像源下载，哈希值也一致；一旦不一致，go build 会直接中断——这不是 bug，是设计使然。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
