Go sync.Map CompareAndSwap 失败时如何判断更新条件

线上缓存更新出现过一次很容易误判的现象：调用 sync.Map.CompareAndSwap 后返回 false，值却看起来“应该能更新”。真正的问题通常不是 CAS 随机失败，而是把多个条件混成了一个布尔值：键可能不存在，当前值可能已经不是预期旧值，也可能在读取和替换之间被另一个 goroutine 改过。

排查这类问题要把 Load 当作诊断入口，把 CompareAndSwap 当作最后的原子条件更新。Load 负责解释当前状态，CAS 的 false 负责提醒“这次替换没有发生”，不能被解读成唯一原因。

• 先确认 old 是可比较类型，并且语义上确实是期望的旧值。
• 再用 Load 区分键不存在、类型不符和旧值不一致。
• 最后保留 CompareAndSwap，处理读取后发生的并发变化。

官方资料：https://pkg.go.dev/sync#Map.CompareAndSwap

先还原 CompareAndSwap 的失败现场

Go 官方文档对 Map.CompareAndSwap 的定义很明确：只有 key 当前存储的值等于 old 时，才会替换为 new，并返回 true；old 必须是可比较类型。也就是说，false 首先只说明“没有发生这次替换”，并没有告诉你是哪一类前置条件没有满足。

var cache sync.Map
cache.Store("quota", 10)

// old 与当前值相等时才替换，返回值只代表本次替换是否发生。
swapped := cache.CompareAndSwap("quota", 10, 9)
if !swapped {
    // 这里不能直接断言是键不存在，也可能是值已经被其他 goroutine 改写。
    log.Println("条件更新未发生")
}

还要留意值的动态类型。如果 map 里存的是结构体、切片或函数，直接把不可比较值作为 old 传入会破坏这条调用契约；工程上更稳妥的做法是让同一个 key 始终保存明确、可比较的值类型。

用 Load 把 false 拆成几种原因

如果业务需要给日志或指标标出失败原因，先调用 Load。它的第二个返回值能区分键是否存在，再通过类型断言和业务比较区分“类型不符”和“旧值不一致”。这个读取只是诊断，不是更新成功的承诺。

func updateQuota(m *sync.Map, key string, want, next int) (bool, string) {
    current, ok := m.Load(key)
    if !ok {
        // key 不存在时，CompareAndSwap 不会凭空创建新值。
        return false, "key-not-found"
    }

    value, ok := current.(int)
    if !ok {
        // 统一 key 的值类型，避免比较时触发不可预期的类型问题。
        return false, "value-type-mismatch"
    }
    if value != want {
        // 当前值存在，但已经不是调用方期待的旧值。
        return false, "old-value-mismatch"
    }

    // 最后的替换仍由 CAS 原子完成，不能用前面的 Load 代替它。
    if m.CompareAndSwap(key, want, next) {
        return true, "swapped"
    }
    // Load 之后到 CAS 之前可能有其他 goroutine 改过 key。
    return false, "concurrent-change"
}

把并发变化当作正常分支处理

最容易留下隐患的修复是：看到 CAS 返回 false 就无条件再写一次。这样会把条件更新退化成覆盖写，反而丢失了“只有当前值仍是 want 才能修改”的保护。

如果 concurrent-change 只是短暂竞争，可以重新 Load 并在有限次数内重试；如果这次更新不是必须完成，也可以记录 key 后放弃。重试前要重新读取当前值，不能复用旧的 want 判断，更不能把失败后的 Store 当成通用兜底。

在指标中至少区分 key-not-found、old-value-mismatch 和 concurrent-change。这样下一次故障出现时，日志能告诉你是数据状态不符合预期，还是竞争程度上升，而不是只看到一串没有上下文的 false。

补上值类型和容器边界

sync.Map 适合多个 goroutine 并发读写的特定模式，官方文档也提醒它不是普通 map 的默认替代品。若业务还要同时维护多个字段的不变量，普通 map 配合明确的锁往往更容易读懂；若继续使用 sync.Map，就让同一 key 的值类型固定，并且不要在首次使用后复制 sync.Map。

回到最初的故障，稳定的修复路径是：用 Load 记录当前状态，用类型断言守住值边界，用 CompareAndSwap 保护最后一次条件替换，再为竞争失败选择有限重试或放弃。这样既保留了原子更新的意义，也不会把一次 false 误判成单一根因。

常见问题

CompareAndSwap 返回 false 能直接说明 key 不存在吗？

不能。false 也可能表示当前值不等于 old，或者 Load 之后发生了并发修改。需要先用 Load 判断键状态，再结合值类型和业务值分析。

为什么已经 Load 到 want，CAS 仍然可能失败？

Load 与 CAS 之间存在并发窗口，另一个 goroutine 可能已经更新了同一个 key。Load 是诊断依据，CAS 才是最后的条件更新。

CAS 失败后应该改用 Store 吗？

只有在业务明确允许覆盖写时才考虑 Store。若原本要求“旧值未变化才更新”，Store 会绕过这个保护，应该重读后有限重试或记录并放弃。