只要节点数N变化，几乎所有key归属都会改变——如从4库扩到5库，约80% key重映射，引发缓存雪崩、数据库QPS翻倍、连接池打满，且key分布不均时会加剧热点问题。
Go 里用 hash(key) % N 做分片，什么情况下会崩
只要节点数 N 变了，几乎所有 key 的归属都会变——比如从 4 个库扩到 5 个，约 80% 的 key 重映射。真实压测中这直接触发缓存雪崩、数据库 QPS 翻倍、连接池打满。
这不是理论风险：业务上线后加库、缩容、故障剔除节点，% 运算会让整个数据路由逻辑瞬间失效。尤其当 key 分布本身不均（如大量 "order_202605" 前缀），取模还会加剧热点问题。
- 别在配置里写死
numShards = 8就完事，得提前规划扩容路径 - 如果必须用取模，至少确保
N是 2 的幂（如 4/8/16/32），后续可用位运算hash & (N-1)替代除法，但依然解决不了重映射问题 - 日志里一旦出现批量
"key not found in shard X, fallback to scan all"，基本就是取模分片开始反噬了
Go 实现范围分片时，user_id 和 created_at 怎么组合才不踩坑
纯按 user_id 范围分片，容易导致新注册用户集中写入最新分片；纯按时间分片，又会让单个用户的数据散落在多个库表里，查全量订单得跨 N 个库 JOIN。
稳妥做法是双字段嵌套：先用 user_id % 100 算出“用户桶”，再按 created_at 月粒度分表。例如 user_id=12345 落在桶 45，则所有该用户的记录都进 orders_45_202605 表。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 桶数量建议固定（如 100），避免后续调整；表名用
bucket + 时间拼接，不用动态计算 - 查询时必须带
user_id才能定位桶，否则退化为全库扫描 - 不要用
created_at BETWEEN ? AND ?直接跨桶查，应用层得自己拆成多个 goroutine 并发查对应桶
sync.Map 能不能直接当分片 map 用
不能。它不是为高并发写设计的——每次写新 key 都要升级 dirty map，底层仍走全局互斥锁，热点 key 下性能断崖下跌，runtime.futex 占比飙升是典型信号。
真正需要的是每个分片独立锁：32 个 sync.RWMutex + 32 个原生 map，key 通过 fnv.Hash64(key) & 0x1f（即 % 32）落到对应分片。读多写少场景下，RWMutex 能让并发读完全无锁竞争。
- 别手写
shard.mu.RLock(); v, ok := shard.m[key]; shard.mu.RUnlock()再判断写，这是竞态窗口——正确做法是读失败后直接切写锁重试 - 分片数组必须初始化完成再暴露给 goroutine，用
sync.Once或atomic.Value包一层，别裸指针传引用 - 删除操作只调
delete(shard.m, key)，别清空整个分片 map，GC 会疯
一致性哈希在 Go 里落地，为什么不能只靠 hashicorp/memberlist
memberlist 解决的是节点发现和健康探测，不是数据路由。它不提供 key 到节点的映射函数，也不处理虚拟节点、环上位置预分配、负载倾斜检测这些分片核心能力。
真正在 Go 里跑一致性哈希，得自己封装：用 circle := make(map[uint32]string) 存哈希环，每个物理节点加 100–200 个虚拟节点（node+"#"+strconv.Itoa(i)），key 插入前先 hash(key) % 0x100000000 定位顺时针最近节点。扩容时只迁移环上相邻区段，重映射率压到 1% 内。
- 别把哈希环存在内存里就完事，节点变更必须持久化或广播，否则重启后环不一致
- 线上务必加监控：各节点实际承载 key 数量标准差 > 30%，说明虚拟节点数不够或 hash 函数有偏
- Redis 集群用 CRC16 % 16384，这个槽位数是硬编码的，你的服务如果对接 Redis Cluster，
Slot()函数必须严格复现，不能自己另起炉灶
user_id 和 tenant_id 谁该当主键。 
