Go 结构体包含 Mutex 时为什么不能直接复制

Go 结构体里放了 sync.Mutex 后，最重要的规则不是“这个结构体不能赋值”，而是：Mutex 第一次使用后不能再被复制。按值传参、返回结构体、遍历结构体切片，都会隐式复制字段；复制出来的是另一把带着旧状态的锁，和原对象保护的数据也不再处于同一个锁的保护范围内。

把带 Mutex 的对象当成不可复制的资源：用指针持有它，用指针接收者修改它；如果需要返回数据，复制加锁读取后的快照，而不是复制整个对象。

为什么复制后锁和数据不再是同一个对象

Mutex 本身没有导出内部字段，但它保存着当前是否被占用以及等待关系等运行时状态。Go 官方文档明确规定，零值是未加锁状态，而第一次使用后不能复制。下面这种写法不会因为语法不合法而立刻失败，问题在于它把锁和值一起复制了：

type Cache struct {
    mu    sync.Mutex
    items map[string]string
}

// badCopy 把 Cache 按值接收，调用时会复制其中的 Mutex。
func badCopy(c Cache) Cache {
    return c
}

如果原对象已经持有锁，副本可能带着“已锁定”的状态，却没有原锁对应的等待者和使用路径；如果两个对象随后分别修改自己的 items，它们又可能各自拿不同的锁保护同一张 map。锁没有覆盖到真实共享关系，结果可能是死锁、竞态，或者让代码审查误以为访问已经被同步。

用指针接收者和快照类型拆开可复制数据

修复的核心是让带锁对象只有一个明确地址，并把“可复制的数据结果”单独建模。构造函数返回指针，修改方法使用指针接收者；读取时先加锁，再把字段复制到不含锁的 CacheSnapshot。

type CacheSnapshot struct {
    Items map[string]string
}

// NewCache 返回唯一的带锁对象，避免调用方拿到一个可随意复制的值。
func NewCache() *Cache {
    return &Cache{items: make(map[string]string)}
}

// Put 只在原始对象上加锁，保护同一份 map。
func (c *Cache) Put(key, value string) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.items[key] = value
}

// Snapshot 返回不含 Mutex 的副本，调用方可以安全地按值传递它。
func (c *Cache) Snapshot() CacheSnapshot {
    c.mu.Lock()
    defer c.mu.Unlock()

    items := make(map[string]string, len(c.items))
    for key, value := range c.items {
        items[key] = value
    }
    return CacheSnapshot{Items: items}
}

这里的复制发生在锁保护之内，复制的只是 map 中的业务数据；快照返回后不再依赖原来的锁。若只需要读取一个字段，也可以提供返回字符串或数值的小方法，避免暴露可变 map。

这些看似普通的写法最容易触发复制

排查时不要只盯着显式的 a = b。下面的入口都应优先改成指针或快照：

指针接收者不是万能护栏：如果先把 *Cache 解引用后赋给另一个 Cache，仍然发生复制。也不要为了绕过提示把 Mutex 改成指针字段；那会改变锁的共享方式，必须重新审视对象所有权和生命周期。

用工具和检查清单确认修复没有回退

Go 自带的 go vet 有 copylocks 检查项，会提示把锁按值传入、返回或赋值的路径。提交前可以先运行：

# 检查按值传递锁对象等常见问题
go vet ./...

# 检查共享数据访问是否仍存在竞态
go test -race ./...

go vet 报告的是高风险复制线索，不代表所有并发错误都能被它发现；反过来，竞态测试也不能替代对象设计。最后按三项复查：带锁类型是否只通过指针流转、公开返回值是否去掉 Mutex、快照复制是否发生在锁保护范围内。

相关问题

结构体还没有加过锁时，可以复制吗？

官方约束的分界是“第一次使用后”。但为了让接口长期稳定，仍建议从一开始就把带 Mutex 的类型设计成指针对象，不把“当前还没用过”当成可复制契约。

为什么只是读取结构体也会被 go vet 提醒？

按值读取同样会复制 Mutex；工具无法替你证明这个复制发生在首次使用之前，所以会把它当作需要人工确认的 copylocks 风险。

用 sync.RWMutex 时规则不同吗？

不同步类型的细节不同，但 sync 包中的同步对象同样不应在使用后复制。对外保持指针和快照边界，通常比针对具体锁类型写例外更安全。