结构体被拷贝会导致 sync.Locker 失效，因其内部 state/sema 等字段在值拷贝后完全独立，副本加锁无法保护原结构体临界区，且可能触发“copy of unlocked mutex”崩溃。
为什么结构体被拷贝会导致 sync.Locker 失效
因为 sync.Mutex 和 sync.RWMutex 内部包含指针和状态字段（如 state、sema），一旦结构体被值拷贝，副本里的锁就和原锁完全无关——你对副本加锁，原结构体的临界区根本不受保护，还可能触发 fatal error: copy of unlocked mutex。
用 unexported 字段阻止结构体拷贝
Go 没有“禁止拷贝”语法，但可通过添加不可导出的、不可复制的字段，让编译器拒绝赋值或传参时的隐式拷贝。最常用的是 sync.Mutex 本身（它含不可比较字段）或自定义空 struct 加 noCopy 注释。
- 推荐方式：在结构体里嵌入一个未导出的
sync.Mutex字段（哪怕不用），例如：type Config struct { mu sync.Mutex // 不导出，且不可复制 Data string } - 更明确的方式：用
sync.noCopy类型（需配合//go:notinheap或运行时检查），但日常够用的是前者 - 注意：仅导出字段不足够——如果所有字段都可复制，结构体仍可拷贝；必须至少一个字段不可复制
哪些场景会意外触发结构体拷贝
容易被忽略的拷贝点不是显式 copy()，而是函数调用和赋值中隐式的值传递。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 函数参数是结构体类型（非指针）：如
func process(c Config)→ 调用时整个结构体被拷贝 - map value 是结构体：如
m := map[string]Config{}→m["x"] = cfg会拷贝 - slice 元素是结构体：如
cs := []Config{cfg}→ 追加或索引访问不触发拷贝，但cs[0] = anotherCfg会覆盖并拷贝新值 - JSON 反序列化到结构体变量：没问题；但若反序列化到结构体指针字段的值接收器方法里，可能误用值接收器导致锁失效
用 go vet 检测潜在拷贝问题
Go 自带的 go vet 支持 -copylocks 检查（默认启用），它能发现对含锁字段的结构体进行值传递的行为。
立即学习“go语言免费学习笔记（深入）”；
- 运行
go vet ./...，若出现类似assignment copies lock value to x: sync.Mutex就说明有风险拷贝 - 该检查只报「明显危险」操作，不保证全覆盖——比如嵌套结构体中的锁字段可能漏检
- 真正保险的做法是：所有含
sync.Locker的结构体，一律用指针传递，并把方法接收器设为*T
Copy() 方法，而取决于它的字段是否全可复制。只要嵌了一个 sync.Mutex，它就天然不可拷贝；但如果你忘了嵌、或者用了别名类型绕过检查，问题就会悄悄发生。 
