go mod init必须在项目根目录执行，因为其基于当前路径推导模块路径，若在子目录执行会生成孤立go.mod，导致上级导入路径无法解析而报错。
Go语言中第三方库包管理不是“配合语言学习”的辅助项，而是必须同步掌握的核心能力——不理解go mod机制，就无法真正运行、调试或复现任何实际项目。
go mod init 为什么必须在项目根目录执行
初始化模块不是形式主义，而是定义整个依赖作用域的起点。一旦go mod init执行，Go就会以当前目录为根，扫描所有import语句生成初始require列表。
- 如果在子目录下误执行，会生成一个孤立的
go.mod，导致上级目录的导入路径无法被正确解析，编译时报cannot find package - 模块路径（如
github.com/yourname/project）应与代码托管地址一致，否则他人go get时会拉取错误路径 - 不指定路径直接
go mod init会尝试推导，但推导结果常不可靠（比如推成project而非完整域名路径），后续go get可能写入错误模块名
go get @ 版本号和 -u 的行为差异极易踩坑
go get不是简单的“下载”，它会实时修改go.mod并触发依赖图重算，不同参数带来完全不同的版本策略：
-
go get github.com/gin-gonic/gin@v1.9.1：强制锁定到该精确版本，写入require行，适合生产环境或需要确定行为的场景 -
go get -u github.com/gin-gonic/gin：按语义化版本规则升级到最高兼容版（如从v1.8.0升到v1.9.1，但不会升到v2.0.0），但若该库未打v1.9.1tag，可能拉到v1.9.0+incompatible，行为不稳定 -
go get github.com/some/lib@8f3a2b1：基于commit哈希拉取，适用于未发布tag的紧急修复，但go.sum校验仍生效，不可绕过
go mod tidy 不只是清理，它暴露真实依赖结构
运行go mod tidy后，你会看到go.mod里突然多出一堆间接依赖（// indirect标记），这不是冗余，而是MVS（最小版本选择）算法的实际结果：
立即学习“go语言免费学习笔记（深入）”；
- 它把所有transitive依赖显式列出来，防止因某一级依赖升级导致下游意外变更
- 如果
tidy删掉了你手动写进go.mod的某行require，说明该项目中根本没import它——可能是旧代码残留，也可能是你误以为需要该库 - 若
tidy报错missing go.sum entry，说明本地缓存或代理返回了与首次下载不一致的内容，必须检查网络代理或镜像源是否可信
go.sum 文件为什么不能删、也不能手改
go.sum是构建可重现性的最后一道防线，它的存在意义不是“记录版本”，而是“断言字节一致性”：
- 每次
go build或go run都会校验每个依赖模块的SHA256哈希，不匹配则报错checksum mismatch，阻止被篡改或污染的包进入构建流程 - 删除
go.sum会导致下次go build重新生成，但新生成的哈希基于当前网络拉取的内容——如果此时上游已悄悄修改了某个tag的代码（极少数但真实发生过），你的构建就不再可重现 - 国内用户务必设置
GOPROXY=https://goproxy.cn,direct，否则go.sum可能因直连失败而回退到不可控的源，破坏校验逻辑
真正难的不是记住命令，而是理解每条命令背后对go.mod和go.sum的修改如何影响整个依赖图的收敛性——尤其当多个模块通过replace或go.work交叉引用时，一个go get可能触发十几层间接依赖的重算。这种复杂性不会因“学完语法”而消失，只会随着项目规模放大。
