Go 测试发现数据竞争为什么不等于测试失败原因

数据竞争本身就是 Go race 测试失败的充分原因。标题里的“不等于”只适用于另一层判断：出现竞争报告，不能仅凭日志相邻就认定它解释了某条业务断言失败、超时或 panic。测试进程可能同时存在多个问题，需要分别定位，不能把 race 当成可以忽略的提示。

官方地址：https://go.dev/doc/articles/race_detector

先确认 race 本身就是失败条件

启用 -race 后，检测器观察实际执行中的内存访问。检测到缺乏必要同步的冲突访问时，会给出报告。即使业务断言碰巧得到期望值，也不代表这一轮测试可以算作成功。

testing 的实现会把测试执行期间检测到的竞争记为失败；在测试执行范围之外发现的竞争，也可能使包的最终结果失败。因此，“没有哪一行 t.Fatal 被调用，为什么包仍然 FAIL”并不矛盾。应先保留竞争报告，而不是只寻找断言语句。

# 让读者在目标项目执行；关闭结果缓存便于观察本轮执行。
go test -race -count=1 ./...

这是复现命令示例，本文没有在本地运行项目或生成终端截图。检测器支持的平台与环境以官方文档为准；不要把普通测试的成功记录当成启用 race 后的记录。

分开记录断言与竞争两类证据

一个测试用例可能同时有断言失败与数据竞争。两者可能有因果关系，也可能分别来自不同共享状态。例如断言因输入预期写错而失败，后台缓存刷新又碰巧出现竞争。只修缓存竞争不一定会改变错误预期。

排查记录应至少保留：业务断言的实际值与期望值、竞争报告里的冲突访问位置、相关协程创建位置，以及测试名和运行参数。先建立证据，再判断是否属于同一缺陷。

读取冲突访问和创建栈

报告通常给出两侧冲突访问的调用栈，以及相关协程在哪里创建。首先定位同一内存对象：是字段、闭包捕获变量，还是共享集合中的内容？然后分析两次访问中哪次写入、各自拥有什么同步约束。

协程编号用于区分报告中的执行者，不是稳定业务身份。创建栈说明任务从哪里启动，冲突栈说明任务在哪个访问点产生问题；两类位置都要保留。栈上出现某个测试名，也不能免除对其他后台任务和共享全局状态的分析。

定位目标是明确同步协议：哪个时刻允许读，谁负责写，谁保证写入结束。仅靠增加休眠时间改变调度，可能让一次运行不再报告，却没有建立同步关系。

用明确同步修复共享访问

以下两个原创测试分别展示一次性结果发布和多写者共享计数。把它们保存在测试文件中即可使用：前者等待完成通道，后者用同一把锁保护写入，再等待所有任务完成。它们是正确同步的示例，不是故意制造竞争的运行记录。

package sample

import (
    "sync"
    "testing"
)

func TestPublishedResult(t *testing.T) {
    done := make(chan struct{})
    var result int
    go func() {
        // 用完成通道发布结果，关闭之后不再修改 result。
        result = 42
        close(done)
    }()
    

完成通道适合一个写者完成后再读取的场景；如果关闭通道后写者继续修改同一变量，示例的安全前提就不成立。Mutex 适合共同管理多次共享访问，但必须覆盖全部相关访问，不能只给某个写者加锁。

WaitGroup 用来等待任务完成。它不能单独让两个仍在运行的写者互斥；示例里 count++ 仍需要锁。修复后应分别关注原有断言是否成立，以及相同路径是否仍报告竞争，避免把两个目标混成“日志看起来干净”。

保持 TestMain 与后台任务边界

如果项目使用 TestMain，初始化和清理过程也可能启动后台任务。应明确停止方式并等待其退出，避免它跨过测试边界继续读写共享数据。某个用例已经返回，不代表它启动的协程自动结束。

TestMain 应保留 m.Run 的结果。官方文档允许直接调用 m.Run 后返回，由测试包装器使用其结果退出；需要显式退出时可使用它返回的状态码。不要把退出码写死为零来掩盖失败，也不应把这当成修复竞争的方法。

从调用方接口看，后台组件最好提供清楚的启动、停止、等待完成约定。错误模型则分开保留业务错误、同步问题和进程最终状态，便于在测试失败时找到对应责任对象。

不开 -race 就通过，是否可以忽略报告？

不能。普通构建没有启用相同检测能力，执行时间也可能不同。竞争需要修复，而非通过换命令隐藏。

一次没有报告，能证明修好了吗？

不能覆盖所有未执行路径。应把同步关系说明清楚，并让有代表性的并发场景覆盖相关访问。

所有断言都对但最后 FAIL，先看什么？

保留完整日志，检查竞争、后台任务与 TestMain 的执行结果。测试框架的失败不只来自业务断言。

参考：Go Data Race Detector、TestMain 官方说明、testing 竞争失败处理源码。