Go modules 初始化失败主因是路径推断错误或残留文件干扰，应清理后显式指定module path；go get版本不生效因默认升级而非锁定，需确认tag存在或强制commit；vendor需配合-mod=vendor构建且定期更新；replace与exclude共存时顺序和版本号须谨慎处理。
Go modules 初始化失败：go mod init 报错或生成错误模块名
执行 go mod init 时，如果当前目录已有 go.sum 或旧的 Gopkg.lock，可能干扰初始化；更常见的是模块路径推断出错——比如在 $GOPATH/src 下直接运行，Go 会尝试从路径推导 module name，导致生成类似 module github.com/username/project 的错误假设（实际你并未托管在 GitHub）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先清理残留：
rm -f go.mod go.sum Gopkg.lock vendor/ - 用显式路径初始化：
go mod init example.com/myapp（域名不需真实存在，仅作命名空间，避免未来重命名麻烦） - 若项目已提交到私有 Git 仓库，可直接用其地址：
go mod init gitlab.example.com/group/project - 初始化后检查
go.mod第一行是否为预期 module path，不是则手动修正并运行go mod tidy重建依赖图
go get 拉取特定版本失败：@v0.12.3 不生效或回退到 latest
go get 默认行为是升级到满足要求的最新兼容版本，而非精确锁定。写 go get github.com/sirupsen/logrus@v1.9.3 看似指定版本，但若 go.mod 中已有更高主版本（如 v2.0.0+incompatible），它可能拒绝降级；若该 tag 不存在或未被 Go proxy 缓存，也会 fallback 到 latest 并报 warning。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确认 tag 存在：
curl -I https://proxy.golang.org/github.com/sirupsen/logrus/@v/v1.9.3.info - 强制使用确切 commit：
go get github.com/sirupsen/logrus@55046e2 - 想彻底禁用自动升级，改用
go mod edit -require=github.com/sirupsen/logrus@v1.9.3+go mod tidy - 注意
@latest不等于master分支，而是语义化版本中最高合法 patch 版本，可能跳过预发布版
vendor 目录未更新或构建仍走 proxy：go mod vendor 失效
go mod vendor 只复制 go.mod 中声明的直接依赖及其 transitive 依赖，但不会自动更新 vendor 内容；更关键的是，Go 1.14+ 默认启用 GOPROXY，即使有 vendor，go build 仍可能绕过它去拉远程包（尤其当本地 vendor 缺少某间接依赖时）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每次变更依赖后必须重新运行：
go mod vendor→git add vendor/→git commit - 构建时强制使用 vendor：
go build -mod=vendor（缺这个 flag 就不算真正离线） - 验证 vendor 完整性：
go mod verify检查哈希，go list -mod=vendor -f '{{.Dir}}' ./...确认所有包都来自 vendor - CI 中建议设环境变量：
GOPROXY=off GOFLAGS=-mod=vendor，避免意外联网
多模块项目中 replace 与 exclude 冲突：私有库打补丁后无法生效
用 replace 替换私有 fork（如 replace github.com/orig/lib => ../lib-fix）很常见，但若同时用了 exclude（如排除某个已知崩溃的版本），Go 会在 resolve 阶段先 apply exclude，再 apply replace，导致 replace 规则被跳过——尤其当 fork 的版本号落在被 exclude 的区间内。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 优先用
replace+ 本地路径，避免exclude；exclude应只用于彻底不可用的版本（如 panic in init） - 若必须共存，把
replace放在exclude之后，并确保替换目标版本号不在 exclude 范围内（例如 excludev1.2.0，就用v1.2.1-fix作为 fork tag） - 调试依赖图用：
go list -m all | grep target和go mod graph | grep target，看最终解析出的路径是否含=> - 注意
replace对子模块无效，跨 module 的引用仍走原始路径，需在各 module 的go.mod单独声明
go build 可能同时读取根目录、vendor、GOROOT/src、甚至子目录下的多个 go.mod，而 go list -m 和 go mod graph 输出的差异，往往就是问题根源。 
