就是不让你拷贝的意思。
不是所有的东西都可以拷贝的，比如sync包下面的Mutex结构体，就是不可以拷贝的。为了防止有些不应该被拷贝的对象被拷贝，于是就有了noCopy。
golang中如何禁止复制
noCopy是一个golang基础包内部的结构体（小写开头，说明不对外暴露，不想让用户调用），其声明如下：
type noCopy struct{}
// Lock is a no-op used by -copylocks checker from `go vet`.
func (*noCopy) Lock() {}
func (*noCopy) Unlock() {}
当我们声明的结构体里包含noCopy时：
type DoNotCopyMe struct {
noCopy
}
var d DoNotCopyMe
d2 := d // 这里发生了拷贝
编译器是不会报错的，对，你没有看错，编译器是不会报错的，只能用vet工具检查:
// 假设我们上面的代码写在main.go文件中
go vet main.go
// 会看到如下输出
./main.go:616:11: assignment copies lock value to d2: command-line-arguments.DoNotCopyMe contains command-line-arguments.noCopy
./main.go:618:23: call of fmt.Printf copies lock value: command-line-arguments.DoNotCopyMe contains command-line-arguments.noCopy
如果没有错误的使用不能被copy的代码审核，运行命令时不会看到输出。
从上面的实验我们可以得出两点结论：
如果一个结构体实现了Lock和Unlock函数，原则上就不能被拷贝。
但是编译器没有做限制，如果想知道代码里是否有错误的用法，需要用go vet命令检查。
为什么sync.Mutex不能复制
如果说实现了Lock和Unlock方法的结构体是不能复制的，那么sync包下的Mutex肯定是符合条件的，是不允许被复制的，我们来看个例子。
type Container struct {
sync.Mutex
counters map[string]int
}
func (c Container) inc(name string) {
c.Lock()
defer c.Unlock()
c.counters[name]++
}
func main() {
c := Container{counters: map[string]int{"a": 0, "b": 0}}
doIncrement := func(name string, n int) {
for i := 0; i < n; i++ {
c.inc(name) // A
}
}
go doIncrement("a", 100000)
go doIncrement("a", 100000)
time.Sleep(300 * time.Millisecond)
fmt.Println(c.counters)
}
让我们运行一下，看会发生什么？
fatal error: concurrent map writes
抛异常了。
按说这段代码是可以正常工作的呀，我们考虑到了map是不支持并发的，所以使用了互斥锁来保护map，为什还会发生异常呢？
问题出在A部分，这里发生了对象拷贝，也就是说，一个规定了noCopy的对象被拷贝了。
我们如果修改上面的代码，使它能正常工作呢？
我们在声明inc方法的时候，应该这样声明：
func (c *Container) inc(name string) {
c.Lock()
defer c.Unlock()
c.counters[name]++
}
把c改成指针类型就可以了，当c无论在哪里引用，都是同一个c，那么内部使用的还是同一个Mutex对象，是不会发生拷贝的。
Mutex会产生异常更本质的原因
以后我们再写文章去解析Mutex的原理，今天我们只对Mutex做浅显的研究，能解决我们的疑惑即可。我们看下Mutex的结构体，在mutext.go文件里，它是这样定义的：
// A Mutex must not be copied after first use.
type Mutex struct {
state int32
sema uint32
}
在这个结构体里并没有指针，也就是说，外面c变量被拷贝了多少次，Mutex也被拷贝了多少次，这里没有任何东西是共享的，每个goroutine里使用的Mutex实例都是自己的，并不是公用的，但是因为map的本质是一个指针，所以map倒是公用的。这就相当于每个人都有自己的钥匙，却要去开同一把锁，产生竞争是必然的，map中有并发检查，于是就抛异常了。
所以，在了解到问题的本质后，我们还有另一种解法：
type Container struct {
*sync.Mutex
counters map[string]int
}
c := Container{counters: map[string]int{"a": 0, "b": 0}, Mutex: &sync.Mutex{}}
把sync.Mutex定义成一个指针，这样外面的c变量无论被拷贝多少次，内部使用的锁还是同一个，也能保持并发的inc方法能正常执行。
在结构体中引用了Mutex后，很容易在拷贝后发生并发错误。所以总是把Mutex声明为指针不失为一个安全的方法。
type AlwaysSafe struct {
mux *sync.Mutex
}
只是要记得初始化：
a := AlwaysSafe{mux: &sync.Mutex{}}
