把冗长的网址压缩成几串字符，这个看似简单的操作背后藏着不少技术门道。无论是发朋友圈时被字数限制逼到墙角，还是做投放时需要追踪每一分钱的效果，短链都已成数字时代的刚需工具。

短链到底解决了什么

除了肉眼可见的"变短"，短链真正的价值在于释放了信息密度。微博140字的紧箍咒下，一个原始链接可能直接吃掉三分之一的配额；短信场景里，按条计费的字节数容不得半点浪费。更隐蔽的好处是二维码的容错率——链接越短，黑白格子的分布越稀疏，扫码成功率在复杂光线环境下能差出几个数量级。

数据追踪则是另一个隐形战场。原始链接埋点需要改动目标页面，而短链天然自带流量入口，点击热力图、来源渠道、设备分布都能在这一跳之间完成采集。

重定向：短链工作的核心机制



当手指点下那个以 t.cn 或 bit.ly 开头的地址，一场毫秒级的接力随即展开。服务器返回 302 状态码，在 HTTP 响应头的 Location 字段里塞入原始网址，浏览器接到指令后立刻转向新地址。这个"临时重定向"的设计颇有深意——既保留了未来修改指向的灵活性，又让搜索引擎明白权重该算在谁的头上。

两条技术路线的抉择

哈希派选择用 MurmurHash 这类非加密算法对长链做指纹提取。相比 MD5 或 SHA 家族，它的计算速度能快上数倍，生成的 32 位整数再经 62 进制编码（0-9、a-z、A-Z），六位字符就能覆盖 568 亿种组合。隐患在于碰撞概率，当库存突破千万级时，需要布隆过滤器或预留二次哈希的逃生通道。

自增 ID 派则更像发票编号管理。MySQL 的自增主键、Redis 的原子计数、Snowflake 的分布式时间戳，都能产出绝不重复的数字序列。同样转 62 进制后，短链呈现出可预测的递增规律，这对某些业务是特征，对另一些则是需要打散混淆的弱点。



两种方案最终都要落库。键值对存储里，短码作键、长链作值是最直白的映射；若需支撑统计需求，还得另起一张点击日志表，或者把计数器塞进 Redis 的 HyperLogLog 结构里省些内存。



踩坑实录

高并发下的数据库查询是首个瓶颈。短链服务的读请求往往比写高出两个数量级，本地缓存或 Redis 集群的预热策略直接影响响应延迟。哈希冲突的兜底方案要在设计初期就预留——是发现碰撞后追加随机字符，还是直接换用 ID 生成方案，决定了架构的弹性空间。

安全层面，短链的不可预测性本身就是防护。若采用连续 ID，竞争对手只需遍历数字就能扒光你的全部投放链接；加上足够的随机盐，扫描成本才能趋近无穷。另外要警惕开放接口被滥用成垃圾信息的中转站， referer 校验、速率限制、黑名单机制缺一不可。

一个极简实现示例



面对 https://www.example.com/long/url/with/many/parameters 这样的庞然大物，MurmurHash 算出 123456789，转 62 进制得 abcD1，最终形态 http://short.url/abcD1 便诞生了。这个六字符的替身，将在数据库里默默守着那个 87 字符的原身，直到某次点击触发重定向，完成它的使命。

短链系统的复杂度随规模指数上升。个人工具用哈希加本地文件就能跑通，日活过亿的产品则需要考虑多活部署、冷热数据分离、甚至边缘节点的 302 响应缓存。但无论规模大小，理解重定向的本质、权衡唯一性与可读性、守住安全与性能的底线，都是绕不开的功课。