冷热分离本质是路由逻辑抽象而非硬编码存储路径，须通过统一storage接口、工厂函数和分层降级实现可维护性，并严格隔离热冷字段、校验归档完整性、解耦分片键与冷热判定。
冷热分离不是存到不同数据库，而是读写路径自动路由
直接在业务层硬编码 redis.Get 和 s3.PutObject 是最常见错误——后续换存储、加温层、改策略时，所有调用点都要改。真正可维护的做法是抽象出统一接口，让路由逻辑集中可控。
- 定义
Storage接口，只暴露Get/Put/Delete方法，不暴露底层细节 - 用工厂函数
NewStorage(level string)返回具体实现，level 可为"hot"、"warm"、"cold" -
Get必须支持降级：查不到热层就查温层，再查不到才查冷层，最后返回storage.ErrNotFound -
Put默认只写热层，冷数据归档走异步协程（例如用time.AfterFunc(24*time.Hour, moveToCold)），避免阻塞主流程
热数据必须低延迟，但别把所有字段都塞进同一个 struct
全局变量或高频更新的 struct 如果混入配置、调试开关等冷字段，会导致整个缓存行频繁失效——哪怕只改一个 Debug 字段，也会让 CPU 核心间同步整块 64 字节缓存行，性能断崖下跌。
- 热字段（如计数器、状态标志）单独拎出来，用
[128]byte填充确保独占缓存行 - 冷字段（如
Timeout、Endpoint）放在另一个 struct，不加填充 - 避免在热 struct 中嵌入指针或
interface{}，它们会引入不可控的内存跳转 - 示例中
HotStats和ColdConfig分开定义，并通过指针组合进主结构体，就是为隔离访问模式
冷数据归档前不校验完整性，等于埋定时静默损坏
写入 S3/MinIO 后不比对 SHA256，一旦网络抖动或磁盘静默错误导致数据截断，系统毫无感知——直到某天查冷数据失败，才发现订单记录少了最后 3 字节。
- 归档前计算源数据
sha256.Sum256，写入对象时作为x-amz-meta-sha256header 一并上传 - 归档后立即发起 HEAD 请求，校验 header 中的 hash 与本地计算值是否一致
- 不一致则触发重试 + 告警，禁止标记该条数据为“已归档”
- 这个步骤不能省，2026 年 6 月已有线上事故因跳过此步导致批量数据恢复失败
分片键和冷热判断不能复用同一字段
用 userID 既做分库分表路由，又当冷热判定依据（比如“90 天未登录即归档”），会导致冷数据分散在所有分片里，迁移成本指数上升——你得遍历全部 128 个分表扫描时间戳。
- 冷热判断应基于独立元数据字段，如
LastAccessedAt或UpdatedAt，且该字段需建索引 - 分片键保持稳定（如
userID或tenantID），不参与冷热决策 - 归档任务按时间范围批量扫表（
WHERE LastAccessedAt ），再根据分片键定位物理位置，而不是反向推导 - 如果业务允许，可在写入时就打标：
INSERT ... VALUES (..., 'hot')，避免运行时反复计算
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
