应选用 hash/fnv（尤其是 fnv.new32a()）：快、分布均匀、输出确定、无加密开销；crypto/sha256 仅在需验签或防恶意碰撞时使用，且其性能比 fnv 慢 3–5 倍、摘要冗余。
字符串哈希该用 fnv 还是 crypto/sha256？
分片路由的哈希不是为了防篡改，而是为了把 user_id、file_key 这类字符串稳定映射到有限节点上。选错哈希类型会直接拖慢整个链路——crypto/sha256 比 hash/fnv 慢 3–5 倍，且生成 32 字节摘要纯属浪费。
真实场景中：
- hash/fnv（尤其是 fnv.New32a()）是默认选择：快、分布均匀、输出确定、无加密开销
- crypto/sha256 只在两类情况必须用：客户端传来的 X-Final-SHA256 需服务端复验；或 key 本身不可信（如用户输入的任意字符串），需抗碰撞防恶意打散
常见错误：
- 把 sha256.Sum(nil) 当作整数用，结果得到的是 struct 而非 uint64 → panic
- 用 md5 做分片哈希，既不安全又比 fnv 慢，还容易因低字节冲突导致倾斜
hash/fnv.New32a() 的 Sum32() 和 Sum(nil) 别混用
Sum32() 返回 uint32，适合直接参与取模或位运算；Sum(nil) 返回 []byte，要先转成 int 才能用，多一次拷贝且易出错。
正确写法示例：
h := fnv.New32a()
h.Write([]byte("user_12345"))
shardID := int(h.Sum32()) % numShards // ✅ 直接、高效、无额外分配
错误写法：
shardID := int(binary.BigEndian.Uint32(h.Sum(nil))) % numShards // ❌ 多余转换，且 h.Sum(nil) 返回长度为 4 的切片，不是固定 uint32
注意：
- Sum32() 是 fnv 包专为分片优化的接口，语义清晰
- 不要用 Sum(nil)[0] | Sum(nil)[1] 手动拼，Go 1.21+ 的 <code>binary 包也未必能对齐字节序
- 如果后续要升级为一致性哈希环，Sum32() 输出可直接喂给 sort.Search，无需再哈希一遍
字符串分片哈希必须带“确定性前缀”防空值/边界问题
直接哈希空字符串 "" 或全零字符串（如 "0000"）会导致大量 key 落到同一 shard，尤其在用户 ID 未规范补零、订单号带前导零时极易触发热点。
稳妥做法是在哈希前统一加一个不可见但确定的前缀：
- 用
"shard:" + key，而非裸 key；避免key == ""时哈希值为 0 - 若 key 来自数据库主键且含前导零（如
"000123"），先strings.TrimLeft(key, "0")再拼接，否则不同格式的相同数值会被分到不同 shard - 不要依赖客户端保证 key 格式，服务端必须做归一化——
getShard("123")和getShard("00123")必须返回相同结果
这个细节线上常被忽略，日志里一旦出现 "shard 0 QPS 突增 300%"，八成是没做前缀或归一化。
分片数量变更时，为什么 hash(key) % N 会崩？
只要 N 一变，几乎所有字符串的 shardID 都会重算。从 8 个节点扩到 9 个，约 88% 的 key 归属改变——缓存击穿、连接池打满、SQL 查询全走 fallback 路径。
真正可用的方案只有两个：
- 用一致性哈希环：每个节点注册 100–200 个虚拟节点，
key哈希后顺时针找最近节点；节点上下线只影响局部环段 - 如果坚持用取模，至少让
N是 2 的幂（如 4/8/16/32），并用hash & (N-1)替代% N加速，但重映射问题依然存在
别信“先跑一周数据看分布再调参”——生产环境没有试错窗口。上线前就得决定是用 github.com/sony/gobreaker 配合 fallback，还是直接上 github.com/yourbasic/hash 的 ring 实现。
最常被漏掉的一点：一致性哈希环的 keys 切片必须保持升序，每次 Add() 后要显式 sort.Ints(m.keys)，否则 sort.Search 查不到正确位置，所有 key 都落到第一个节点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
