短链接相信大家都不陌生。刷微博时看到的那些tb.cn、bit.ly开头的链接，电商促销海报上的二维码，点进去就直接跳转到目标页面，其实背后都是短链接服务在起作用。无论是日常聊天分享，还是大型营销活动，这种技术都应用得非常广泛。今天我们就来聊聊，长链接是怎么变成短链接的，这中间究竟发生了什么。

短链接的核心逻辑并不复杂：把一串冗长的网址压缩成短短几个字符，用户点击时再帮他“导航”到原始页面。整个过程通常靠HTTP的302或301重定向来实现——服务器收到短链接请求后，返回一个跳转指令，浏览器自动打开目标URL。看起来一键直达，但其实现涉及编码算法、数据存储和性能优化等多个技术环节。



长链接变短链接，业界主流的做法有两种。

第一种是基于哈希的方案。先对原始URL做MD5处理，得到一串32位的哈希值，然后把这串哈希值切分成几段，从中选择合适的片段进行Base62编码，最后生成6到8位的短码。Base62其实就是0-9、a-z、A-Z这62个字符组成的一套编码体系，比Base64少了“+”和“”两个符号，用在URL里更安全，不会出现特殊字符导致解析问题。

第二种思路更直接——给每个长链接分配一个自增的数字ID，把ID转成Base62编码后就成了短链接。还原的时候，通过这个ID去查表就能拿到原始URL。这两种方案各有权衡，哈希方案不需要存储映射关系，但存在极低概率的碰撞风险；自增ID方案实现简单，但需要额外的存储空间来保存对应关系。

这里有个常见的误解需要澄清：MD5是加密算法，Base64是编码方式，两者完全是不同的概念。MD5生成的128位哈希值本身，不能直接“转换”成Base64编码。



短链接还原的过程，说起来比生成更简单。用户访问短链接时，系统在数据库或缓存里查一下这个短码对应哪个长URL，查到了就返回302重定向，没查到就显示404。为了让跳转更快，很多服务会加一层“最近使用”的内存缓存，把高频访问的映射关系放在里面，缓存过期时间通常设为一小时。



实际开发中还有几个地方需要注意。

一是冲突问题。不同长链接理论上可能生成相同的短码，虽然概率很低，但生成算法里最好加上校验，发现冲突及时处理。二是有效期设置。营销活动用的短链接可能活不过几天，永久有效的链接也要考虑数据增长带来的存储压力。三是安全性问题。字符集太小或者编码规律太明显的短链接，容易被人用脚本暴力枚举破解。最后，微信等平台对域名审核比较严格，如果你的域名涉及诱导分享、虚假信息等内容，可能会被屏蔽，导致短链接直接失效。

搞清楚了这些核心原理，开发一个可用的短链接服务其实并不难。选什么编码方案、要不要加缓存、设置多长有效期，这些选择最终都要看具体业务场景来决定。