go modules 是当前唯一推荐的依赖管理方式，必须用 go mod init 在项目根目录初始化，模块路径需与实际托管地址（如 github.com/yourname/app）严格一致，否则 import 解析失败、go get 无法定位；错误路径、子目录执行或本地路径初始化均导致协作与 ci 故障。
Go Modules 是当前唯一推荐的依赖管理方式，没有“优雅替代方案”——所有试图绕过它的做法，最终都会在协作、CI 或升级时付出更高代价。
go mod init 必须在项目根目录执行
模块路径不是随便起的，它直接决定 import 语句的写法和远程包解析逻辑。比如你的 GitHub 仓库是 github.com/yourname/app，就该运行：
go mod init github.com/yourname/app
如果误在子目录下执行（如 cmd/ 或 internal/），会生成错误的模块路径，导致其他包无法正确导入，或 go get 找不到你自己的模块。
- 模块路径必须与代码实际托管地址一致，否则别人
go get时会失败 - 不能用本地路径（如
./myapp）或相对路径初始化 - 若已有
go.mod，重复执行go mod init不会覆盖，但会报错提示“already exists”
go get 不要加 @latest，尤其在线上分支
@latest 看似省事，实则把版本控制权交给了上游——某天上游发个 v2.0.0 breaking change，你的 CI 就可能突然挂掉。
- 生产项目应显式指定语义化版本，例如：
go get github.com/gin-gonic/gin@v1.9.1 - 想升级？先查 changelog，再手动改
go.mod中的版本号，或用go get -u=patch限制只升补丁版 -
go get默认会更新go.mod和go.sum，但不会自动清理未引用的依赖，这点常被忽略
go mod tidy 是日常维护的底线操作
它不只是“整理依赖”，而是做三件事：补全缺失的 require、删掉未使用的、校验 go.sum。但要注意：
- 它不会帮你降级已引入的高版本——如果某个间接依赖拉进了不兼容的 v2.x，
tidy反而会固化它 - 执行前建议先
git status确认没漏提交旧go.mod，否则可能覆盖他人修改 - CI 流程里应强制加
go mod tidy -v && git diff --exit-code go.mod go.sum，防止有人漏提交
replace 和 exclude 不是常规手段，而是手术刀
它们解决的是“MVS 失效”场景，比如私有库、未发布分支、或上游 bug 还没修复。但滥用会导致：
-
replace后本地能跑，CI 却因 GOPRIVATE 配置缺失而失败 -
exclude只阻止特定版本被选中，但不阻止它被其他依赖悄悄拉进来——得配合go mod graph确认是否真被剪掉 - 所有
replace和exclude必须加注释说明原因，否则半年后没人记得为什么这么写
真正容易被忽略的点是：go.sum 不只是校验和快照，它记录了每个依赖的完整溯源路径；一旦你手动编辑 go.mod，就得重新 go mod download 或 go build 触发 go.sum 更新，否则校验会失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
