sync.map仅适合“大量并发读+极少写”的场景，如请求计数；不支持ttl、淘汰、遍历，无法用于配置或用户数据缓存。
Go 框架本身不内置缓存机制，缓存得靠你自己选型、封装和集成——不是“用框架自带的缓存”，而是“在框架里怎么把缓存用对”。选错方案或忽略边界条件，轻则缓存失效、内存暴涨，重则并发错乱、服务卡死。
sync.Map 适合什么场景？不适合什么？
它不是通用缓存替代品，只适合「大量 goroutine 频繁读 + 极少写」的特定负载。比如记录请求计数、临时状态快照。
- 别用它存配置、用户数据、商品信息——key 总量可控（几百到几万）时，带
sync.RWMutex的普通map更稳：读无锁、写仅锁、内存占用低 -
sync.Map不支持遍历、不能原子清空、没有 TTL 接口，想做过期淘汰或批量刷新，基本没法搞 - 高频写 + 小 key 数量下，它的分片+原子操作反而比一把读写锁慢，实测 GC 压力也更高
go-cache 和 bigcache 的关键差异在哪？
两者都支持 TTL 和并发安全，但底层设计决定你能不能放心用在生产环境。
-
go-cache是纯 Go 实现，value 类型任意，支持OnEvicted回调，适合中小规模、需要灵活清理逻辑的场景；但它内部用map+ 定时器，key 多了会创建海量time.Timer，易泄漏 -
bigcache用分片 + 时间戳数组管理过期，TTL 粒度是整数秒，所有 value 必须是[]byte；优势是内存友好、GC 友好，适合高吞吐、大容量缓存；缺点是无法存结构体，出问题要懂它的哈希分片逻辑 - 如果只是缓存 JSON 字符串或序列化后的结构体，
bigcache更省资源；如果要存*User指针并做复杂清理，go-cache更直接
本地缓存如何避免击穿和雪崩？
本地缓存单机隔离，解决不了分布式击穿，但能显著降低下游压力——前提是加对防护。
- 对热点 key 加
singleflight.Group：同一时间只放一个 goroutine 去加载，其余等待结果，避免 DB 被打爆 - 用「逻辑过期」代替绝对过期：value 里嵌
expireAt time.Time和data interface{}，过期后允许再用 5 秒旧值，同时异步刷新 - 别依赖本地缓存扛突发流量——它没容量限制、没降级开关、没监控埋点，出问题时连“是不是缓存挂了”都难确认
Redis 缓存必须注意的三个硬伤
Go 连 Redis 不难，难的是让缓存真正可靠、可观测、可运维。
- 连接池大小别拍脑袋设：默认 10 太小，高并发下会排队阻塞；建议按
QPS × 平均耗时（秒）× 2估算，再压测调优 - 缓存键名必须带业务前缀和版本号，比如
"product:v2:12345"，否则升级结构体或改逻辑时，旧缓存会静默污染新逻辑 - GET 后不做
nil判断就直接json.Unmarshal，遇到空值或过期 key 会 panic；务必先检查val, ok := client.Get(ctx, key).Result()
最常被忽略的一点：本地缓存不是独立模块，它是散落在 handler、service、util 里的几十行代码。没人管它内存增长、没人看它命中率、没人配告警——等它吃光内存或返回脏数据时，问题已经在线上跑了好几天。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
