缓存预热必须在http.listenandserve启动前同步执行于main()中，紧接initdb()和initredis()之后；禁用init()和goroutine异步预热，需超时控制、分页查询、pipeline写入、锁机制及降级校验。
缓存预热必须在 http.ListenAndServe 启动前完成，且所有依赖（redis.Client、*sql.DB、配置）已初始化完毕；否则请求会穿透 DB 或直接 panic 报 redis: connection closed、nil pointer dereference。
预热该放在 main() 里还是 init()？
init() 太早，redis.Client 可能还是 nil，sql.DB 连接池也未建立，一调用就 panic。正确顺序是：InitDB() → InitRedis() → preloadCache() → http.ListenAndServe()。
- 别把预热逻辑塞进任何包级
init()函数 - 如果用了 Wire 等 DI 框架，确保预热函数是显式调用的，不是被自动 resolve 的“服务”
- 全局变量（如
var cache *redis.Client）必须在preloadCache()前完成赋值，否则cache.Pipeline()会 panic
为什么不能用 goroutine 异步预热？
Go 主 goroutine 在 http.ListenAndServe 返回后就退出，其他 goroutine 可能被强制终止，导致预热中途丢弃、缓存写入不全、甚至连接泄漏。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 常见错误现象：
redis: connection closed日志出现在预热中间，或只加载了前 200 条数据但 DB 已查了 1w 行 - 禁止写
go preloadCache()这类裸 goroutine - 若真要“后台补全”，可用
sync.WaitGroup+context.WithTimeout同步等待，但主流程仍需明确控制是否就绪
从 MySQL 加热点数据到 Redis 怎么避免拖垮数据库？
直接 SELECT * FROM product WHERE is_hot = true 是高危操作：大表会触发深分页、锁表、OOM；字段冗余还会让 Redis 内存暴涨。
- 只查必要字段：
SELECT id, name, price, updated_at FROM product WHERE status = 1 ORDER BY pv DESC LIMIT 10000 - 用游标分页替代 OFFSET：
WHERE id > ? ORDER BY id LIMIT 100，每次取 last_id 继续 - 加显式隔离级别：
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ，确保看到一致快照 - 批量走 pipeline：
pipe := redisClient.Pipeline()，每批 ≤1000 条，最后必须调用pipe.Exec(ctx)
预热失败怎么处理才不卡住启动？
预热失败不能 panic 全局，也不能静默跳过——得留痕、可降级、能观测。
- 必须用
context.WithTimeout(ctx, 5*time.Second)包裹整个预热流程，超时后记录 warn 日志 - 设降级标记：
atomic.StoreBool(&cacheWarmedUp, false)，后续 handler 可据此决定是否 fallback 到 DB - 日志要带上下文：比如 “warm up failed for product hot list: context deadline exceeded, loaded 732/10000 keys”
- 跨 Pod 重复预热风险真实存在，单靠
sync.Once不够；需用SETNX cache_warmup_lock 1 EX 30抢锁，失败则 sleep 后重试或跳过
最容易被忽略的是：预热不是 dump 全量数据，而是按真实访问模式精筛子集；以及 pipeline 写入漏掉 Exec() 就等于白写——这两点在线上出问题时往往最难定位。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
