Go搜索结果缓存必须解决并发安全、过期淘汰、内存控制三问题；sync.Map不支持TTL、容量限制和清理回调，易致OOM；推荐go-cache或groupcache/lru，二者均支持TTL、容量上限及类型自由。
搜索结果缓存不是简单地把 map[string]interface{} 存起来就行，Go 里真正能用的缓存必须解决并发安全、过期淘汰、内存控制这三件事。
为什么不能直接用 sync.Map 存搜索结果
sync.Map 虽然并发安全，但它不支持自动过期、不支持容量限制、无法触发清理回调——这意味着你缓存的 search?q=go+cache 结果可能一年都留着，直到 OOM。
- 没有 TTL：得自己起 goroutine 定时扫，容易漏删或重复删
- 无 LRU/LFU 策略：热门 query 挤不掉冷门 query，缓存命中率反而下降
- value 类型难约束：搜索结果通常是
[]SearchItem或带分页元信息的结构体，sync.Map不校验类型，取出来还得断言
推荐方案：用 github.com/patrickmn/go-cache（轻量）或 github.com/bsm/groupcache/lru（高并发）
前者适合中小流量 API，后者适合搜索网关类服务。两者都默认支持 TTL 和容量上限，且 key/value 类型自由。
-
go-cache示例：import "github.com/patrickmn/go-cache"<br>c := cache.New(5*time.Minute, 10*time.Minute)<br>// key 是 query 字符串标准化后的结果，比如 url.QueryEscape("golang 缓存")<br>c.Set(key, result, cache.DefaultExpiration)<br>if x, found := c.Get(key); found {<br> return x.([]SearchResult), nil<br>} -
groupcache/lru更适合高频更新场景：它允许你传入OnEvicted回调，在 item 被踢出时释放关联资源（比如关闭临时文件句柄） - 注意：key 必须可比较（不能是 slice/map），建议统一用
sha256.Sum256哈希 query + 参数组合，避免长字符串做 key 影响性能
缓存穿透和击穿必须在 Go 层拦截
搜索接口常见问题不是“缓存没命上”，而是“根本没数据还狂刷”。Go 里最有效的防御是两级缓存 + 空值占位。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 先查本地
go-cache，命中则返回；未命中则加锁（用singleflight.Group），防止相同 query 并发打到后端 - 后端返回空结果时，仍写入缓存一个特殊空结构体（如
EmptyResult{CreatedAt: time.Now()}），并设较短 TTL（如 60s），避免反复穿透 - 不要依赖 Redis 的布隆过滤器做前置判断——Go 服务本身就得扛住突发流量，不能多一次网络跳转
缓存更新时机比存储方式更关键
搜索结果变更是低频但强一致要求的场景。不要等用户搜到旧结果才刷新，而要在数据源变更时主动失效。
- 监听数据库 binlog 或消息队列（如 Kafka topic
search_index_updated），收到事件后调用c.Delete(key) - 避免用模糊 key 清除（如
DeletePrefix("search:")），Go-cache 不支持，groupcache/lru 也不支持——应维护一份map[string][]string记录每个 document ID 关联的所有 query key - 如果更新频繁（如每秒百次），考虑用写时复制（COW）策略：每次更新生成新 cache 实例，原子替换指针，避免锁整个 cache
缓存逻辑越靠近 handler 就越难测试和复用，建议封装成独立 struct，带 mockable 的 store 接口和可注入的 clock。最容易被忽略的是缓存 key 的构造一致性——同一个语义 query 在不同 handler 里用了不同编码方式，缓存就形同虚设。
