Go sync.Map LoadOrStore 什么时候返回旧值：并发初始化与类型断言边界

缓存初始化代码最容易让人误判的一行，是把 sync.Map.LoadOrStore 的返回值直接当成“我刚放进去的对象”。在并发请求同时第一次访问同一个键时，只有一个调用真正完成存入，其余调用拿到的是已经存在的旧值；判断这个结果靠的是 loaded，不是返回值本身。

LoadOrStore 返回三元组中的 actual 是最终应使用的值，loaded=true 表示键原来已经存在；初始化逻辑必须围绕这两个事实写。

LoadOrStore 的“旧值”到底从哪里来

sync.Map 是一个并发安全的键值表，LoadOrStore(key, value) 同时完成“查找”和“必要时写入”。如果 key 已经存在，它不会覆盖旧值，而是返回旧值并把 loaded 置为 true；如果 key 不存在，本次 value 才会成为实际存储值，loaded 为 false。

这里有一个很实用的判断：不要用 actual == value 推断谁赢了。接口值可能装着指针、字符串或其他可比较值，比较本身还可能受到类型和值语义影响。loaded 才是 API 明确给出的结果位。

并发第一次访问时，应该使用哪个对象

package main

import (
    "fmt"
    "sync"
)

func main() {
    var cache sync.Map

    value := "built-by-this-call"
    actual, loaded := cache.LoadOrStore("config", value)
    if loaded {
        fmt.Println("reuse", actual)
        return
    }
    fmt.Println("store", actual)
}

单线程运行时，这段代码第一次会输出 store built-by-this-call，第二次运行同一个进程里的相同逻辑则会走 reuse。关键不是把分支写得多复杂，而是后续统一使用 actual：它代表这个键最终对应的值。

图中只保留与代码一致的三个节点：sync.Map 进入 LoadOrStore，再由 loaded 分出首次存入和复用旧值两条路径。

把“构造出来的 value”与“最终 actual”分开

在真实缓存里，value 往往是本次调用刚解析的配置、刚创建的客户端或刚计算出的结果。另一个 goroutine 可能更早完成存入，因此当前调用即便拿到了 loaded=true，也应该丢掉自己的临时对象，使用 actual。如果临时对象拥有文件句柄、连接或大块内存，还要在复用分支释放它。

类型断言为什么必须跟着存储约定走

LoadOrStore 返回的是 any。如果约定键 config 对应一个字符串，就要让写入和读取都遵守这个约定，不能一会儿存 string，一会儿存 *Config。安全的断言写法应该保留失败分支：

actual, loaded := cache.LoadOrStore("config", "ready")
text, ok := actual.(string)
if !ok {
    panic("cache key config has an unexpected type")
}
if loaded {
    fmt.Println("reuse", text)
} else {
    fmt.Println("store", text)
}

类型断言应落在 actual 上，而不是本次调用的临时 value；断言失败表示键的存储约定已经被破坏。

不要把类型错误归因给并发

如果 actual.(string) 失败，优先检查所有写入这个键的代码路径。若代码约定把缓存值表达为 value.(string)，也要确认这个约定在所有写入点一致。并发只决定谁先把值放进去，不会把一个字符串自动变成别的类型。把键名集中成常量、把存取封装到同一个小函数里，通常比在各个调用点补更多断言更稳。

哪些场景不适合直接用 LoadOrStore

如果构造对象很便宜，允许多个 goroutine 各自算一次，再由 LoadOrStore 选出一个结果，代码往往足够简单。若构造过程会发起网络请求、打开资源或执行昂贵计算，重复构造的代价就要单独评估。LoadOrStore 解决的是键值存取的并发安全，不等于“只允许一个 goroutine 执行构造函数”。

这时可以把构造过程放进更明确的初始化方案，例如按键维护初始化状态，或在业务边界上使用 sync.Once。选择前先确认是否需要失败重试、是否允许初始化阻塞其他请求，以及失败对象是否能被缓存。不要因为看到 loaded 就默认它提供了完整的单次执行语义。

常见问题：sync.Map.LoadOrStore 返回值怎么判断

loaded=true 是不是表示本次 value 写入成功？

不是。它表示 key 原来已经有值，本次调用返回已有值；本次传入的 value 没有成为该键的实际值。

为什么不直接使用第二个参数 value？

并发调用时，另一个调用可能已经先存入了不同对象。返回的 actual 才是这个 key 最终应使用的对象。

类型断言失败时应该重试 LoadOrStore 吗？

通常不应该盲目重试。先定位同一个 key 的写入约定是否不一致；重试只会掩盖缓存数据已经被错误写入的问题。

把判断写在返回值旁边

阅读 LoadOrStore 时可以记住一句话：loaded 说明“键是否已有值”，actual 说明“最终该用哪个值”。围绕这两个返回值组织类型检查、资源释放和初始化策略，代码就不容易在并发第一次访问时选错对象。