go build 没用新代码是因为默认复用缓存的.a文件，改了源码但未强制重编译依赖；应执行go build ./或go install ./触发全量依赖重建，必要时配合go clean -modcache清理模块缓存。

go build 为什么没用新代码？

因为 go build 默认复用已编译的依赖包（.a 文件），尤其当这些包曾被 go install 缓存到 $GOPATH/pkg/ 或构建缓存中时。你改了 server.go，但 main 仍链接旧版 server.a，结果就是“代码变了，行为没变”。这不是 bug，是 Go 增量构建的设计逻辑。

常见现象包括：

• undefined: xxx —— 新增函数/变量不被识别
• 日志或返回值仍是旧逻辑 —— 修改未生效
• go mod tidy 没输出、不拉新版本 —— 缓存干扰模块解析

强制重编译所有依赖的可靠方式

别只跑 go build main.go，它脱离项目上下文，无法触发依赖重建。正确做法是：在项目根目录（含 go.mod）执行：

• go build ./ —— 构建当前目录下所有包（含子目录），强制检查并重编译所有依赖源码
• go install ./ —— 更彻底：编译 + 写入 pkg/ 缓存 + 生成可执行文件，后续 go build 才能拿到最新版
• 若只想更新某依赖包（如 github.com/yourname/utils），进入其目录后运行 go install

注意：必须用绝对导入路径（如 import "github.com/yourname/utils"），不能用 ./utils 或 utils，否则 Go 无法定位模块边界。

模块缓存污染时怎么清理

当 go mod tidy 静默失败、私有库认证反复报错、或项目重命名后依赖解析异常，大概率是 $GOMODCACHE（默认 $GOPATH/pkg/mod）里存了旧路径/损坏数据。

安全清理步骤：

• 先查缓存位置：go env GOMODCACHE
• 清空模块缓存：go clean -modcache（不要手动删目录）
• 重新下载依赖：go mod download 或直接 go mod tidy
• 验证完整性：go mod verify（检查 go.sum 校验和是否匹配）

如果只是临时调试，可加环境变量绕过校验：GOSUMDB=off go mod download，但上线前务必恢复。

替换本地依赖调试时的坑

用 replace 指向本地修改版时，容易忽略两个关键点：

• replace 只影响当前模块，下游依赖不会自动继承 —— 若其他包也 import 同一模块，它们仍走远程版本
• 本地路径必须是完整绝对路径，或相对于 go.mod 的相对路径；写错会导致 go build 报 cannot find module
• 调试完必须删掉 go.mod 中的 replace 行，否则提交后 CI 会失败

示例正确写法：replace github.com/xxx/lib => ../lib（../lib 是相对于 go.mod 的路径）。

真正麻烦的不是缓存本身，而是缓存和模块路径、导入语句、构建命令三者之间的耦合关系——改一处，另外两处没同步，问题就藏得极深。