互联网上的链接越来越长，复制粘贴时常常打断段落排版，社交平台还有严格的字数限制。把冗长的网址压缩成几个字符，背后是一套精巧的技术架构。

核心机制其实是一张查询表。服务器端维护着长网址与短码的对应关系，用户点击短链接时，服务端查表找到原始地址，通过HTTP重定向完成跳转。这张表的设计决定了整个系统的性能天花板。

生成短码有几种典型思路。哈希算法是最直接的方案，MD5或SHA-1把任意长度的输入碾成固定长度的指纹，截取前几位就能当短码用。但哈希碰撞不可避免——两个不同网址算出相同结果，后写入的那个会覆盖前者。工程上通常采用"冲突检测+重哈希"的策略，或者干脆在哈希值里混入时间戳、随机盐，把碰撞概率压到忽略不计。



Base64编码走的是另一条路。把网址转成二进制，再按6位一组映射到64个可见字符，理论上能比原串缩短四分之一。问题是编码结果仍可能长达数十字符，而且夹杂着大小写混杂的字母数字，手动输入时容易出错。

更务实的做法是自己设计进制转换系统。把数据库自增ID当成十进制数，转换成62进制（0-9、a-z、A-Z），6位字符就能表示568亿条记录。这种方案天然保证唯一性，递增发号也避免了重复检查的开销。如果需要更短的码，可以牺牲一部分容量，改用更大的字符集，甚至剔除容易混淆的字符（比如0和O、1和l）。

重定向时的状态码选择暗藏玄机。301永久重定向会让浏览器缓存结果，后续访问直接跳过长链服务器，减轻负载却丢失了统计数据。302临时重定向每次都要回源查询，便于追踪点击热力图，但服务器压力持续累积。营销场景偏爱后者，内容分发则倾向前者。

实际部署中，短链服务还要应对更复杂的挑战。短码被恶意遍历怎么办？需要加签名校验或频率限制。原始链接失效如何感知？得做异步存活检测。高并发场景下，发号器可能成为瓶颈，于是有了雪花算法分布式生成、Redis预分配号段等优化手段。

这些技术最终服务于具体的业务场景。微博限140字时，短链能省出更多表达空间；短信按条计费，压缩后的链接直接降低投放成本；线下海报印刷二维码，短码对应的图案更稀疏、扫描容错率更高。甚至某些安全场景里，短链还能充当"防火墙"——对外暴露的是易失效的短码，背后长链可以随时更换，阻断恶意传播链条。