sync.Map仅适用于读多写少、无TTL和淘汰需求的单机轻量场景，如配置热更新、白名单；需TTL、LRU、跨实例共享或大容量缓存时必须换Redis或第三方库。
单机本地缓存用 sync.Map 就够了，别一上来就引入 Redis 或第三方库——它没并发安全问题，零依赖，内存访问快，适合配置、白名单、小规模用户态数据等场景。
为什么不用 map + mutex 而选 sync.Map
sync.Map 是 Go 标准库专为「读多写少」场景优化的并发安全映射，比手动加锁的 map 更轻量、更高效。尤其在 Gin 的 HTTP handler 中高频读取（比如路由级开关、接口灰度标识），sync.Map 的读路径无锁，性能优势明显。
- 普通
map直接并发读写会 panic：fatal error: concurrent map read and map write - 自己封装
map + sync.RWMutex可行，但读多时锁竞争仍存在，且易漏写 Unlock -
sync.Map的Load/Store方法本身已做并发控制，无需额外同步原语
在 Gin 中初始化并全局复用 sync.Map
不要在每个 handler 里 new 一个 sync.Map，它不是一次性的；应在 main() 初始化阶段声明为包级变量或注入到 gin.Engine 的 Keys 中（后者不推荐，因 Keys 非线程安全容器）。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 推荐方式：定义全局变量
var localCache = sync.Map{}，所有 handler 直接调用localCache.Load(key)或localCache.Store(key, value) - 若需类型安全，可封装一层函数，如
GetFeatureFlag(key string) bool，内部做类型断言和默认值兜底 - 避免存大对象（如结构体指针），尤其是带未导出字段的——
sync.Map不关心序列化，但 GC 压力和内存占用会变高
什么时候该换 Redis 而不是硬撑 sync.Map
sync.Map 是单进程视角的，跨实例无效。以下情况必须切走：
立即学习“go语言免费学习笔记（深入）”；
- 部署多个 Gin 实例（如 Kubernetes 多 Pod），缓存需共享 → 必须上 Redis
- 需要过期时间（TTL）、LRU 驱逐、原子计数（如限流）→
sync.Map不支持 - 缓存数据量持续增长且不可控（如用户 session 映射表）→ 容易 OOM，Redis 可配置 maxmemory 和淘汰策略
- 要求缓存变更能广播通知（如配置热更新）→
sync.Map无事件机制，Redis 可用 Pub/Sub
真正容易被忽略的是：很多人把 sync.Map 当成「轻量 Redis 替代品」，结果上线后发现缓存不一致、GC 频繁、甚至因误存闭包或 channel 导致 goroutine 泄漏。它只解决「本进程内并发读写安全」这一个问题，别的都得自己补。
