Go race 未报告数据竞争的覆盖边界

go test -race 没有报告，只能说明这次实际执行的范围中没有被检测器报告的数据竞争，不能据此证明整个程序并发正确。先确认目标包与测试确实运行，再检查异常分支是否触达、读写是否共享同一实例，以及测试是否建立了过强的串行顺序。

官方说明：https://go.dev/doc/articles/race_detector

触发信号：无报告却仍有并发异常

设想排查一个共享计数模块：单元测试没有 race 报告，集成调用却偶尔丢失业务更新。我会先把“检测无报告”和“结果正确”分成两条判断，而不是立刻增加等待时间。这里是原创排查场景，不是已经在本文项目中复现的故障记录。

数据竞争关注缺少适当同步的共享内存访问；业务异常还可能来自多个独立正确操作之间的逻辑空隙。例如查询余额与扣减各自受锁保护，却没有把整项条件更新放在同一个临界区，仍可能违反业务约束。检测器与业务断言的任务不同。

快速判断：测试范围与实际路径

检测器观察运行时发生的访问。目标代码没有执行，就不能期待它发现那条路径中的竞争。包选择、测试过滤、提前返回、环境条件和替代实现，都可能让预期中的读写没有发生。

还应查看构建标签与替代文件。带 race 的构建会定义相应标签；若某个测试或实现被排除，结果就不能代表被排除的代码。应记录排除理由并提供适合该路径的测试方式，而不是把排除后的成功当作问题消失。

处理步骤：让读写共享同一实例

下面示例将对象创建放在工作方外部，读写共享同一个指针，用启动通道提供共同入口，用 WaitGroup 等待完成。counter 本身带锁，示例展示的是正确组织并发用例的结构；迁移到真实排障时，需要改为调用实际组件，而不是另写一个始终正确的替身。

package state

import (
    "sync"
    "testing"
)

// counter 是完整演示对象；真实项目应调用自己的共享组件。
type counter struct {
    mu sync.Mutex
    n  int
}

func (c *counter) Add() {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.n++
}

func (c *counter) Value() int {
    c.mu.Lock()
    defer c.mu.Unlock()
    return c.n
}

func TestSharedCounter(t *testing.T) {
    c := &counter{} // 只创建一次，读写方共享同一指针。
    start := make(chan struct{})
    var wg sync.WaitGroup
    wg.Add(2)

    go func() {
        defer wg.Done()
        

将这段完整示例保存为相应包中的 counter_test.go 后，可使用下面的命令。命令与代码均为建议用法，本文没有执行，也没有生成或虚构检测报告。

# 在模块根目录运行；包范围以实际项目为准。
go test -race -count=1 ./...

# 针对本文演示测试增加重复次数和调度配置。
# 真实项目需换成目标包路径及自己的测试名。
go test -race -run '^TestSharedCounter$' -count=20 -cpu=1,2,4 .

共同入口并不能强制每次访问发生特定交错，更不是穷举调度。它只是避免测试先完成全部写入、再运行读取。WaitGroup 则保证断言发生在工作方完成之后；不要把“等待最终结束”误认为它已经保护了两个工作方内部的共享访问。

第一次全范围命令用于了解当前模块的包覆盖；重复运行目标用例用于增加执行机会。count=1 明确禁止复用成功测试结果，count=20 重复运行用例，cpu 参数选择不同 GOMAXPROCS 值。这些次数是示例配置，不对应某个“覆盖充分”的阈值。

如果目标代码只在服务集成路径出现，可以在受控环境中让带 race 的构建接受有代表性的负载。不要只重复同一条永远不进入异常分支的请求；应把重连、取消、初始化交接或对象替换等实际条件纳入用例。

回滚路径：先隔离并发入口再修复同步

发现可疑共享对象时，短期可以通过项目已有开关停用新增并发路径，或回退到已知可用的串行实现，同时记录对吞吐和延迟的影响。这是业务处置选择，不应把关闭 race 检测当成修复。

代码修复应依据数据所有权与操作契约：同一把锁保护相关读写，或将状态交给单个拥有者管理。若多个字段共同构成约束，锁的范围应包含整项操作；只给单个字段换成原子读写，并不自动保证整个业务事务正确。

不要用 time.Sleep 为共享访问建立正确性。延时改变执行机会，不建立所需的同步关系。修复后的用例应保留真实并发入口，同时检查业务结果，避免测试为了稳定通过而把待查路径全部串行化。

确认结果：将检测报告与业务断言分开

一条结论至少需要两类信息：运行的检测任务是否完成，以及业务断言是否成立。出现 race 报告时，应关注冲突访问位置与相应工作方；业务断言失败但没有报告时，也应继续排查状态约束与覆盖条件。

最终计数断言是本文示例的业务判断，检测器则关注执行中的访问关系。对于库存、任务去重或缓存替换，还需要定义各自的不变量；不能因为所有读写都使用了锁或原子操作，就省略结果判断。

记录无报告结果时，采用“指定构建、包范围、负载与次数下未观察到报告”的表述；不要写成“全部线程安全”。也不要把编译失败、用例被跳过或根本没有匹配测试的执行归入同一种成功结果。

复盘项：留下覆盖条件与相关问答

保留目标代码版本、模块范围、构建标签、测试名、输入条件、共享对象创建位置和运行参数。下一次修复时，这些信息比单独一张绿色成功标记更容易说明结论适用于哪里。性能测量应另行设计，检测构建的运行特征不应直接当作普通发布构建的性能结论。

测试覆盖率高，是否就不需要补并发用例？

语句执行与并发条件是两个维度。同一行被执行，并不说明实际共享对象的读写关系已经覆盖。

增加 count 能否保证发现全部竞争？

不能。更多次数增加观察机会，却不能补上未调用的分支，也不能穷举所有调度。

测试读写没有在墙钟时间上重叠，就一定没有问题吗？

不要只按肉眼看到的时间先后来判断。应根据 Go 内存模型中的同步关系分析访问；日志时间和睡眠都不能代替正确的同步设计。

资料：Go 数据竞争检测器；Go 测试参数；Go 内存模型。