今すぐログイン 刷微博、收短信或者看公众号的时候，你大概率见过那种被压缩成一小串字符的链接。明明点进去还是同一个网页，显示的地址却可能只有十几个字母。所谓“长链接转短链接”，其实就是给原网址做了一次瘦身。
它的核心原理并不复杂。服务端会维护一张映射表，把短地址和长地址一一对应起来。短链接就像一把钥匙，用户点击后，服务器先去表里查出对应的长链接，再把请求重定向过去。真正决定你最终打开哪个页面的，其实是服务器里那张“对照表”。
目前把长地址压短的做法，大致可以分为几类。
最常用的是哈希算法。用 MD5、SHA-1 这类哈希函数把长链接映射成一个固定长度的字符串，再拼上短链域名，就能生成一条短链接。这种方式生成速度快，长度也固定。但哈希存在冲突风险：两个不同的长地址可能算出相同的哈希值。所以实际使用时通常会加入随机数、时间戳，或者在冲突时自增序号，以此来保证唯一性。
第二种是 Base64 编码。把长链接转成二进制数据，再做 Base64 编码，得到一串可打印字符。这种方法实现起来很简单，但编码结果通常还是偏长，而且夹杂着大小写字母、数字和加减斜杠，既不好看也不好记。真正做短链时，往往还要再截断或二次处理。
第三种是自定义算法。根据业务规则自己设计生成逻辑，比如抽取部分字符、按规则替换，或者采用类似“62 进制”这样的编码方式。自己掌控的好处是灵活，但前提是必须保证短码唯一、随机、可逆，最好还能抗猜测。否则一旦被枚举出来，就可能造成数据泄露等问题。
第四种是直接调用第三方短链服务，例如快缩短网址、Bitly、TinyURL 等。这些平台已经把生成、存储、跳转、统计整套链路搭好了，用户只需要调用接口或者粘贴长地址，就能拿到短链接。对于不想自建系统的团队来说，这是最省事的方案。
短链接真正派得上用场的地方其实不少。社交媒体平台有字符限制，短链接能省下宝贵的字数，排版也更清爽；短信和邮件里篇幅本来就有限，短链接不仅省空间，看起来也不像乱码；在营销推广场景中，短链接还能附带点击统计，方便追踪广告效果和用户来源；一些 API 接口也喜欢用短链接作为回调地址或参数，减少传输体积。
当然，具体选哪种实现方式，还是要看实际需求。如果只是临时分享一条链接，第三方服务最方便；如果是企业级应用，每天承载大量访问，就需要自建系统，自己控制唯一性和安全性。无论哪种方式，唯一性、可读性、稳定性，以及对数据的持续监控，都是不能忽略的关键点。