go-cache初始化panic主因是参数错误：defaultexpiration不能为0（须用cache.noexpiration），cleanupinterval必须大于0；传0或负数会触发time.duration转换失败导致nil指针解引用。
go-cache 不是拿来即用的“缓冲区”，它是一把双刃剑：用对了能减压，初始化错一个参数就直接 panic 或内存暴涨到 OOM。
cache.New() 为什么一运行就 panic
常见错误是传了 0 或负数给 cache.New() 的两个参数。第一个是默认过期时间（defaultExpiration），第二个是清理间隔（cleanupInterval）。传 0 会触发内部 time.Duration 转换失败，导致 nil 指针解引用 panic。
-
defaultExpiration设为0≠ 永不过期，必须用cache.NoExpiration -
cleanupInterval必须 >0；设为0不仅不清理，还会 panic - 别用
cache.New(0, 0)试图“禁用过期”——这是关掉清理器 + 所有条目永不过期 - 正确写法：
cache.New(5*time.Minute, 1*time.Minute)或cache.New(cache.NoExpiration, 30*time.Second)
Get() 返回 (nil, false) 却刚 Set 过，怎么回事
这不是并发竞争问题，而是语义误读或数据类型陷阱。go-cache 的 Get() 返回 (interface{}, bool)，第二个布尔值才表示“是否命中有效条目”，nil 值本身不能用来判断存在性。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 存了
nil *User，Get()会返回(nil, true)，不是未命中 - 存了
map/slice/chan等引用类型，后续修改原变量会“意外”改掉缓存内容 - 并发写入时没注意：
Set传的是指针，多个 goroutine 共享底层数据，Get出来看似一致，实际是同一块内存 - 正确写法永远是：
if val, found := cache.Get("key"); found { /* 处理 val */ } else { /* 真未命中，该查 DB */ }
Set() 返回 false 就代表失败？
完全不是。cache.Set() 返回 bool 表示“是否首次插入该 key”，和操作成败无关。它几乎不会失败（内部 map 扩容失败极罕见，且不暴露 error）。
- key 已存在 → 更新 value 并返回
false - key 不存在 → 插入并返回
true - 误用
if !cache.Set(k, v, exp) { log.Println("set failed") }会导致日志刷屏 - 需要“首次设置”语义，请用
cache.Add(key, value, exp)，它只在 key 不存在时写入，失败才返回false - 想实现“有则跳过、无则设且带过期”，只能自己先
Get()判断，go-cache 不提供 CAS 类型操作
为什么用了 go-cache 还是扛不住突发流量
因为 go-cache 没有容量限制、没有淘汰策略（如 LRU/LFU）、不控制总 key 数量。它只靠 TTL + 定时扫描清理，内存只增不减是常态。
- 高写入场景下，内存持续上涨，GC 压力大，甚至 OOM
- 没有最大容量限制，
Set永远成功，不会像bigcache那样丢老数据腾空间 - 如果需要容量控制，要么自己封装一层计数 + 删除逻辑，要么换
lru或fastcache库 - 真正难处理的从来不是“怎么存”，而是“什么时候删、删哪些、删完怎么降级”。go-cache 把这部分交给你手动兜底
最常被忽略的点是：清理间隔（cleanupInterval）设得过大时，过期 key 会在内存里滞留很久；而设得太小又会增加调度开销。这个值没有银弹，得结合你的 key 生命周期分布和 QPS 实测调优。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
