立即登入 短信里、微博上、海报二维码中，我们常能看到那种只有短短一截的链接。它们背后是一套不算复杂、但相当精巧的技术体系。把长链接变短，核心就三步：建立映射、生成短码、完成跳转。可要真正把它做稳做好，里面藏着不少值得琢磨的细节。
一切从映射存储开始。用户提交一个长链接，比如 https://example.com/very/long/path?param=1 这样的地址，短链服务会为它生成一个唯一的短码，假设是 abc123，再把这组对应关系写进数据库——MySQL、Redis 都行——形成一张映射表。这张表里通常不只有短码和长链接两个字段，还会顺带记下过期时间、点击次数之类的扩展信息，为后续各种运营功能打底。
短码又是怎么来的？常见的路子有三条。第一种是自增 ID 转换：数据库每插入一条记录，ID 就自动加一，再把这个 ID 转成 62 进制——0-9 加上大小写字母，一共 62 个字符——短码就出来了。比如 ID 为 1001，转换后得到 1zw。这种方式天然不会重复，实现起来也最省事。第二种是哈希算法：对长链接做一次 MD5 或 SHA-1 运算，截取一段字符当短码用。好处是同一个链接总能得到同一个短码，坏处是存在哈希碰撞的可能——两个不同的链接可能算出相同的结果，得额外写一套冲突处理逻辑。第三种最直白：随机生成一串 6 位左右的字母数字组合，生成后查一下库里有没有撞车，没撞就用，撞了再来一次。
映射建好了，接下来轮到用户真正能感知的环节：重定向。有人访问 short.ly/abc123 时，服务器取出短码部分，去数据库查出对应的长链接，然后返回一个 301 或 302 状态码，浏览器收到响应后自动跳到目标地址。301 是永久重定向，302 是临时重定向，两者在搜索引擎权重传递和浏览器缓存行为上有差别，选哪个要看具体业务场景。
基本流程跑通了，再看看优化层面的考量。短码长度就是个需要权衡的问题：太短组合不够用，太长又失去了"短"的意义。算笔账就知道了——6 位短码能支持 62 的 6 次方、约 568 亿个组合，对绝大多数业务来说绰绰有余。如果用户想自定义短码，比如嵌入品牌名方便识别和传播，系统还得先检查这个码有没有被人占掉。
性能上，每次访问都直接查数据库，显然扛不住大流量。所以一般会引入 Redis 缓存热门短码的映射关系，让大部分请求直接命中内存；再配合 CDN 节点缓存重定向响应，全球各地用户的访问速度就有了保障。
防滥用同样不能少。短链服务很容易被灰产盯上，拿去包装钓鱼链接或者恶意网址。常见的应对是限制单个 IP 的生成频率，防止有人批量刷短链；对可疑的敏感链接，则用自动拦截加人工审核双管齐下。
基础跳转之外，成熟的短链服务往往还会扩展出一系列高级功能。链接过期，是在数据库里存一个时间戳，每次访问先校验，过期就返回错误页。访问统计是很多运营者最看重的部分：每次重定向发生时，系统顺手更新点击次数，并记录访客的地理位置、设备类型等信息，方便评估推广效果。面向开发者，还会提供批量生成的 API 接口，发个 POST 请求就能批量拿到短链，方便集成进自己的业务系统。
把整个过程串起来看：用户提交长链接，服务生成短码 abc123 并存好映射关系；有人访问短链时，服务器查出对应的长链接，返回 302 重定向，浏览器自动跳过去。从用户视角看只是眨眼一瞬间，背后却走完了查询、校验、统计一整套流程。
当然，真要上线运营一个短链服务，挑战也不少。高并发是第一道坎——海量请求涌过来，单点数据库根本吃不消，得靠分布式数据库加 Redis Cluster 这类缓存集群分摊压力。短码冲突前面提过，用哈希方案就必须设计好碰撞处理机制，或者干脆采用能保证唯一性的生成方式。还有数据安全问题：如果短码是有规律的自增序列，别人完全可以挨个枚举，把库里的链接爬个遍。所以有些服务会加盐哈希，或者干脆限制生成权限。
说到底，短链服务的底层逻辑并不神秘：映射存储打底，高效算法出码，重定向完成跳转。真正的功夫，在于给这个简单的骨架填上性能、安全、统计这些血肉，让它在真实的高流量环境里稳稳当当地跑下去。