sync.map仅限单进程内协程同步，无法跨进程/跨机器生效，因其依赖进程内内存实现，多实例间数据完全隔离。
为什么直接用 sync.Map 不适合做跨进程数据同步
因为 sync.Map 是 Go 运行时内的内存结构，只在单个进程内有效。如果你有多个 Go 服务实例（比如部署了 3 个副本），每个实例都有自己的 sync.Map，彼此完全隔离——改 A 实例的键值，B 实例根本看不到。所谓“同步”，必须依赖外部一致存储或通信机制。
用 Redis 做中心状态存储时，SET 和 SETNX 怎么选
核心看是否需要防止并发覆盖：SET 无条件覆盖，适合最终一致性要求不高的场景；SETNX（即 SET key value NX）只在 key 不存在时写入，配合 EX 可实现带过期时间的“首次写入锁定”。但注意：它不能解决“读-改-写”竞态（比如先 GET 再 SETNX），此时得用 Lua 脚本或 WATCH/MULTI。
- 高频更新且允许短暂不一致 → 用
SET key value EX 30 - 初始化配置、开关标志等“只设一次”场景 → 用
SET key value NX EX 3600 - 需要原子增减或条件更新 → 直接上 Lua 脚本，例如：
return redis.call("INCRBY", KEYS[1], ARGV[1])
github.com/go-redis/redis/v9 的 PubSub 模式怎么避免消息丢失
默认的 Redis Pub/Sub 是“发即忘”，订阅者离线期间发布的消息全部丢弃。真要可靠同步，得组合使用：PUBLISH + 持久化消息队列（如 Redis Stream）+ 客户端位点管理。
- 发送端统一往
Stream写（XADD sync:events * data "{\"key\":\"user:123\",\"op\":\"update\"}"） - 每个同步客户端维护自己的消费组（
XGROUP CREATE sync:events group-a $ MKSTREAM）和读取位点 - 用
XREADGROUP GROUP group-a consumer-1 COUNT 10 STREAMS sync:events >拉取消息，成功处理后再XACK - 别依赖
Subscribe方法做关键数据同步——它没重试、没确认、没历史回溯
本地缓存与远程同步之间如何避免脏读
常见错误是“先删本地缓存，再发远程更新”，结果远程失败，本地已空，下次读就穿透到 DB 或返回空。更稳的做法是“双删 + 延迟补偿”：
- 第一步：更新远程存储（如 Redis Stream）
- 第二步：删除本地
sync.Map中对应 key（触发下次读取时重建） - 第三步：异步启动一个延迟 goroutine（比如 500ms 后），再次检查远程值是否已生效，若未同步则强制 reload
- 补充：对强一致性要求高的 key（如权限开关），可完全跳过本地缓存，直连 Redis Stream +
XREADGROUP
真正难的不是写同步逻辑，而是界定哪些数据能容忍几秒延迟、哪些必须强一致——这个业务语义层的判断，没法靠工具自动完成。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
