短链接的核心在于用极短的字符承载冗长的网址信息，其技术实现围绕"压缩—映射—跳转"三个环节展开。

从长串到短码的转换

长网址首先需要被"数字化"。系统通常采用哈希算法生成固定长度的摘要，MD5是常见选择——无论输入多长，输出始终是128位（32位十六进制字符）。例如一条复杂网址经MD5运算后得到e99a18c428cb38d5f260853678922e03，但这32位仍显冗长。



真正的压缩发生在后续处理：将这32位哈希值分段，每段与62进制字符集（26个小写字母+26个大写字母+10个数字）进行取模运算，最终映射为6位短码。6位62进制可产生约568亿种组合，足以支撑大规模应用。部分系统还会加入洗牌扰动，既分散存储压力，也防止短码被 sequential 猜测。



映射关系的持久化

短码与原始网址的对应关系需要可靠存储。关系型数据库是最直接的选择，但面临读写瓶颈——短链服务往往读多写少，且存在明显的热点访问。因此架构上通常分层设计：Redis等内存缓存承载高频查询，持久化数据库作为底仓，LRU策略淘汰冷数据。

存储结构设计需兼顾查询效率。以短码为主键的KV模型最为常见，也可对原始网址建立反向索引用于查重——当同一长链多次提交时，直接返回已生成的短码，避免重复数据。

访问时的重定向链路

用户点击短链后，请求抵达服务端，流程随即启动：解析路径提取短码→缓存查询→必要时回源数据库→获取长网址→返回HTTP重定向响应。

301与302状态码的选择颇有讲究。301永久重定向会被浏览器缓存，后续访问直接跳转长链，减轻服务端压力但丧失统计能力；302临时重定向则每次经过服务端，便于追踪点击数据却消耗更多资源。商业服务往往混合使用，对营销场景用302保活数据，对纯跳转场景用301降本。

工程中的关键细节



碰撞处理是绕不开的课题。哈希空间虽大，但不同网址生成相同短码的概率客观存在。检测机制必不可少：生成后先查重，冲突则换种子重新哈希，或直接在短码后扩展位数。

安全防护维度，短链因不可读性天然适合钓鱼利用。服务方需建立黑名单过滤恶意目标，对敏感跳转增加二次确认，并限制单IP的生成频次防止滥用。HTTPS已是标配，防止中间人篡改跳转目标。

性能优化方面，除了缓存层，CDN边缘节点也可承担首跳解析，将重定向逻辑下沉至离用户更近的位置，进一步压缩首包延迟。



整个技术链条并不复杂，却在高并发场景下考验着系统的极限设计——如何用最少字符支撑最大规模，如何在毫秒级完成解析跳转，正是短链服务的价值所在。