Go 结构体复制后锁为什么会出问题：值接收者与 sync.Mutex 的所有权边界

给一个带 sync.Mutex 的结构体加方法时，最容易被忽略的不是加锁语句，而是方法接收者写成了值。代码能编译，测试也可能暂时通过，但每次调用都在复制结构体，锁和计数器已经不再属于同一个实例。

只要结构体里包含正在使用的 sync.Mutex，通常就把它当成不可复制对象：方法用指针接收者，容器传指针，初始化后固定所有权。

值接收者复制的到底是什么

先看一个足够小的类型。Counter 里有锁和数值，Inc 却使用值接收者：

type Counter struct {
    mu sync.Mutex
    n  int
}

func (c Counter) Inc() {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.n++
}

调用 counter.Inc() 时，编译器会先复制 counter，然后在副本上执行方法。n++ 改的是副本，原值不变；更麻烦的是，副本里的 mu 也不是原来的那把锁。

这个例子有两个独立问题：计数结果丢失，以及锁的保护对象错位。前者在单线程测试中就能暴露，后者往往要等结构体还包含引用、指针或外部状态时才变得危险。

锁的适用压力来自共享状态，而不是字段数量

锁的意义是让一组并发操作围绕同一份状态建立顺序。如果复制动作把锁和状态拆成了不同实例，就算每个副本内部都没有数据竞争，也不代表业务操作被正确串行化。

可以把这条边界记成一句话：锁保护的是对象的所有权，不是某个方法名。对象需要保持身份时，复制整个对象就应该被视为设计错误。

尤其要留意这几类类型：

• 包含 sync.Mutex、sync.RWMutex 或 sync.Cond 的状态对象；
• 锁保护 map、缓存、连接池或统计值，而结构体又被放入切片或按值返回；
• 方法通过接口调用，接收者形式被接口实现声明悄悄固定。

典型修复：让方法和容器都传递对象指针

修复不是把 Lock 移到另一个位置，而是让锁和状态从初始化到使用始终属于同一个对象：

type Counter struct {
    mu sync.Mutex
    n  int
}

func (c *Counter) Inc() {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.n++
}

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

把多个计数器交给调用方时，也不要在容器里保存值：

counters := map[string]*Counter{
    "orders": &Counter{},
}
counters["orders"].Inc()

这样，方法拿到的是原对象地址，map 里保存的也是同一个地址。若确实要复制配置字段，可以在创建阶段复制配置，再单独初始化新的锁和运行状态；不要复制一个已经开始工作的锁。

值接收者什么时候还能用

不是所有结构体都必须用指针接收者。没有同步原语、没有需要保持身份的内部状态，并且复制成本可接受的值对象，可以继续使用值接收者，例如时间区间、坐标或只读配置。

但同一个类型一旦加入互斥锁，原先“看起来方便”的值语义就应该重新评估。接口方法集、构造函数返回值和测试辅助函数都要一起检查，不能只改一个 Inc 方法。

如果需要只读查询，也建议保留指针接收者。这样可以让调用方看到统一的所有权语义，避免以后新增字段后又引入隐蔽复制。

用 go vet 把复制锁拦在提交前

Go 工具链可以识别不少复制锁路径。保存上面的值接收者后运行：

go vet ./...

常见提示会指出方法复制了带锁的结构体，或者某个赋值、返回值复制了锁。它不是运行时证明，但很适合作为第一道门：一旦提示来自包含同步原语的类型，先回到所有权设计，不要只在这一行加注释压掉告警。

还可以用测试验证“调用前后是同一个对象”：

func TestCounterUsesSameObject(t *testing.T) {
    c := &Counter{}
    c.Inc()
    if got := c.Value(); got != 1 {
        t.Fatalf("Value() = %d, want 1", got)
    }
}

几个容易误判的边界

把锁改成指针就一定安全吗

不一定。将字段写成 *sync.Mutex 会让复制后的结构体共享同一把锁，但这会把锁的生命周期、nil 处理和初始化责任变复杂；除非有明确的共享需求，否则优先让整个状态对象不可复制。

加了锁为什么还会得到旧值

如果写方法是值接收者，锁和字段都在副本上，调用者读取原对象当然仍然是旧值。先检查接收者和容器是否按值传递，再看锁的顺序。

go vet 没报错是不是就能复制

也不能这样反推。工具只能覆盖它识别到的路径，业务层的别名、接口和构造逻辑仍需要人工确认。对含锁类型建立“不复制”的代码约定，比依赖单次检查更可靠。

常见问题

结构体里只有一个 Mutex，也必须用指针接收者吗

如果这个结构体会在运行中保存状态，建议统一使用指针接收者。这样即使以后增加字段，也不会因为某个旧方法继续按值复制而埋下问题。

复制一个还没使用过的锁可以吗

初始化阶段复制一个尚未使用的零值锁通常不会立刻出错，但不应该把它当成长期设计。对象一旦开始承载共享状态，就应固定所有权并停止复制。

为什么锁没有竞争，结果还是不对

每个副本都拿自己的锁时，竞争检测器可能看不到同一把锁上的冲突，但副本保护的状态也不是调用方读取的原状态。结果错误不一定以数据竞争的形式出现。

判断清单

看到一个带 sync.Mutex 的结构体，可以按这个顺序检查：方法是否全部使用指针接收者；返回值、参数、切片和 map 是否保存了对象副本；锁保护的字段是否和锁在同一个对象；初始化后是否还会把对象赋值给另一个变量；最后运行 go vet ./... 并补一个并发测试。

如果这些问题都能回答清楚，锁的边界通常就稳定了。真正需要改的往往不是某个 Lock 调用，而是让对象从创建到销毁都保持唯一、可追踪的所有权。