不用rand.intn()因随机碰撞概率高、无法保证唯一性、长度不可控、含歧义字符，且不满足确定性映射；应使用固定seed的murmurhash32哈希url后转62进制，并通过redis单key存储双向映射确保一致性。
为什么不用 rand.Intn() 生成短码
因为随机碰撞概率在百万级请求下就不可忽视，且无法保证全局唯一、可预测长度、无歧义字符（如 0 和 O）。更糟的是，它不支持“给定原始 URL 必然映射到同一短码”，导致重复插入或 302 跳转不一致。
实际场景中，你希望：https://example.com/a?x=1 每次都生成 abc123，而不是每次随机。否则缓存、日志、统计全乱套。
- 用
MurmurHash32对原始 URL 做哈希，再取模 + 编码成 62 进制（0-9a-zA-Z），能保证确定性映射 - 哈希后截取低 32 位足够应付千万级短链，冲突时加 salt 重试（比如拼上时间戳毫秒）
- 别直接用
hash/maphash—— 它是 per-process 随机种子，重启后结果不同，不适合持久化短码
如何用 murmur3 库生成稳定短码
Go 官方没内置 MurmurHash，得用第三方，但注意选支持 Sum32() 且 seed 可控的实现，比如 github.com/spaolacci/murmur3。
常见错误是忽略 seed 设置：默认 seed 是 0，看似稳定，但一旦你后期想扩容分片（比如按短码首字母拆 Redis 实例），就必须能复现历史哈希值 —— 所以 seed 必须硬编码，不能用 time.Now().UnixNano()。
立即学习“go语言免费学习笔记（深入）”；
- 固定 seed 示例：
h := murmur3.New32WithSeed(0xdeadbeef) - 写入前先
h.Write([]byte(longURL))，再调用h.Sum32() - 把
uint32转成 62 进制字符串时，避免用递归或字符串拼接，用预分配[]byte更快 - 如果短码长度要固定为 6 位，记得对
Sum32() % (62^6)再编码，而不是直接截取哈希值低位（否则分布不均）
Redis 存储结构怎么设计才不踩坑
短链服务本质是「长→短」和「短→长」两个映射，但很多人只存一个方向，导致跳转时查不到原 URL。
典型错误是用两个独立 key：short:abc123 存原 URL，long:https://... 存短码 —— 看似合理，但并发写入时可能产生脏数据（比如 A 写了短码，B 同时写同 URL 的短码，覆盖了 A 的 long-key）。
- 推荐单 key 存完整映射：
url:abc123→{"long":"https://...","created":171xxxxxx,"hits":0}，用 Redis JSON 或哈希类型 - 用
SETNX（redis.SetNX(ctx, "short:"+code, longURL, expire)）保证短码唯一性，失败则重试生成新码 - 别用
INCR维护计数器单独存访问量 —— 容易丢数据；改用HINCRBY url:abc123 hits 1原子更新 - 过期时间必须设，但别设太短（比如 1 小时），否则热门链接反复重建，压垮 DB；建议 30 天 + 后台异步清理冷数据
跳转时为什么 GET 返回 404 却查不到 Redis key
最常见原因是短码被意外截断或编码污染：前端传过来的 /go/abc123? 里带了问号、空格、斜杠，或者用了 URL 编码（如 abc%3123），但代码里直接拿 r.URL.Path 拼接，没做 strings.TrimPrefix() 或 url.PathUnescape()。
另一个隐蔽问题是 Redis key 大小写敏感，而短码生成时若混入大写 A-Z，但 Nginx 或 CDN 默认把路径转小写转发，导致 key 查不到。
- 统一在入库前把短码转小写（或全大写），读取时也强制转换，避免大小写歧义
- 用
redis.Get(ctx, "url:"+strings.ToLower(code)).Val()，别依赖客户端是否保持原样 - 加一层日志：记录每次跳转的原始 path、清洗后 code、Redis 查询 key，5 分钟内出现 10 次 “key not found” 就触发告警
- 别在跳转 handler 里做重定向前校验权限 —— 会拖慢 302，权限检查应放在短码生成环节或单独网关层
短链最难的不是生成，是让每个环节都接受「同一个字符串在任意时间、任意机器、任意中间件里都算出完全相同的 key」—— 从哈希 seed 到 URL 解析，再到 Redis key 拼接，漏掉一个 normalize 步骤，线上就静默丢请求。
