不用rand.Intn因不唯一、不可逆、难扩容；MurmurHash通过确定性哈希+截断+冲突重试平衡可靠性与性能，但仍需DB存储映射并处理碰撞。
为什么不用 rand.Intn 直接生成短码
因为不可逆、不唯一、难扩容。用户分享后点开 404，问题出在“随机”上——它不保证全局唯一，也不支持从短码反查原 URL，更没法水平扩展多实例。MurmurHash 是个折中选择：确定性哈希 + 截断 + 冲突兜底，比纯随机靠谱，比数据库自增 ID 更轻量。
实际用时要注意三点：
-
MurmurHash3_x64_128输出是 16 字节，转成 base64 或 base32 后长度浮动，建议固定截取前 6–8 字符（如hash[:6]），再转base32避免大小写混淆 - 哈希值本身不带业务语义，
https://t.co/abc123中的abc123必须映射到唯一url_id，所以仍需 DB 存储映射关系，哈希只负责生成初始短码 - 冲突真实存在：两个不同 URL 哈希后前 6 字节相同。必须加循环重试逻辑，比如失败就拼上时间戳毫秒或递增序号再哈希一次
Go 里怎么调用 MurmurHash（别自己实现）
直接用 github.com/spaolacci/murmur3 这个库，它经过大量生产验证，比网上零散 gist 可靠。别用 golang.org/x/exp 里的实验版，那个已归档且不维护。
关键实操点：
立即学习“go语言免费学习笔记（深入）”；
- 输入要统一编码：始终用
[]byte(url)，别传string后再转，避免 UTF-8 多字节导致哈希不一致 - 选
murmur3.Sum64就够用，128 位没必要；返回值是uint64，转字符串再截断比操作字节数组更稳 - 示例生成逻辑：
hash := murmur3.Sum64([]byte(originalURL + salt)) // salt 是固定字符串，防简单碰撞 shortCode := base32.StdEncoding.EncodeToString([]byte(strconv.FormatUint(hash, 36)))[:6]
短码冲突时怎么安全重试
DB 唯一索引报 duplicate key violation 是唯一可靠信号，别靠内存 map 判断——分布式下无效。重试不是随便加个数字了事。
推荐策略：
- 第一次失败后，用
originalURL + timestamp_ms再哈希，但 timestamp 要精确到毫秒，否则并发请求可能撞上同一时间戳 - 最多重试 3 次，超过就 fallback 到
uuid.NewString()[0:6]，确保不卡住请求 - 记录日志：把冲突的原始 URL、生成的短码、重试次数都打出来，方便后续分析是否 salt 设计不合理
上线后发现短码重复率高怎么办
大概率是 salt 太弱或哈希截取得太短。6 位 base32 理论上限约 10 亿组合，但实际到 1000 万级就开始明显碰撞。
可动的参数就三个：
- 把截取长度从
[:6]改成[:7]，组合数翻 32 倍，但短码变长，得权衡用户体验 - 换 salt：不要用固定字符串，改用服务启动时生成的随机字符串，重启后不变；或者用域名+端口组合，让不同实例 salt 不同
- 放弃 MurmurHash，改用
xxhash.Sum64（更快）或直接存自增 ID 后 base62 编码（更可控），前者适合读多写少，后者适合强顺序场景
真正麻烦的是已有短码不能变，所有调整都得兼容旧链接跳转。哈希只是生成环节的一环，存储和路由才是长期维护成本所在。
