Go cmd/go 的 fuzz_modcache 测试为什么会抖动：模块缓存与测试隔离边界

CI 里看到 TestScript/test_fuzz_modcache 偶尔失败，很容易把锅甩给 fuzz 的随机输入。Go 官方测试真正关心的却是另一件事：模块缓存里的包在主模块外，能不能读取已有 fuzz corpus，以及一次失败的模糊测试会不会把共享缓存和校验记录弄脏。这个测试在不同操作系统、缓存权限和路径规则下呈现的日志不同，所以看起来像“抖动”。

先把问题拆成三层：go test 是否读到了外部模块、GOMODCACHE 是否可写、go mod verify 是否仍能证明缓存完整；不要用一次失败日志直接判断 fuzz 引擎不稳定。

先把 fuzz_modcache 的失败读成什么

Go 官方的 test_fuzz_modcache.txt 先固定 GOFLAGS=-modcacherw，再把 example.com/fuzzfail 当作主模块之外的依赖。没有 corpus 时，普通 go test 应该通过，而 go test -fuzz=. 应该在真正启动 fuzz 前被拒绝；带有 corpus 的版本则应读取已有语料，但仍拒绝对外部模块直接做 fuzz。

这条设计边界是为了防止失败样本被写回依赖模块的缓存。测试还用 go mod verify 检查模块内容和校验信息没有被破坏。也就是说，日志里出现“找不到 corpus 文件”时，首先要问的是模块包是否完整、路径是否能被当前平台解析，而不是先增加 fuzz 时间。

为什么不同机器会得出不同结论

同一份脚本在不同环境里出现不同日志，通常有三个来源。第一，模块缓存可能只读，也可能因为用户权限而可写；官方脚本显式加入 -modcacherw，就是把这个变量固定住。第二，Windows 路径的分隔符和临时目录层级会进入错误文本，导致脚本的严格输出匹配更容易失效。第三，依赖版本是否真的带着 testdata/fuzz 目录，会决定普通测试是在读取 corpus 后失败，还是根本找不到文件。

按四层证据缩小故障范围

第一层看工具链和工作区：记录 go version、go env GOMODCACHE、go env GOFLAGS，确认测试没有悄悄切换到另一套工具链。Go 1.21 起，go 命令会根据 go.mod、go.work 和 GOTOOLCHAIN 选择工具链，环境差异会影响模块操作的前置条件。

第二层看依赖落点，用 go list -m -f '{{.Dir}}' example.com/fuzzfail 确认实际目录，再检查该版本是否包含 testdata/fuzz。第三层在独立临时目录里复现，显式设置一个新的 GOMODCACHE，不要覆盖开发机已有缓存。第四层只用 go mod verify 做收尾证据，同时核对依赖目录里的 校验文件：它通过，才说明本轮检查没有留下缓存篡改痕迹。

env GOFLAGS=-modcacherw \
  GOMODCACHE="$PWD/.cache/mod" \
  go test -fuzz=. example.com/fuzzfail

go env GOMODCACHE GOFLAGS GOTOOLCHAIN
go mod verify

这里的重点不是照抄官方测试命令，而是让每个结论都对应一个独立证据：工具链负责回答“用谁运行”，模块目录回答“读了什么”，缓存变量回答“能否写入”，完整性检查回答“是否留下副作用”。

修复动作应该落在测试隔离层

如果 CI 只是为了验证 Go 工具链行为，最稳妥的做法是为该任务提供独立的临时 GOMODCACHE，并在任务结束后销毁它。需要复现官方脚本时，保留 GOFLAGS=-modcacherw，让权限条件固定；需要验证只读场景时，再单独建一个只读缓存用例，不要让两种条件共享同一目录。

不要把 go clean -modcache 当成默认修复，它会扩大影响面，也可能掩盖依赖包缺文件、代理返回异常或路径处理问题。若是脚本只因一行平台相关输出没有匹配，先确认测试预期是否写得过窄；若 go mod verify 真的失败，再升级为缓存污染或下载链路故障处理。

相关问题

fuzz_modcache 失败是不是 fuzz 随机性导致的？

不一定。官方测试主要验证外部模块的 corpus 读取、-fuzz 拒绝和模块缓存完整性；Windows 上还可能叠加路径差异。

为什么要设置 GOFLAGS=-modcacherw？

为了固定模块缓存的写入前提，避免 root 或不同平台的权限差异改变测试结果。

应该先清理全局模块缓存吗？

不应该。先用独立 GOMODCACHE 复现并运行 go mod verify，只有确认缓存本身损坏后再处理具体目录。

把“测试脚本没匹配到输出”和“模块缓存真的被破坏”分开，通常就能解释这类看似抖动的 CI 失败。对 cmd/go 来说，可重复性首先来自隔离工作目录、固定权限和可核验的依赖内容。