Go模块依赖源码存于$GOPATH/pkg/mod，按“域名/路径@版本号”分层存储，含完整源码、go.mod和.info校验文件；该目录只读，由工具链自动管理，不可手动修改。
go.mod 依赖源码到底存在哪？不是 $GOPATH/src
Go Modules 模式下，go get 下载的所有依赖源码，**不会放在 $GOPATH/src**，而是统一存入全局模块缓存目录：$GOPATH/pkg/mod。这是最常被误判的点——尤其从 GOPATH 时代转过来的开发者，仍习惯去 src 里翻代码。
实际路径结构是：$GOPATH/pkg/mod/cache/download/ 存原始 zip 缓存；$GOPATH/pkg/mod/ 下则是解压后的模块快照，按 域名/路径@版本号 组织，例如：
github.com/gin-gonic/gin@v1.9.1/ ├── go.mod ├── gin.go └── ...
这个目录是只读的，由 Go 工具链自动管理，**你不该手动修改或删除其中文件**（除非清理缓存用 go clean -modcache）。
为什么 go.sum 文件必须和 go.mod 一起提交？
go.sum 不是可选的“校验备份”，它是构建可重现性的强制约束。它记录了每个依赖模块的 **具体 commit hash 或 zip 校验和**，防止相同版本号下因远程仓库篡改、重发 tag 导致行为不一致。
立即学习“go语言免费学习笔记（深入）”；
常见错误现象：
- CI 构建失败，报错
checksum mismatch - 本地能跑，同事拉代码后
go build报错
原因通常是：go.sum 未提交、被误删、或有人手动编辑过。正确做法是：
- 每次
go mod tidy或go get后，go.sum会自动更新，连同go.mod一起git add - 禁止在
go.sum中手动增删行，哪怕看起来“只是注释” - 若遇到校验失败，优先检查是否有人
go get github.com/foo/bar@v1.2.3后又撤回，导致go.sum状态不一致
replace 和 exclude 的真实作用范围与陷阱
replace 只影响当前模块的构建，**不改变依赖本身的模块路径或导入语句**；exclude 则是彻底从构建列表中剔除某个版本——但它不能解决“间接依赖冲突”，只能规避已知问题版本。
典型使用场景：
-
replace github.com/example/lib => ./internal/lib：本地调试未发布的改动，此时import "github.com/example/lib"仍不变，但编译时读的是本地路径 -
exclude github.com/badpkg v1.0.5：当某依赖的 v1.0.5 有 panic bug，且上游未发布修复版时临时绕过
容易踩的坑：
-
replace路径写成相对路径但没注意工作目录，导致 CI 失败（建议统一用绝对路径或./local/path） -
exclude后没运行go mod tidy，残留的旧版本仍可能被间接引入 - 多个
replace指向同一模块不同版本时，Go 会报错，必须显式指定唯一映射
go list -m all 显示的“伪版本”是怎么来的？
当你看到类似 github.com/some/pkg v0.0.0-20230401123456-abcdef123456 这种格式，说明该模块没有打正式 tag，Go 自动生成了“伪版本号”：由时间戳 + 提交哈希构成。
这通常发生在：
- 依赖仓库只有 commit，没发任何 tag
- 你用
go get github.com/some/pkg@commit-hash直接指定 commit - 模块路径本身不匹配（比如模块声明为
example.com/mymod，但实际 repo 地址是github.com/xxx/mymod）
伪版本不可靠，不适合生产环境长期使用。如果必须用，应尽快推动上游打 tag，或通过 replace 锁定到稳定 commit。
真正要留意的，不是怎么生成伪版本，而是它出现时往往意味着：模块维护不规范、版本策略缺失、或者你的 import 路径和模块声明不一致——这些才是根因。
