Go race detector 报告中的 goroutine 创建栈怎么看

Go race detector 报告里的 goroutine 创建栈用于回答“这个任务从哪里启动”，冲突访问栈用于回答“哪个读写操作发生了竞态”。先根据 goroutine 编号把两者配对，再沿共享对象寻找同步责任。不要只看报告最后一个创建位置，就把那条 go 语句当成错误写入的位置。

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

内存模型：https://go.dev/ref/mem

接口目标：分清访问位置和启动位置

一份竞态报告包含两种上下文。访问栈展示参与冲突的读写及其调用链；创建栈展示相关 goroutine 的启动来源。前者适合定位字段、切片元素或映射访问，后者适合找到是谁创建并持有这些任务。

两次访问可能出自同一个函数，但来自两个不同任务；两个创建栈也可能落在同一条循环中的 go 语句。位置相同并不表示没有并发，创建位置不同也不表示访问了不同对象。

调用方需求：先对齐 goroutine 编号

阅读时先记下访问栈A所属的 goroutine A，再找到它的创建栈；对访问栈B和 goroutine B做同样的配对。接着确认两次访问针对哪个共享字段。图中的创建栈概括两个任务各自的创建信息，不代表报告只有一条创建调用链。

编号只在当前报告上下文中使用，不应保存成稳定业务标识。看到某个任务已经结束，也不能据此排除竞态：检测器报告的是捕获到的冲突，任务后来退出不等于当时的访问受到了同步保护。

若创建链中出现测试框架、通用任务池或包装函数，继续寻找靠近业务代码的启动层。框架负责调度不意味着框架拥有你的共享状态，修复位置还要结合对象的访问接口判断。

参数设计：追踪共享对象的身份

goroutine 的参数按值传递，不代表参数引用的底层数据被深拷贝。传入同一个指针，两个任务仍然指向同一对象；复制切片描述符仍可能共享底层数组；闭包也可能捕获外层变量。因此创建栈的价值在于帮助你回到启动函数，弄清任务参数究竟携带了什么。

可以围绕调用方列出三个事实：对象在哪里创建、哪些任务得到它、这些任务使用哪些访问方法。如果接口承诺允许并发调用，就应明确状态保护；如果只允许单任务使用，则应在调用方建立清晰的所有权。不要仅通过把指针改成值参数宣称问题已解决，结构体内部仍可能含引用类型。

错误处理：把同步放到完整访问边界

数据竞争不是普通返回错误，不能靠忽略报告或重试调用消除。对同一状态使用互斥锁时，相关读写都需要遵守同一保护协议；只给写入加锁、读取仍裸读，不能建立完整保护。也可以通过通道传递所有权，或者为任务提供不再变化的独立快照，具体取决于接口语义。

WaitGroup 用于等任务完成，不能让两个同时运行的递增操作互斥。主任务在 Wait 返回后读取结果，与两个工作任务在 Wait 返回前互相修改状态，是两件不同的事。增加 Sleep、调整启动先后或扩大机器资源，都不构成同步修复。

下图按接口责任组织实体：调用方使用启动函数，启动函数组织任务参数，任务参数引用共享对象；访问方法与互斥锁共同定义共享对象的保护范围。这些连线表达静态关系，不代表执行顺序。

兼容策略：理解报告的观察范围

race detector 是运行时检测工具，只能发现实际执行路径中发生的竞争。一次没有报告，不能证明所有输入、路径和并发负载都安全。用测试覆盖代表性并发路径，比单纯反复运行空闲场景更有意义。

# 在支持 race detector 的环境中，对目标包启用检测
go test -race ./...
# 需要重复观察时增加运行次数；无报告仍不等于完整证明
go test -race -count=10 ./...

如果报告无法恢复完整栈，官方提供的 history_size 配置可以调整每个 goroutine 的访问历史容量，但会增加内存开销；它影响检测器记录能力，不会为业务读写添加同步。这里无需为了“让创建栈更清楚”就盲目修改运行参数。

示例：两个启动入口共享一个计数器

下面是刻意保留数据竞争的教学片段，不应直接用于业务。两个启动入口共享同一指针，访问栈会帮助定位 bump 内的递增，创建栈则帮助回到启动这些任务的位置。具体报告编号、栈帧和是否出现某个冲突组合取决于实际运行；本文不提供伪造的运行输出。

package raceexample

import (
    "sync"
    "testing"
)

type counter struct {
    value int
}

func bump(c *counter, wg *sync.WaitGroup) {
    defer wg.Done()
    for i := 0; i 

若计数器应允许多个任务调用，可以把锁和状态一起封装，并要求所有访问通过方法完成。下面是独立的修复版本，替换上面的示例使用；不要把两个同名测试文件同时放入一个包。

package raceexample

import (
    "sync"
    "testing"
)

type counter struct {
    mu sync.Mutex
    value int
}

func (c *counter) add() {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.value++ // 完整读改写操作由同一把锁保护。
}

func (c *counter) load() int {
    c.mu.Lock()
    defer c.mu.Unlock()
    return c.value // 读取也遵守相同的保护协议。
}

func TestSharedCounter(t *testing.T) {
    c := &counter{}
    var wg sync.WaitGroup
    work := func() {
        defer wg.Done()
        for i := 0; i 

这个版本把同步放在共享对象的方法中，调用方仍然负责启动和等待任务。含锁的计数器应通过指针使用，使用后不要复制包含互斥锁的对象。实际项目还要确认没有其他代码绕过方法直接访问 value。

为什么创建栈没有指出应加哪把锁？它提供启动来源，不承担接口设计判断。需要结合访问栈和对象共享方式决定保护责任。

把 go 语句删掉就算修复吗？串行执行可能消除该并发场景，但也改变接口行为。应先确认业务是否允许串行，再选择同步、所有权传递或独立快照。

遇到这类报告，先定位冲突访问，再用创建栈寻找任务来源，最后把对象身份与同步协议连起来。修复应解释为什么相关访问具有明确的同步关系，而不是只让一次运行不再报警。