立即登录 一条拖着 utm 参数、动辄七八十个字符的长链接，用起来处处受限：塞进按字计费的短信里是纯浪费，印上海报会让二维码密得扫不动，丢进微信群还会被折叠成难看的一坨。短链接干的就是这件事——把又臭又长的地址压缩成十几个字符。市面上的工具用起来都一个样：粘贴、点击、生成，几秒钟搞定。但这套流程背后，到底是怎么跑起来的？
原理一句话就能说清：编码映射加重定向。给长链接生成一个独一无二的短码当"钥匙"，数据库里存下短码和原地址的对应关系；用户访问时，服务器查出原始链接，回一个跳转响应即可。道理不难，真正的门道藏在每一步的具体做法里。
先看短码是怎么生成的。最直觉的思路是哈希：拿 MD5 或 SHA-1 对长链接算一遍，取结果的前六七位当短码。优点是快，不用跟任何存储打交道；麻烦在于会撞车——两个不同的长链接可能算出相同的前缀。真碰上冲突，要么换个盐值重算，要么在库里顺延一位，逻辑一下就复杂了。
相比之下，更常见的做法是自增 ID 转 62 进制。0 到 9、a 到 z、A 到 Z，正好凑齐 62 个字符。每来一条长链接，数据库发一个自增 ID，再把这个数字转成 62 进制字符串：ID 是 1，短码就是 "1"；ID 涨到一百万，也不过四位字符。这条路的优点是永远不会冲突，生成成本几乎为零；代价则是短码连续、可预测，有心人加一减一，就能遍历你库里的所有链接。而且整个系统强依赖发号机制，一旦要做分布式部署，还得引入号段模式或者雪花 ID 之类的方案。
第三条路是随机字符串：直接生成 6 到 8 位随机字符，查重通过就入库。它的安全性最好，外人猜不到下一个短码是什么，但每生成一次都得查一次重。更微妙的是，随着库里数据变多，随机碰撞的概率会像生日悖论那样悄悄爬升，重试的开销不容小觑。所以实际系统很少单押一种方案，通常是几种混着用。
短码有了，接下来是存。一张 MySQL 表其实就够撑起基本盘：
CREATE TABLE short_links (
id INT AUTO_INCREMENT PRIMARY KEY,
short_code VARCHAR(8) UNIQUE NOT NULL,
long_url TEXT NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
但只靠数据库，扛不住热门链接的访问洪峰。标准玩法是把热点映射丢进 Redis，查询先走缓存，缓存没命中再回源数据库——这一步直接决定了短链服务能扛住多大的并发。
存储搞定了，再来看跳转。用户点开短链的那一刻，发生的事其实很简单：服务器从 URL 里取出短码，比如
s.com/abc123 里的 abc123，查出对应的长链接，然后返回一个 301 或 302 状态码，并在响应头的 Location 字段里写上目标地址，浏览器收到后自动跳过去。整个过程通常在毫秒级完成。
选 301 还是 302，是一道真正的选择题。301 是永久重定向，浏览器会把它缓存下来，下次再点同一个短链连服务器都不经过，速度最快——但这也意味着你丢掉了后续所有的点击统计，而且目标地址改不了。302 是临时重定向，每次访问都得过一遍服务器，于是点击量、设备类型、访问来源这些数据全能记下来，后台也随时可以把映射指向新的落地页。很多营销工具主打的"链接已经印在海报上、广告已经投出去了，还能临时换网址"，靠的就是 302 加上可修改的映射关系。
到这里，一个能跑的短链系统就成了。但要做到上线扛事，还有一堆边角要打磨：长链接入库前得做归一化，去掉无意义的参数，免得同一个页面被存成几十条记录；要防滥用，设置有效期和访问频率限制，做恶意内容检测，否则短链分分钟变成钓鱼网站的温床；要防遍历，尤其是用自增 ID 方案的时候；等数据量大了，还得考虑分库分表、负载均衡和 CDN 加速，让各地用户都能秒开。
说到底，短链接的核心原理朴素得有点无聊——无非是"起个别名，查表跳转"。但从一个能跑的 demo，到一个扛得住高并发、毫秒级响应、数据可统计、还不被人钻空子的服务，中间隔着的全是工程细节。下次再看到那种只有几位字符的短链，不妨想一想：就这么个小东西背后，其实藏着一套挺完整的系统设计。