值类型本身非线程安全，“拷贝后使用”可规避竞争，但共享同一内存地址时仍会触发竞态；含指针、map、slice等字段的结构体浅拷贝后仍可能竞争；需依场景选用atomic、mutex或channel。
值类型本身不是线程安全的，但“拷贝后使用”可规避竞争
Go 中的 int、string、struct 等值类型在被传参或赋值时会复制一份新副本。这意味着：多个 goroutine 同时读写各自持有的副本，不会产生数据竞争——但这不等于“值类型天然并发安全”，关键看是否共享了同一块内存。
常见误解是认为只要用了 int 就不用加锁。错在忽略了变量是否被多个 goroutine 共同指向。比如一个全局 var counter int，被 10 个 goroutine 同时执行 counter++，就会触发竞态（race condition），因为它们操作的是同一个内存地址。
- 只读场景（如配置参数）：直接传递
int或struct值是安全的 - 需修改且跨 goroutine 共享状态：必须用同步机制（
sync.Mutex、sync/atomic或 channel） - 结构体含指针或 map/slice 字段时：即使类型是值类型，字段仍可能指向共享堆内存，拷贝后仍可能竞争
struct 拷贝陷阱：字段里藏着指针就危险
定义一个看似纯值类型的结构体，但如果它包含 map、slice、*int 或 chan，那它的“值拷贝”只是浅拷贝——底层数据结构仍在共用。这时候并发读写这些字段，依然会出问题。
type Config struct {
Name string
Data map[string]int // ⚠️ 这个 map 是引用类型！
Tags []string // ⚠️ slice header 被拷贝，底层数组仍共享
}
var cfg Config = Config{Data: make(map[string]int)}
go func() { cfg.Data["a"] = 1 }() // 竞态！
go func() { delete(cfg.Data, "a") }() // 竞态！
- 检测方式：
go run -race main.go能捕获这类运行时竞态 - 修复思路：要么用
sync.RWMutex保护整个结构体访问，要么彻底避免共享——改用 channel 传递更新指令，或每次构造全新结构体 + 不可变字段 - 注意
time.Time、net.IP等看似简单但内部含指针的类型，它们的拷贝也是安全的（标准库已确保字段不可变），但自定义结构体不能默认这么假设
何时该用 atomic 而不是 mutex？
对单个 int32、int64、uint32、uintptr、unsafe.Pointer 或布尔值做原子读写时，sync/atomic 比 sync.Mutex 更轻量、无锁且性能更好。但它不适用于复合操作（比如“读-改-写”中的条件判断）。
立即学习“go语言免费学习笔记（深入）”；
var counter int64
// ✅ 安全：原子增
atomic.AddInt64(&counter, 1)
// ❌ 危险：非原子的“先读再判断再写”
if counter < 10 {
counter++ // 竞态！中间可能被其他 goroutine 修改
}
// ✅ 正确：用 CompareAndSwap 实现条件更新
for {
old := atomic.LoadInt64(&counter)
if old >= 10 {
break
}
if atomic.CompareAndSwapInt64(&counter, old, old+1) {
break
}
}
-
atomic只支持固定尺寸的整型和指针，不支持float64（需用math.Float64bits转换）或结构体 - 所有
atomic操作都要求变量地址对齐（Go 编译器通常自动保证，但用unsafe手动布局时需留意） - 如果逻辑涉及多个字段协同更新（如用户余额和冻结金额同时变动），mutex 或事务型 channel 更合适
channel 替代共享内存：更符合 Go 的并发哲学
Go 推崇“不要通过共享内存来通信，而应通过通信来共享内存”。这意味着：与其让多个 goroutine 直接读写同一个 struct 字段，不如用 channel 发送指令或数据包，由一个专属 goroutine 串行处理状态变更。
- 适合场景：计数器、配置热更新、事件聚合、状态机流转
- 优势：天然串行化、边界清晰、易测试、无锁开销
- 代价：少量内存分配（channel 元数据）、调度延迟（goroutine 切换），但多数业务场景下远小于锁争用成本
- 注意缓冲区大小：无缓冲 channel 会阻塞发送方直到接收方就绪；有缓冲 channel 可缓解突发压力，但别设过大（掩盖设计缺陷）
真正容易被忽略的是：值类型的“安全性”永远依附于使用方式。哪怕是最简单的 int，一旦变成多个 goroutine 闭包中捕获的变量，或通过反射间接修改，照样会翻车。
