Войти сейчас 收到营销短信时，你大概注意过，里面的链接往往只有短短一截：一个域名，后面跟几个字母数字，点开却能跳进某个具体的商品页。要知道，商品页的原始地址通常拖着一大串参数，直接塞进短信既难看又浪费字数，印在海报上还会把二维码挤得密密麻麻，扫起来都费劲。短链服务解决的正是这类麻烦。但问题来了：区区几个字符，凭什么能精准指向一条几百字符的长链接？
答案的第一层是重定向。短链本身并不携带目标页面的任何信息，它更像个门牌号。bit.ly、新浪 t.cn 这类服务商会在自己的服务器上存一份"短码对应长链"的对照表。你访问短链时，服务器查出背后的长链，返回一个 301 或 302 状态码，告诉浏览器"你要找的东西在别处"，浏览器随即自动跳过去，整个过程通常只要几十毫秒，人几乎察觉不到。有意思的是，不少短链服务偏偏爱用 302 临时重定向，而不是 301 永久重定向——原因很实际：301 会被浏览器缓存，用户下次再点同一个短链就不经过服务器了，点击量、访问来源这些统计数据也就无从谈起。
第二层是短码的生成，这里轮到哈希算法登场。常见做法是对长链接做一次 MD5 或 SHA-1 运算，得到一个固定长度的哈希值，再通过 Base62 编码把它转换成由大小写字母和数字组成的字符串，最后截取前几位当作短码。为什么偏偏是 62 个字符？可选字符越多，同样长度能装下的组合就越多——6 位短码就有 62 的 6 次方、超过五百亿种组合，应付一般业务绰绰有余。
有人可能会担心：两条不同的长链，算出同一个短码怎么办？这种哈希冲突理论上确实存在，只是概率极低，处理起来也不复杂——发现生成的短码已被占用，就给原链接加一点随机"盐"再算一遍，或者做二次哈希，直到拿到不冲突的结果为止。工程实践中还有另一条路线：用自增 ID 配合 Base62 转换，按顺序发号，天然不会撞车；代价是短码容易被按规律枚举，业务量大时也不如哈希方案灵活。
第三层是存储与查询。映射关系通常以键值对的形式存放：短码作键，长链作值，顺带记录过期时间、创建者、点击数等元信息。这种"按 key 查 value"的场景，交给 Redis 之类的内存键值数据库再合适不过，配合合理的索引设计，一次查询可以压到毫秒级。过期时间也值得单独一提：临时活动页设七天有效，到期自动清理；长期使用的链接则设为永久，各取所需。
当然，系统随机生成的短码并不总让人满意。做品牌传播时，大家更希望短码本身就能被读懂，比如带上活动名或品牌名，自定义短链正是为此准备的。用户提交想要的后缀，系统先检查它是否已被占用、是否符合长度和字符规范——一般只允许字母和数字——通过后才会建立映射。规则很简单：先到先得，好短码永远属于手快的人。
把这几层拼起来，一个短链服务的基本轮廓就清晰了。但要真正扛住生产环境，还有几道坎要过。
先说流量。短链服务的访问分布极不均匀，少数热门链接往往贡献绝大多数点击。把这部分热点数据放进缓存，能挡掉大部分数据库查询；再配合负载均衡把请求分摊到多台机器，才能平稳消化营销活动带来的瞬时洪峰。
再说安全。一方面要防止有人调用接口批量刷短码、白白占用资源，常见做法是限流加校验；另一方面要对映射关系做加密或签名，防止被人篡改指向。更深一层的麻烦在于，短链隐藏了真实地址，天然容易被钓鱼和灰产利用——这也是各大平台对陌生短链格外警惕、动辄拦截的原因之一。理解了这个背景，再回头看市面上那些"防红防封"的功能，就知道它们在解决什么痛点了。
至于扩展性，随着数据量增长，单库单表迟早装不下，分布式存储是必经之路。短码长度也不能一成不变：位数太短很快就会耗尽，太长又失去了"短"的意义，只能在存储成本和可读性之间动态权衡。
回过头看，短链的原理其实算不上高深：重定向负责指路，哈希负责造码，数据库负责记账。真正难的，是把这三件事在高并发、海量数据的场景下做得又快又稳。下次再点开一个短链，不妨想一想——那几十毫秒里，有一整套系统在替你跑腿。