sync/atomic不能替代sync.Mutex，因其仅支持单字段有限类型原子操作，无法保护多字段协同、切片/map操作或复合逻辑临界区；而Mutex适用于复杂临界区与非原子类型操作。
sync/atomic 不能替代 sync.Mutex
因为原子操作只对单个字段有效，且仅支持有限类型（int32、int64、uint32、uint64、uintptr、*unsafe.Pointer），无法保护结构体字段组合、切片追加、map 操作或任意逻辑临界区。比如你想原子地「读取计数器 + 更新状态 + 记录时间戳」，这三步必须用 sync.Mutex 包裹，atomic 做不到。
常见误用现象：atomic.LoadUint64(&s.counter) 看似安全，但若后续依赖 s.status 的值做判断，而 s.status 是普通字段——这就产生竞态，go run -race 会报错。
atomic.Bool）、指针替换（如无锁栈头）[]byte、map[string]int）、需条件等待的场景（配合 sync.Cond）atomic 比 Mutex 快 5–10 倍；但一旦涉及内存分配或复杂逻辑，锁开销占比迅速下降，别过早优化sync.RWMutex 在读多写少场景下的真实取舍sync.RWMutex 不是“读不阻塞”的银弹。它允许并发读，但写操作会阻塞所有新读和所有写；更重要的是，**写锁饥饿**很常见——持续有新读请求进来时，写 goroutine 可能无限等待。
典型错误配置：HTTP handler 中对全局配置 map 做 RWMutex.RLock() 读取，但每秒有上千请求，同时后台每分钟一次配置热更（RLock() + Unlock() + Lock() + 写入 + Unlock()）。结果是写操作经常卡住数秒。
ctx, cancel := context.WithTimeout(context.Background(), 500*time.Millisecond)，再调用 rwMutex.TryLock()（需自行封装或用第三方库如 github.com/cespare/xxhash 配合重试）atomic.Value 存整个结构体指针，写时构造新副本再原子替换——避免锁，也无饥饿atomic.Value 要求存储的值类型必须是可比较的（不能含 map、func、slice），否则运行时报 panic: "value is not comparable"atomic.Value 安全替换配置结构体的实操要点atomic.Value 是 Go 标准库中少数能安全承载任意类型（满足可比较前提）的原子容器，特别适合热更新只读配置。
type Config struct {
Timeout time.Duration
Retries int
Endpoints []string // ⚠️ 注意：slice 本身不可比较，会导致 panic
}
// 正确做法：把 slice 封装进 struct，或改用 *[]string（指针可比较）
type SafeConfig struct {
Timeout time.Duration
Retries int
Endpoints []string // ✅ 实际上 slice header 是 struct，底层是 [3]uintptr；但 Go 规范不保证其可比较，所以仍建议避免
}
// 更稳妥定义：
type Config struct {
Timeout time.Duration
Retries int
Endpoints []string `json:"-"` // 仅用于运行时，不参与 atomic.Value 比较
}
// 然后只把基础字段放进 atomic.Value，Endpoints 单独用 RWMutex 保护（或用 sync.Map）
Config 实例 → 调用 configStore.Store(newCfg)
cfg := configStore.Load().(Config)，无需锁，无拷贝（底层是 unsafe.Pointer 赋值）Config 含指针字段（如 *http.Client），多个 goroutine 并发读取后修改其内部状态，依然会引发数据竞争——atomic.Value 只保证“指针替换”原子，不保证所指对象线程安全-race
go run -race 能发现大部分共享变量访问冲突，但对以下情况无能为力：
time.Timer 重复 Reset()、sync.WaitGroup Add() 在 Done() 之后调用user.Status 和 user.LastActive 必须同步更新，否则中间状态被读到就出错atomic 变量之间建议填充 _ [8]byte 隔开真正关键的防线，是设计阶段就明确「谁拥有该数据」「谁负责更新」「读写是否需要强一致性」。比方说日志中的 request ID，用 context.WithValue() 传递比全局原子变量更清晰，也更易测试。