Go go test 测试环境变量改变但缓存没有失效怎么办

如果你修改了测试环境变量，却仍然看到 (cached)，先不要急着删除整个 Go 缓存。go test 在包列表模式下会缓存成功的测试结果；只有测试实际读取的环境变量发生变化时，这个输入才会影响后续命中。排障时最直接的办法是给本次命令加上 -count=1，明确要求重新执行。

官方地址：https://go.dev/cmd/go/

可以把问题拆成三件事：变量是否传给了测试进程、测试是否读取了它、这次是否需要无条件重跑。

• 只改了未被测试读取的变量，不一定改变缓存键。
• 把 MODE=slow 写在命令后面，它可能只是测试参数，不是环境变量。
• 需要一次新结果时，优先使用 go test -count=1 ./...。

先分清 go test 缓存了什么

go test ./... 不只是编译测试文件，还会运行每个包对应的测试二进制。官方文档说明，包列表模式会缓存成功的包测试结果；再次运行时，如果测试二进制和可缓存参数都匹配，命令可能直接显示之前的结果，并在摘要里写出 (cached)。

因此，看到缓存并不代表“所有环境变量都被忽略”。测试缓存关注的是本次测试真正使用的输入。源码、测试文件、测试参数和测试读取的文件或环境变量没有变化时，成功结果才可能继续复用。构建缓存和测试结果缓存也不是同一层：清理构建缓存不等于清理已经记录的测试结果。

为什么环境变量变了，缓存仍可能命中

最常见的误区是把“shell 中有一个变量”当成“测试一定读取了这个变量”。下面的写法才会把变量传给启动的测试进程：

package config_test

import (
    "os"
    "testing"
)

func TestMode(t *testing.T) {
    // 测试通过 os.Getenv 读取外部输入，模式才成为测试行为的一部分。
    mode := os.Getenv("APP_MODE")
    if mode == "" {
        t.Fatal("APP_MODE 未设置")
    }
}

# 变量放在命令前，才会进入测试进程的环境。
APP_MODE=slow go test ./...

# 变量改变后，显式要求本次不使用成功测试结果缓存。
APP_MODE=fast go test -count=1 ./...

如果测试没有调用 os.Getenv("APP_MODE")，而你只改变了 APP_MODE，它就不是这个测试结果的实际输入。另一个常见错误是把 APP_MODE=fast 放到 go test ./... 后面；那通常会被解释为传给测试二进制的参数，而不是 shell 环境设置。CI 中还要注意变量是否写在正确的 job、step 或容器环境里。

用 -count=1 得到一次确定的新结果

当你正在排查外部配置、时间、随机种子或测试数据变化时，不需要先清理整台机器的 Go 缓存。官方推荐的显式禁用测试缓存写法是：

# -count=1 只影响本次 go test 调用，便于排查外部输入变化。
go test -count=1 ./...

# 同时注入环境变量，避免依赖当前 shell 的隐式状态。
APP_MODE=fast go test -count=1 ./...

-count=1 的价值是把“本次要不要重新跑”说清楚。它不会修改测试代码，也不会删除模块下载缓存；下次去掉它后，go test 仍可按正常规则复用成功结果。若只想确认某个包，也可以将 ./... 换成明确的包路径，缩小排查范围。

什么时候需要 go clean -testcache

如果团队希望让后续正常命令都暂时看不到以前的成功测试结果，可以使用：

# 只让已缓存的测试结果过期，不删除构建产物和模块下载内容。
go clean -testcache

# 清理后再按默认规则运行所有包测试。
go test ./...

这个动作的影响范围比 -count=1 大，但仍然只针对测试结果缓存。它适合本地统一清理或复现缓存相关问题，不适合把每次 CI 测试都写成固定清理。若只是当前一次环境变量排障，优先使用 APP_MODE=值 go test -count=1 ./...，更容易保留问题现场。

排查结论可以这样记录

最后记住：环境变量只有在真正成为测试输入时，改变它才有机会影响缓存判断；需要确定地排除缓存时，-count=1 是最小、可回滚的开关。

相关问题

为什么 go test 输出会出现 (cached)？

通常表示包列表模式复用了以前成功的测试结果，而不是本次重新启动测试二进制。

go clean -cache 能代替 go clean -testcache 吗？

不能混为一谈。前者清理整个 Go 构建缓存，后者让测试结果过期；只处理测试缓存时使用后者更准确。