go test 默认启用测试缓存，修改代码后仍显示pass是因为直接返回上次缓存结果；需加 -count=1 参数强制重新执行，vscode中可通过设置 go.testflags: ["-count=1"] 全局禁用。
Go test 为什么改了代码但测试还是通过？
因为 go test 默认启用测试缓存（test cache），只要输入（源码、依赖、构建参数）没变，就直接返回上次缓存结果——哪怕你刚删掉一个 return true 改成 return false，它也照过不误。
这不是 VSCode 的 bug，是 Go 原生行为；VSCode 的「Run Test」按钮底层调用的就是 go test，所以缓存一样生效。
- 典型现象：修改函数逻辑后，右键 Run Test 或点击测试旁的 ▶️ 图标，结果仍是 PASS，
go test -v手动运行也一样 - 验证是否命中缓存：加
-count=1参数强制不缓存，如go test -v -count=1，此时会真实重新执行 - 缓存位置在
$GOCACHE（通常是$HOME/Library/Caches/go-build或%LOCALAPPDATA%\go-build），但一般不需要手动清
VSCode 中禁用 Go test 缓存的两种可靠方式
不能只靠重启 VSCode 或重载窗口，必须让 go test 命令本身带上禁用缓存的参数。
- 全局禁用（推荐调试阶段）：在 VSCode 设置中搜索
go.testFlags，将其值设为["-count=1"]—— 这会让所有测试都跳过缓存 - 临时禁用单次运行：右键测试函数 → 「Run Test (no cache)」（如果安装了
golang.go插件 v0.38+，该选项默认存在；否则需升级插件） - 注意：不要设
-gcflags="all=-l"或-race来“顺便”禁缓存，它们不保证绕过缓存，且可能掩盖真实问题
为什么 go test -a 不解决这个问题？
-a 只强制重新编译所有依赖包（包括标准库），但不触碰测试结果缓存。Go 的缓存是按「测试输出哈希」判定的，和编译动作无关。
-
go test -a -count=1✅ 同时满足：重编 + 不缓存 -
go test -a❌ 仍可能从缓存读结果 - VSCode 的
go.testEnvVars里设GOCACHE=off无效——Go 1.21+ 已废弃该环境变量，仅支持命令行参数控制
CI/CD 或团队协作时要注意什么？
本地关缓存是调试需要，但 CI 脚本里不该长期加 -count=1，否则会拖慢整体测试时间。真正要保障的是「可重现性」：
- 确保
go.mod和go.sum提交，避免依赖漂移影响缓存哈希 - 禁止把
go test命令硬编码在 Makefile 或 GitHub Actions 中却不带-count=1—— 这会让 CI 偶尔“漏测”逻辑变更 - 如果用了
gopls，它的语义分析不受缓存影响，所以保存即报错的提示（比如类型不匹配）依然可靠；但「运行测试」这个动作，完全由go test自己决定是否缓存
缓存本身不是敌人，但当你在改逻辑、写断言、排查条件分支时，它会变成最安静的干扰项——关掉它，比猜它有没有生效，省事得多。
