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或含不可复制字段。
基本上就这些。值类型不是并发银弹，安全与否取决于你怎么用它，而不是它“是什么类型”。
