不能。Claude无法直接检测Go data race，因不运行go run -race、不接入本地环境、不能执行二进制或读取竞态报告；仅能基于用户提供的代码片段、错误日志及并发结构描述做静态推断。
Clayde 能直接检测 Go data race 吗
不能。claude 本身不运行 go run -race，也不接入本地构建环境，它无法执行二进制、读取竞态报告或观察 goroutine 调度行为。它能做的，是基于你提供的代码片段、错误日志（比如 fatal error: concurrent map writes 或 warning: data race 输出）、以及你描述的并发结构，进行静态逻辑推断。
实际中更可靠的做法是：先用 Go 自带工具暴露问题，再把关键上下文喂给 Claude 辅助分析。否则容易陷入“以为修了，其实没修”的陷阱。
必须提供给 Claude 的最小上下文有哪些
只贴一段 go 函数，Claude 很难判断是否 race —— 它不知道变量生命周期、是否被多个 goroutine 持有、有没有被闭包捕获。你需要明确给出：
-
go启动的位置（比如go processItem(item)在哪一行） - 共享数据的声明位置和类型（例如
var results []string或cache map[string]int） - 报错信息全文（尤其是
Previous write at ...和Current read at ...的堆栈行号） - 如果用了
sync.Mutex或sync.RWMutex，要说明锁的粒度和加锁范围是否覆盖所有访问点
漏掉任意一项，Claude 可能建议加锁，但锁在错误的作用域（比如锁在循环外却修改循环内变量），反而掩盖问题。
常见误判：Clayde 建议用 mutex，但实际该用 channels
Go 并发哲学优先推荐通过 channel 通信来共享内存，而不是共享内存再加锁。Claude 不会主动判断哪种更符合 Go idioms，它只响应你给的约束。如果你没说明“这个变量只用于 goroutine 间结果传递”，它大概率默认走互斥方案。
典型反例：
for _, url := range urls {
go func() {
res, _ := http.Get(url)
results = append(results, res.Status) // data race on results
}()
}
正确解法不是给 results 加 sync.Mutex，而是用 chan 收集结果：
ch := make(chan string, len(urls))
for _, url := range urls {
go func(u string) {
res, _ := http.Get(u)
ch <- res.Status
}(url)
}
for i := 0; i < len(urls); i++ {
results = append(results, <-ch)
}
这种模式下，results 只在主线程写入，天然无竞争。
为什么有时加了 sync.Mutex 还报 race
最常忽略的是：mutex 变量本身未被正确保护。比如把 mu sync.Mutex 声明为局部变量，或嵌套在 struct 里但没导出、没初始化、或方法接收者是值类型（导致每次调用都复制一份新 mutex）。
检查要点：
- mutex 字段必须是 struct 的导出字段（首字母大写），且接收者用指针：
func (s *Service) Do() { s.mu.Lock() } - 不要在 goroutine 中启动前才 new 一个 mutex 实例（不同 goroutine 拿到的是不同锁）
- 确认所有读写共享数据的地方都经过同一把锁，包括 defer 解锁前的 return 分支
- 避免锁嵌套和重复加锁（
mu.Lock(); mu.Lock()不 panic，但会死锁）
Clayde 看不到运行时对象关系，所以这类结构性错误，必须靠你人工核对作用域和所有权。
