go mod tidy 未拉取 import 包的根本原因是被导入仓库缺少 go.mod 文件或子目录未声明独立模块；解决需确认 go.mod 存在、使用 replace 临时指向本地路径或采用伪版本拉取。
go mod tidy 为什么没拉到我 import 的包
常见现象是执行 go mod tidy 后，go.mod 里没新增依赖，编译却报 import not found。根本原因不是命令失效，而是 Go 工具链没在当前模块路径下“看到”该包的 go.mod —— 它可能是个没有模块声明的老项目，或你 import 的是子目录但那个子目录没独立模块。
解决方法很直接：
- 确认被 import 的仓库根目录是否存在
go.mod；若不存在（比如某些早期开源库只维护master分支且无模块），Go 默认按伪版本（v0.0.0-yyyymmdd...）拉取，但前提是能访问其源码地址 - 如果 import 路径带子目录（如
github.com/user/repo/subpkg），而该仓库主模块未导出该子目录（即subpkg不在主go.mod的require列表中，也未发布对应 tag），Go 会尝试解析为独立模块 —— 这时它需要subpkg目录下也有go.mod，否则失败 - 临时绕过：用
replace指向本地已有的代码目录，例如replace github.com/user/repo => ./local/repo，再跑一次go mod tidy
从 dep/glide 迁移时 go.sum 校验失败怎么办
老项目用 dep 或 glide 管理依赖，迁移到 Go Modules 后首次 go mod tidy 经常触发 verifying github.com/xxx@v1.2.3: checksum mismatch。这不是网络问题，而是旧工具记录的 commit hash 和 Go Modules 从 proxy 下载的归档内容哈希不一致 —— 因为 Go proxy 对同一 tag 可能返回不同压缩包（含或不含 test 文件、.git 目录等）。
安全做法是信任 go.sum 生成逻辑，而不是复用旧锁文件：
立即学习“go语言免费学习笔记（深入）”；
- 删掉旧的
Gopkg.lock或glide.lock，清空vendor/目录 - 运行
go mod init初始化模块，再手动补全关键依赖（如go get github.com/gin-gonic/gin@v1.9.1） - 执行
go mod tidy，让 Go 自动填充go.mod和生成全新go.sum - 若某依赖必须锁定特定 commit（比如内部未打 tag 的分支），用伪版本语法：
go get github.com/user/repo@9a8b7c6d
GO111MODULE=auto 在 GOPATH 内还能用 Modules 吗
不能。当 GO111MODULE=auto（Go 1.15 及更早默认）且当前目录在 $GOPATH/src 下时，Go 会强制退回到 GOPATH 模式，忽略项目根目录下的 go.mod，所有依赖仍走全局 $GOPATH/src 查找。
这意味着即使你手动生成了 go.mod，go mod tidy 也不会生效，go build 仍可能拉最新 master 而非你声明的版本。
正确姿势只有两个：
- 把项目挪到
$GOPATH外任意路径（推荐），此时auto会自动启用 Modules - 显式设置
GO111MODULE=on（全局或当前 shell），彻底关闭 GOPATH fallback 行为
Go 1.16+ 已默认 on，但 CI 脚本或旧 Docker 镜像若基于低版本 Go，仍需检查该变量值。
replace 语句上线前最容易漏掉的检查点
replace 是调试多模块协作的利器，但也是线上构建最常翻车的地方：CI 流水线里没有本地路径 ./local/dep，导致 go build 直接失败。
上线前务必确认三件事：
- 运行
go list -m all | grep '=>'，看是否还有活跃的replace输出；若有，说明它正在生效 - 检查
go.mod里replace行是否带注释（如// dev-only），避免靠记忆判断用途 - CI 构建前加一步
go mod edit -dropreplace='github.com/user/dep'（可批量），或用go mod vendor后验证 vendor 目录是否含预期代码 —— vendor 不受replace影响
真正难察觉的是 replace 的传递性：它只作用于当前模块，下游依赖不会继承。如果你的模块 A replace 了 X，而模块 B 依赖 A 和 X 的不同版本，B 的构建结果取决于它自己是否也写了 replace —— 这种隐式耦合，光看 A 的 go.mod 根本发现不了。
