首先是为什么很多东西不能拷贝？很多时候我们被直接告诉了答案，Mutex 锁不能拷贝。但是原因呢？

划重点：变量资源本身带状态且操作要配套的不能拷贝。

比如说 Mutex 锁，WaitGroup ，这些本身都是带状态的信息的。并且它们操作一定要配套，不然就会死锁。什么意思？

锁的配套：

mu.Lock()
mu.Unlock()

WaitGroup 的配套：

wg.Add(1)
wg.Done()

这种一定要严格的匹配，一次加锁对应一次解锁，数量不对就会出问题。

回到问题本身，为什么锁不能拷贝？

因为拷贝了很容易会导致操作次数不匹配。很容易理解，拷贝就是创建了一个新的变量，旧的变量加了锁，新的变量解锁。牛头不对马嘴，岂不就死锁了。就算不死锁也可能达不到锁互斥的目的。看个简单的例子：

func main() {
    var mu sync.Mutex
    var i int
 
    // 第一次加锁放锁
    mu.Lock()
    //...
    // 不知道为啥拷出来
    m := mu
    i += 1
    m.Unlock()
 
    // 第二次加锁放锁 
    mu.Lock()
    i += 1
    mu.Unlock()
}

上面就死锁了。有童鞋可能会反驳，我怎么可能犯这种低级错误。那再来一个：

type Obj struct {
    mu sync.Mutex
    // ... 其他字段
}
 
func (o Obj) Lock()        { o.mu.Lock() }
func (o Obj) Dosomething() {}
func (o Obj) Unlock()      { o.mu.Unlock() }
 
func main() {
    o := Obj{}
 
    o.Lock()
    o.Dosomething()
    o.Unlock()
 
    o.Lock()
    o.Dosomething()
    o.Unlock()
}

这种运行起来也是报错的，因为锁变量的拷贝导致加锁解锁不是配套的操作。

再举个例子，看一个 WaitGroup 很典型的死锁问题：

func doSomething(wg sync.WaitGroup) {
    defer wg.Done()
    // ...
}
func main() {
    var wg sync.WaitGroup
    wg.Add(1)
    doSomething(wg)
    wg.Wait()
}

上面的 wg 使用也会导致死锁。归根结底就是WaitGroup 的变量操作没配套。

划重点：针对需要配套操作的变量类型，基本上都会要求 noCopy 的，否则拷贝出来就乱套了。

在上万行的业务代码场景，可能你的问题更隐蔽。很悲伤的是，上面的三个例子都能正常编译。好消息是，上面三个例子都能用 go vet 检查出来。所以大家一定要善用 go vet 来配合检查，能够过滤大部分的低级问题。

noCopy 机制

Go 没有更好的办法阻止拷贝对象，于是通过了一个 noCopy 的机制。**这个不能阻止编译，但是可以让 go vet 能再静态检查的时候检查出来。**Go 里面通过实现一个 noCopy 的结构体，然后嵌入这个结构体就能让 go vet 检查出来。

type noCopy struct{}
// Lock is a no-op used by -copylocks checker from `go vet`.
func (*noCopy) Lock() {}
func (*noCopy) Unlock() {}

类似于 Mutex，WaitGroup ，变量嵌入了这个 noCopy 的类型，就能被 go vet 检查出来。

通常业务如果也有不让拷贝的需求，会怎么做呢？

最简单的是：嵌入 sync.Mutex 变量。就能让这个变量也具有 noCopy 的功能。

哪些类型不能拷贝？

比如 Mutex Lock，Cond，Pool，WaitGroup 。这些资源都严格要求操作要配套：

// Mutex
Lock()
Unlock()
 
// WaitGroup
Add()
Done()
 
// Pool
Put()
Get()
 
// Cond 一定要配合 Lock 
c.L.Lock()
for !condition() {
   c.Wait()
}
// ... make use of condition ...
c.L.Unlock()

你问为啥 Go 里面 sync.WaitGroup 不能复制？这个面试题其实挺有意思的，它不像那些八股文似的问题能直接背答案过关，它背后藏着对 Go 内存模型、并发原语底层实现的理解，还有一些典型的“我当年也踩过”的坑 🤦‍♂️。今天咱就从程序员的视角聊聊它，别指望教科书的风格，我这人说话一向不太规矩。

我先说结论：sync.WaitGroup 不能被复制，是因为复制后可能导致并发状态混乱，最终引发程序行为不确定，甚至直接 panic。

这不是官方瞎规定，这是 Go runtime 的一种保护机制。你复制了 sync.WaitGroup，基本就是在用 AK 点自己的头，炸了别怪 Go 社区不给你留活路。

先来点实战的例子，你看这段代码有没有问题？

func wrongCopy() {
var wg sync.WaitGroup
wg.Add(1)

wg2 := wg // 复制 WaitGroup（大忌！）

gofunc() {
defer wg2.Done()
fmt.Println(“goroutine finished”)
}()

wg.Wait()
}
乍一看好像也没啥问题？跑个 goroutine 然后 wait 一下不挺正常么？

但实际上，这段代码是未定义行为。Go 官方说得很明白：sync.WaitGroup 绝不能被复制（不能通过赋值、作为函数参数值传递、也不能放进 map/value 结构里作为值传来传去）。

你要是非得解释为啥，来，我给你扒一扒它底下的结构。

WaitGroup 的内部结构其实很简单（但也不简单 😅）：

type WaitGroup struct {
noCopy noCopy
state1 uint64 // 高32位是counter，低32位是waiter数量
sema uint32 // 用于Goroutine阻塞和唤醒
}
注意看这个 state1，它是个 uint64，但里头其实打包了两个值（counter 和 waiter），Go 用的是原子操作（atomic）去同时修改它们，比如 Add 和 Done 的时候。

问题就出在这。如果你复制了 WaitGroup，那你其实是把这堆“原子状态”全都复制了一份，但两份状态之间根本没联系，也就是说你有两个互不相干的副本，但你却想让它们配合工作？开什么玩笑 🤯

举个不太恰当的例子，这就像你买了个“共用账户”的网银卡，然后偷偷给老婆复制了一份副本卡，但银行系统根本没授权这张卡… 然后你俩开始抢着操作，谁知道会发生啥？

你这边 Add(1) 加了计数器，但另一个副本的 Done() 是对着另一个计数器减，Wait() 那边等的压根不是你要的那个副本 —— 于是你等着等着就死锁了，或者莫名其妙提前返回，或者压根 panic。

还有人说，那我是不是可以用指针传递就好了？

对！你要用指针，这才是 Go 正解：

func goodCopy() {
var wg sync.WaitGroup
wg.Add(1)

go func(wg *sync.WaitGroup) {
defer wg.Done()
fmt.Println(“safe goroutine”)
}(&wg)

wg.Wait()
}
看到没，用指针就没问题。因为所有操作都是针对同一块内存，状态是共享的，原子操作才不会乱套。这也符合我们对“并发共享资源”的基本认知：要共享，就别复制，用引用。

其实这里还有个历史梗，早年 Go 并没有把 WaitGroup 设置成不可复制，是后来（Go 1.6）加了 noCopy 的辅助结构，用 go vet 静态分析来提醒你：大哥别复制这个对象。

type noCopy struct{}

func (*noCopy) Lock() {}
func (*noCopy) Unlock() {}
noCopy 是个哑巴锁，啥也不干，但它的存在能让 go vet 静态工具抓出来 “你这傻子，WaitGroup 不能复制你还传值！”。从语言层面避免了不少踩坑者的血泪。

我自己以前就吃过一次这样的亏。那会写一个 HTTP server，想图省事在 handler 里搞了个 WaitGroup 当结构体字段，然后 handler 是按值复制进来的，我也没注意，结果上线之后访问一多就直接挂了。

问题是你根本不知道哪炸了，trace 一堆栈是 sync: negative WaitGroup counter，那时候我真想把自己从编译器拖出来打一顿 🤬

所以你看，sync.WaitGroup 不能复制不是抽象问题，是很现实的技术设计问题。它内部就是通过共享状态来实现并发控制的，如果你复制了，就像是把一堆人用来投票的计票箱复制了一份，然后让两拨人分别投票，但最后你只看了一份票数 —— 你觉得能选出总统吗？🫠

有时候面试官问这个问题，并不是看你能不能背出“不能复制”，而是看你能不能意识到“并发原语的设计哲学”，你是不是知道 并发控制本质上是在维护状态一致性，而复制本身就是破坏这种一致性的动作。

顺带一提，Go 里不止 WaitGroup，还有不少类型也不能复制，比如：

sync.Mutex
sync.Cond
sync.Once
context.Context
你看它们的底层设计，其实都是靠状态控制的，只不过状态用得更隐晦一点。

反正你记住，凡是 Go 并发控制相关的结构体，八成都不能随便值传递。