go test 在 CI 中需显式设 GO111MODULE=on、-mod=readonly、-timeout=60s，按 module 分别测试，用 -json 输出结构化日志，避免 Alpine 镜像跑 -race，外部服务改用容器名，时间相关测试注入可控时钟。
Go test 命令如何在 CI 中稳定运行
CI 环境里 go test 失败，八成不是代码问题，而是环境或命令用法不一致。本地能过、CI 报错，常见于未清理测试依赖、并发干扰、或忽略了 -mod=readonly 导致自动写 go.sum。
- 始终显式指定
GO111MODULE=on，避免因 CI 环境 Go 版本差异触发 GOPATH 模式 - 使用
go test -mod=readonly -race -vet=off ./...：禁用自动模块修改，开启竞态检测，关闭冗余 vet（CI 中 vet 通常由 linter 单独跑） - 避免
go test ./...在根目录直接执行——若项目含多个 module（如/cmd、/internal、/api），应按 module 分别测试，否则可能漏测或误加载 - 超时必须设限：
go test -timeout=60s，防止某个测试卡死阻塞整个流水线
如何让测试结果可读且可追踪
CI 不只需要“通过/失败”，还需要知道哪条测试挂了、耗时多少、是否 flaky。原生 go test -v 输出对机器不友好，需转换为标准格式。
- 用
go test -json ./...生成结构化日志，主流 CI（gitHub Actions、gitlab CI）都能解析并展示失败用例详情 - 避免重定向 stderr/stdout 混合输出，直接用
-json而非2>&1 | jq类管道——JSON 流是逐行的，管道易截断或乱序 - flaky 测试要隔离：给不稳定测试加
//go:build !ci构建约束，并在 CI 中跳过（go test -tags=ci ./...），再单独建 job 定期重试验证 - 覆盖率上传前必须归一化路径：CI 中工作目录常为
/home/runner/work/repo/repo，而本地是/Users/me/code/repo，上传前用sed 's|/home/runner/work/[^/]*/[^/]*/||g'清洗coverprofile文件路径
Go 测试与 docker CI 环境的典型冲突点
Docker 镜像里跑 go test 很常见，但默认镜像（如 golang:1.22-alpine）缺调试工具、DNS 配置异常、或 cgroup 限制导致 -race 失败。
- Alpine 镜像慎用
-race：musl libc 与 race detector 兼容性差，CI 中建议切回golang:1.22（debian base） - 测试中调用外部服务（如 redis、postgresql）时，不要用
localhost:6379——Docker 容器内 localhost 是自身，应改用redis:6379并确保 network 连通 - 文件系统权限问题：Alpine 默认以 root 运行，但某些测试用
os.UserHomeDir()或写临时目录，需提前mkdir -p /tmp/testdata && chmod 777 /tmp/testdata - 时间相关测试易失败：Docker 容器可能没同步 host 时间，
time.Now().unix()在秒级测试中偏差超预期，应统一用testify/mock或clockwork注入可控时钟
go test -mod=readonly -json -race -timeout=60s -covermode=count -coverprofile=coverage.out ./... 2>/dev/null | go run github.com/ory/go-acc@latest -out coverage.html复杂点不在写测试，而在让每次 go test 在不同环境里行为一致。路径、模块模式、并发模型、时钟、网络目标——这些隐性依赖比业务逻辑更难收敛。
立即学习“go语言免费学习笔记（深入）”；