本地缓存比Redis更快，因其直接在应用内存读写、无网络RTT（0.2–1ms）、无连接池争抢和序列化开销，P99响应更低，适合高并发下极致性能场景。
为什么用本地缓存而不是只靠Redis？
Redis再快也有网络RTT（通常0.2–1ms），在高并发下连接池争抢、序列化/反序列化开销会放大。而嵌入式本地缓存（如sync.Map或github.com/bluele/gcache）直接在内存读写，P99响应能压到
但别误以为“加个map就行”：Go原生map非并发安全，直接读写会panic；sync.RWMutex保护虽安全，但锁粒度粗，高并发下争抢严重。
- 优先用
sync.Map：零分配、无锁读多写少场景下性能最优，适合API路径、字典项等只读为主数据 - 需要LRU淘汰时选
gcache或groupcache：它们内部用分段锁+原子计数，比全局mutex吞吐高3–5倍 - 避免把大对象（如含slice/map的结构体）直接塞进本地缓存：容易触发GC逃逸，建议序列化为
[]byte再存
gin-vue-admin里本地缓存怎么初始化和复用？
它的server/global/global.go文件里已封装好LocalCache实例，基于gcache构建，支持自动过期和最大容量限制。关键不是“能不能用”，而是“什么时候清”和“清不干净会怎样”。
- 启动时预热数据（如
system.LoadAll()）会写入LocalCache，但不会主动同步到Redis——若Redis里数据更新了，本地缓存就脏了 - 权限变更后调用
cache.Delete("authority:" + userID)，但若没调用或调用失败，后续请求仍走旧缓存 - 建议在关键写操作后加双删：先删本地缓存 → 写DB → 再删一次本地缓存（防中间件panic导致第一次删除丢失）
c.JSON()和本地缓存组合时的隐性坑
你以为缓存了数据，c.JSON(200, cachedData)就万事大吉？错。c.JSON()内部会反射遍历cachedData字段，若该结构体含指针或interface{}，Go逃逸分析会把它整个分配到堆上——本地缓存省下的时间，全被GC吃掉了。
- 返回前用
jsoniter.ConfigFastest.Marshal(cachedData)替代c.JSON()，序列化结果直接c.Data(200, "application/json", bytes) - 缓存值类型尽量用
struct{}或map[string]string，避免嵌套指针（比如*User改成User值拷贝） - 如果缓存的是JSON字符串（如从Redis Get拿到的
[]byte），别再解码成struct又重序列化——直接c.Data()输出
本地缓存失效策略怎么设才不拖慢接口？
设置expire: 10 * time.Minute看着合理，但若所有热点key在同一秒过期，就会引发“缓存雪崩”——大量请求同时穿透到DB。gin-vue-admin默认用固定过期时间，没做随机抖动。
- 给过期时间加±10%随机偏移：
rand.Int63n(60000) + 600000（10分钟±1分钟） - 对高频key（如首页配置）启用“逻辑过期”：缓存value里嵌入
expireAt int64字段，读取时判断是否过期，过期则异步刷新，当前仍返回旧值 - 禁止用
time.Now().Add(...)算过期时间存进缓存——不同goroutine系统时钟可能有微小漂移，导致判断不一致
本地缓存真正难的不是“怎么存”，而是“怎么让它和分布式缓存、数据库的状态始终对齐”。一次漏删、一个没加抖动、一处反射逃逸，都可能让百毫秒目标变成几百毫秒。
