Go 结构体复制后 mutex 为什么可能造成数据竞争

如果一个 Go 结构体里放了 sync.Mutex，它就不再适合像普通值一样到处复制。最容易踩坑的写法是 b := a 或值接收者：锁本身被复制了，但结构体里的 map、slice 等引用型字段可能仍指向同一份底层数据。此时两份对象各自加锁，锁住的却不是同一把锁，最终可能出现数据竞争。

结构体包含 mutex 时，日常 API 使用指针接收者并保持单一实例；需要快照时，只在锁内复制业务数据，给新对象重新创建 mutex。不要直接复制已经使用过的结构体。

为什么 b := a 会让两份锁失去保护关系

先看一个很小的存储对象。这里的 map 是引用型字段，结构体复制后两个 map 字段仍可能指向同一份底层哈希表；但 sync.Mutex 是结构体字段，复制时会得到两个独立的锁状态。

package main

import (
    "sync"
)

type Store struct {
    mu   sync.Mutex
    data map[string]int
}

// Put 只允许通过指针修改原 Store，避免复制 mutex。
func (s *Store) Put(key string) {
    s.mu.Lock()
    defer s.mu.Unlock()
    s.data[key]++
}

func copyAfterUse() {
    a := Store{data: make(map[string]int)}
    a.Put("jobs") // mutex 已经发生首次使用
    b := a        // 错误：复制 mutex；data 仍可能共享底层 map

    var wg sync.WaitGroup
    wg.Add(2)
    go func() { defer wg.Done(); a.Put("jobs") }()
    go func() { defer wg.Done(); b.Put("jobs") }()
    wg.Wait()
}

关键不在于变量名，而在于“锁”和“数据”是否仍然成对。a、b 各自拿到一把 mutex，却可能共同访问同一个 map；两个 goroutine 于是可以同时进入 map 写入区。运行竞态检测时，这类代码通常会暴露为 map 或业务字段的竞争，而不是一个显眼的“mutex 已复制”异常。

三个 API 选择：值接收者、指针接收者还是显式快照

可以把常见写法放到一张决策表里。对于包含同步字段的结构体，真正安全的默认项通常是指针接收者；“值接收者看起来更简洁”并不能抵消它复制接收者的事实。

Go 官方代码审查建议也明确指出：如果结构体包含 sync.Mutex 或类似同步字段，接收者应使用指针以避免复制。标准库的 sync.Mutex 文档则把边界说得更严格：它的零值是未锁定状态，但首次使用后不能复制。

安全写法：指针接收者与显式 Clone

日常读写只保留一个对象入口。构造函数返回 *Store，方法统一使用指针接收者，容器和函数参数也尽量传指针。这样调用方不会在每次方法调用时得到一份带锁副本。

// NewStore 返回由一个指针拥有的共享 Store。
func NewStore() *Store {
    return &Store{data: make(map[string]int)}
}

// Snapshot 只复制业务数据，不复制已经使用过的 mutex。
func (s *Store) Snapshot() *Store {
    s.mu.Lock()
    defer s.mu.Unlock()

    copied := make(map[string]int, len(s.data))
    for key, value := range s.data {
        copied[key] = value
    }
    // 新 Store 自带全新的零值 mutex，和源对象彼此独立。
    return &Store{data: copied}
}

这里的“复制”是有边界的：复制的是 map 中的业务值，而不是 Store 整体。若字段还包含指针、slice、嵌套结构体或其他引用型资源，还要继续决定它们是否需要深拷贝；否则快照仍可能和源对象共享可变底层数据。

把复制风险挡在提交前

先运行 go vet ./...。其中的 copylocks 分析器专门检查把包含锁的值错误地按值传递，常见触发点包括值接收者、按值返回、赋值、函数参数、range 变量和复合字面量。它不是竞态检测器，但能在代码还没有并发执行时提醒 API 设计问题。

# 先让静态分析寻找按值复制锁的路径
go vet ./...

# 再用竞态检测检查共享 map 和业务字段
go test -race ./...

修复后重点反查三件事：方法签名是否全部改成指针接收者；是否还有 return value、range []Store 或 map[string]Store 这样的值传递；需要导出快照时，是否只复制数据并重新创建锁。只要对象仍含有 mutex，就把“是否会被复制”作为 API 设计的一部分。

常见问题

mutex 在结构体里但从未 Lock 过，可以复制吗？

从文档边界看，限制是“首次使用后不能复制”；工程上仍建议把它视为不可复制类型，统一用指针传递，避免未来新增方法后悄悄跨过这条边界。

把 mutex 改成指针就一定安全吗？

不一定。多个对象若各自持有不同的锁指针，或者锁保护范围没有覆盖共享数据，仍然会有竞争。要检查的是同一份可变数据是否由同一把锁保护。

为什么 go vet 没报错但程序仍有数据竞争？

go vet 主要找可疑的锁复制，不会证明所有并发访问正确。还要用 go test -race 覆盖真实并发路径，并检查 map、slice 和嵌套对象是否在锁外被访问。