Go中值类型本身可复制且单次读写常为原子操作，但多协程共享同一值时若无同步机制仍会引发数据竞争；需遵循“不共享或共享必同步”原则，优先用channel传递、必要时加锁或使用atomic操作。

Go 中的值类型（如 int、string、struct{} 等）本身是“可复制”的，单次读写操作在多数情况下是原子的（尤其对机器字长以内的整数），但这不等于它们在多协程环境下天然线程安全。真正的问题不在于“值类型是否能被并发读”，而在于“多个 goroutine 同时读写同一份值”时缺乏同步机制所引发的竞态行为。

值类型共享导致的数据竞争

当多个 goroutine 通过指针或闭包等方式访问同一个变量（哪怕它是值类型），就可能产生数据竞争。例如：

• 一个 int 字段被多个 goroutine 用 ++ 修改，而没加锁 —— 这不是原子操作（读+改+写三步），结果会丢失更新；
• 一个 struct{ count int; name string } 被并发写入，即使字段各自是值类型，整个 struct 赋值也不是原子的，且字段间无内存屏障，可能导致部分更新可见；
• 函数参数传的是值，但若该值包含指针（如 struct{ data *[]byte }），实际共享的仍是底层堆内存，风险转移到指针指向的内容上。

看似安全的复制，实则隐藏陷阱

值传递常被误认为“绝对安全”，但要注意：

• 返回结构体时若含 sync.Mutex 字段，直接复制会导致锁状态丢失（Mutex 不可复制，运行时 panic）；
• 切片、map、channel、func、interface 等类型虽是值类型，但底层指向共享的底层数组或哈希表，并发读写这些内容仍需同步；
• 字符串是只读的，但若用 unsafe 或反射绕过只读性，或通过 []byte(unsafe.StringData(s)) 改底层，就会破坏一致性。

如何规避值类型的并发风险

核心原则：不共享，或共享必同步。

• 优先使用 channel 传递值，而不是让多个 goroutine 共享变量地址；
• 若必须共享，用 sync.Mutex 或 sync.RWMutex 保护整个临界区，不要只锁某个字段；
• 对简单整数计数，可用 sync/atomic 包的 LoadInt64、AddInt64 等原子操作，比锁更轻量；
• 避免将含锁、通道、map 等非线程安全字段的 struct 直接赋值或作为 map key 复制 —— 检查是否实现了 sync.Locker 或含不可复制字段。

基本上就这些。值类型不是并发银弹，安全与否取决于你怎么用它，而不是它“是什么类型”。