go运行结果未更新是因gocache缓存机制复用旧.a文件，非vscode缓存所致；需执行go clean -cache、改用go run .或go run -a .强制重编译，并检查vendor、replace及go111module配置。
Go 是编译型语言，VSCode 运行 go run 或调试时结果没变，根本不是“VSCode 缓存”在作怪，而是 Go 自己的构建缓存机制（GOCACHE）复用了旧的中间对象 —— 即使源码改了，只要签名没变，它就直接链接旧的 .a 文件。
为什么 go run 有时不重新编译？
Go 的 GOCACHE 默认启用（路径通常为 $HOME/Library/Caches/go-build（macOS）、%LocalAppData%\go-build（Windows）或 ~/.cache/go-build（Linux）），它会缓存每个包的编译产物（.a 文件）并基于源码哈希+编译参数做签名比对。但某些修改不会触发签名变化：
- 注释增删、空行调整、未被引用的变量名变更
- 只改了
main.go但依赖包（如utils/）没变，而该包已被缓存且未被重新扫描 - 用
go run main.go而非go run .，导致 Go 不递归检查子包，跳过依赖重建 - 启用了
-gcflags="-l"等调试标志后缓存失效策略不同，但后续未清理就切回默认构建
如何强制刷新 GOCACHE 并确保执行最新逻辑？
不要只清 VSCode 缓存（那对 Go 编译无用），重点操作 Go 本身的缓存与构建行为：
- 运行
go clean -cache：清空GOCACHE目录，这是最直接有效的一步 - 改用
go run .（注意是英文句点）：让 Go 从当前目录递归识别所有包，确保依赖包也被纳入构建图 - 加
-a参数强制重编译所有依赖：go run -a .，绕过签名校验，适合调试阶段 - 临时禁用缓存验证：
GOCACHE=off go run .，确认是否真由缓存引起（仅用于排查）
VSCode 配置里容易踩的坑
如果你用的是 VSCode 的 Go 扩展（如 golang.go）配合调试或 Code Runner，这些配置会让问题更隐蔽：
-
go.gopath或go.toolsGopath设置错误，导致扩展调用的是旧 GOPATH 下的二进制而非当前模块 -
launch.json中program指向了已存在的可执行文件（如./bin/app），而非动态go run，改代码后必须手动go build才更新 - 启用了
"go.useLanguageServer": true但 LSP 缓存未同步，此时可尝试命令面板执行Go: Restart Language Server - Code Runner 插件默认执行
go run $fileName，应改为go run .并在插件设置中勾选 “Run in Terminal” 以避免静默失败
Go Modules 下仍出问题？检查 go.sum 和 vendor
即使用了 go mod，也可能因以下原因执行旧逻辑：
-
go.sum锁定的是依赖版本，但本地vendor/目录若存在且未更新（比如go mod vendor后又改了go.mod却没重 vendor），Go 会优先读vendor/里的旧代码 - 某个依赖包被
replace到本地路径，而该路径下代码未git pull或未保存，go run仍用旧副本 -
GO111MODULE=off环境变量意外开启，退回到 GOPATH 模式，导致模块感知失效
真正关键的判断点在于：你改的那行代码，是否真的进入了最终链接的包路径里 —— go list -f '{{.Stk}}' ./... 或 go build -x . 输出里能看到实际参与编译的 .go 文件列表，这是唯一可信依据。
