当接口响应时间超过50ms且数据变更频率低（每分钟不到一次）、读多写少（QPS>100，写入少）时，应使用内存缓存替代数据库查询以提升性能。
什么时候该用内存缓存而不是数据库查
当接口响应时间超过 50ms，且数据变更频率低（比如每分钟不到一次）、读多写少（QPS > 100，写入 sync.Map 或 ristretto 就比反复查 PostgreSQL 或 MySQL 更合适。硬扛数据库不仅拖慢响应，还容易触发连接池耗尽——尤其在突发流量下，database/sql 的 SetMaxOpenConns 很快见底。
常见误判点：把用户会话（session）或带权限校验的实时数据（如余额、库存）直接塞进内存缓存。这类数据一旦过期不及时，会导致“看到旧值但操作失败”的体验断层。
- 适合缓存：地区列表、配置项、文章分类、静态页 HTML 片段
- 不适合缓存：用户 token 状态、订单支付状态、秒杀库存余量
- 折中方案：对敏感字段做短 TTL（如 5s）+ 主动失效（
cache.Delete("order_123")）
Redis 作为二级缓存时 key 设计的三个硬约束
Go 应用连 Redis 常见卡在 key 冲突或序列化不一致上。不是所有字符串都适合当 key，尤其涉及结构体或嵌套 map 时。
- key 必须是纯 ASCII 字符串，不能含空格、换行、控制字符；
json.Marshal出来的结构体字符串含\n和空格，不能直接当 key - 避免使用动态 ID 拼接时不加命名空间，比如
"user_" + userID容易和"user_profile_" + userID冲突，应统一前缀："cache:user:profile:" + userID - 结构体字段顺序影响
json.Marshal结果，建议用map[string]interface{}或定义明确的struct并加json:tag，再用fmt.Sprintf构造 key，例如：fmt.Sprintf("cache:article:%s:%d", slug, version)
type ArticleCache struct {
ID int `json:"id"`
Title string `json:"title"`
Body string `json:"body"`
Author string `json:"author"`
}
// ✅ 正确：key 稳定，value 可序列化
key := "cache:article:" + strconv.Itoa(a.ID)
val, _ := json.Marshal(ArticleCache{ID: a.ID, Title: a.Title, ...})
redisClient.Set(ctx, key, val, 10*time.Minute)
本地缓存（BadgerDB）和 Redis 同时写入的一致性陷阱
想靠 BadgerDB 抗住 Redis 网络抖动？小心双写导致状态分裂。Go 里没有跨存储的原子事务，badger.Update 成功但 redis.Set 失败时，本地有新值、远程还是旧值。
立即学习“go语言免费学习笔记（深入）”；
本书全面介绍PHP脚本语言和MySOL数据库这两种目前最流行的开源软件，主要包括PHP和MySQL基本概念、PHP扩展与应用库、日期和时间功能、PHP数据对象扩展、PHP的mysqli扩展、MySQL 5的存储例程、解发器和视图等。本书帮助读者学习PHP编程语言和MySQL数据库服务器的最佳实践，了解如何创建数据库驱动的动态Web应用程序。
真正可行的做法是「单写 + 异步补」：只写 Redis，本地缓存按需加载并设 TTL；或反过来，只写 BadgerDB，用 goroutine 异步同步到 Redis（失败则记日志+重试队列）。
- 不要在 HTTP handler 里同时调
badger.Update和redis.Set并认为它们“一起生效” - 若必须双写，至少加
context.WithTimeout控制 Redis 调用超时（建议 ≤ 100ms），避免阻塞主流程 - BadgerDB 的
ValueLogFileSize默认 1GB，小文件频繁写入时 IO 高，建议调大到 2GB 并关闭SyncWrites（接受短暂丢失）
HTTP 层缓存头与应用层缓存如何不打架
给响应加了 Cache-Control: public, max-age=300，但后端每次仍查数据库——这是典型的分层缓存未对齐。浏览器、CDN、反向代理（如 Nginx）、Go 应用四层都可能缓存，但各自策略互不知情。
关键动作是：让 Go 应用主动参与 ETag 或 Last-Modified 计算，并在命中本地缓存时返回 304 Not Modified，而非绕过所有中间层直返 200。
- 对静态资源（CSS/JS）用文件哈希命名，配合
Cache-Control: immutable，彻底跳过验证 - 对动态内容（如用户仪表盘），用数据版本号生成 ETag：
ETag: "v2-7a8b9c"，并在If-None-Match匹配时直接 return 304 - Nginx 若配置了
proxy_cache_valid 200 10m，而 Go 返回了Cache-Control: no-cache，Nginx 会忽略缓存——两者必须协调
func dashboardHandler(w http.ResponseWriter, r *http.Request) {
data := loadFromCacheOrDB()
etag := fmt.Sprintf(`"v%d-%x"`, data.Version, md5.Sum([]byte(data.JSON)))
if r.Header.Get("If-None-Match") == etag {
w.WriteHeader(http.StatusNotModified)
return
}
w.Header().Set("ETag", etag)
w.Header().Set("Cache-Control", "public, max-age=60")
json.NewEncoder(w).Encode(data)
}
缓存最难的不是选工具，而是决定哪一层该为哪类数据负责——比如用户登录态由 Redis 管，页面片段由 BadgerDB 管，CDN 只管公开资源，HTTP 头只管客户端行为。混着用，不出问题才怪。
