go mod tidy无输出但依赖未下载，大概率是模块缓存路径错位，因项目重命名、module声明变更或跨gopath移动导致旧路径缓存残留，需执行go clean -modcache清理。
go mod tidy 无输出但依赖没下载，大概率是缓存路径错位
Go 工具链会把模块缓存到 $GOMODCACHE（通常是 $GOPATH/pkg/mod），但项目重命名、go.mod 中的 module 声明变更、或跨 GOPATH 移动目录后，缓存里仍存着旧路径的包，导致新导入路径无法命中。现象就是 go mod tidy 静默退出，不报错也不下载任何东西。
验证方法：
– 运行 go list -m all 看是否列出大量 => 替换路径或版本为空的条目
– 检查 go.mod 第一行 module github.com/xxx/yyy 是否与当前项目实际路径一致
– 执行 go env GOMODCACHE，手动进入该目录，用 find . -name "*your-module-name*" 确认缓存中是否存在旧路径残留
清理缓存必须用 go clean -modcache，不是删 go.sum
go.sum 只存校验和，删了它只会让 go mod tidy 重新生成，解决不了缓存污染。真正要清的是整个模块缓存目录——它里面混着不同版本、不同路径的模块归档，一旦错乱，go build 或 go test 就可能链接到错误的 .a 文件，引发 undefined 错误。
- 执行
go clean -modcache（这是唯一可靠方式，别手删$GOMODCACHE下子目录） - 如果同时怀疑构建缓存也脏了（比如改了函数却报未定义），加个
-cache：go clean -cache -modcache - 清理后不要立刻跑
go build main.go—— 它会跳过子包编译，继续用残留的旧.a，应改用go build ./或go install ./
GOSUMDB=off 导致 checksum mismatch 时不能只删 go.sum
当看到类似 verifying module: checksum database disabled by GOSUMDB=off 或 checksum mismatch，说明本地缓存里的模块内容和远程不一致，但工具又没校验机制兜底。这时候只删 go.sum 是无效的，因为 go mod tidy 会从坏缓存里读出旧内容，再算一遍“错的”校验和。
正确顺序是：
– 先 go clean -modcache
– 再 rm go.sum（可选，tidy 会重建）
– 设置代理加速（国内用户）：go env -w GOPROXY=https://goproxy.cn,direct
– 启用校验（推荐）：go env -w GOSUMDB=gosum.io+ceip
– 最后 go mod tidy
go build 仍报 undefined，说明 pkg 缓存没刷新
即使模块缓存清了，go build main.go 这种写法仍可能复用 $GOROOT/pkg 或 $GOMODCACHE 下已编译好的 .a 文件，尤其当你修改的是被其他包 import 的 helper 函数时。这不是模块问题，是构建缓存没被触发更新。
必须做：
– 改用 go build -a ./（-a 强制重编所有依赖）
– 或直接 go install ./（它会递归编译并更新 .a 缓存）
– 如果知道具体出问题的包路径，例如 github.com/my/project/helper，可单独重装：go install github.com/my/project/helper
模块缓存和构建缓存是两层东西，清理 -modcache 不等于清理 .a；很多“改了代码不生效”的问题，卡在这第二层。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
