Login Now 短链服务做的事情，一句话就能说清楚：把一个又臭又长的网址压成几个字符，用户点开短链，再把他送回原始地址。听着简单，可真要做到稳定、快速、不出错，背后是一整套设计。拆开看，关键环节无非三个：短码怎么生成、数据怎么存、跳转怎么做。
先说短码生成。最直观的思路是哈希——把长链接丢进 MD5 或 SHA-1，拿到一串固定长度的摘要，截取前几位（比如6位）当短码。问题也很直接：哈希一旦截断，冲突几乎躲不掉，两个毫不相干的链接完全可能算出相同的前缀。工程上的补救办法通常是先查库，发现短码被占了就加点盐值重新哈希，或者干脆在哈希结果后面拼一段自增序列，把冲突概率压到可以忽略的程度。
更主流的做法是自增ID加进制转换。每进来一条新链接，数据库分配一个递增的数字ID，再把这个ID换算成62进制——也就是用 a-z、A-Z、0-9 这62个字符来表示数字。具体做法不复杂：反复除以62取余数，把余数映射到字符表上，最后倒序拼起来。拿ID为125的链接举例，125除以62商2余1，映射出来就是"cb"这样的两位短码。这套逻辑有点像Excel的列名：1是a，26是z，27就变成aa，位数跟着ID自然增长。它最大的好处是天生不冲突——ID唯一，短码必然唯一。容量也够看，6位短码理论上能覆盖五百多亿条链接，对绝大多数服务来说根本用不完。
除了系统生成，不少服务还允许用户自定义短码，比如把活动链接缩成 short.url/summer2024 这种好记的形式。实现上没什么玄机：用户提交短码后查一下数据库，没被占用就写入映射，被占了就提示换一个。
再看存储。短链服务的核心数据结构其实就是一张映射表，典型设计大概长这样：
CREATE TABLE short_urls (
short_code VARCHAR(10) PRIMARY KEY,
original_url TEXT NOT NULL,
created_at TIMESTAMP,
expires_at TIMESTAMP,
clicks INT DEFAULT 0
);
短码做主键，配上原始链接、创建时间、可选的过期时间和点击计数，基本就够用了。不过实际部署很少只靠 MySQL 这类关系型数据库，热点短码通常还会放进 Redis 里缓存——热门链接的访问量可能是普通链接的成千上万倍，每次都查磁盘肯定顶不住。
跳转是整条链路里对性能要求最高的一环。用户访问 http://short.url/abc123 时，服务器解析出短码，先查缓存、没有再查数据库，拿到原始链接后返回重定向响应。这里有个值得琢磨的细节：用301还是302？301是永久重定向，浏览器会把它缓存下来，下次访问直接奔目标地址，根本不经过短链服务器——请求是省了，但点击统计全丢了，之后想换目标地址也没辙。302是临时重定向，每次访问都得老老实实过一遍服务器，统计和改跳转都好办。所以需要做数据分析的短链服务几乎都选302。每处理一次跳转，数据库里的 clicks 加一，顺手再记下访问者的IP、浏览器、时间和来源页面，后面的分析报表全靠这些数据撑着。
流量上来之后，单台机器肯定扛不住。常见的做法是负载均衡，把请求分摊到多台服务器上，避免单点故障；再往上还能给热门短链挂CDN缓存，让离用户最近的节点直接响应，数据库的压力能卸掉一大半。
基础功能之外，还有一些常见的进阶玩法。链接过期很好实现：表里存个 expires_at，访问时比对一下当前时间就行，适合做限时活动。密码保护是给短码配一个访问密码，用户输对了才放行。地域限制则通过IP判断访问者所在地区，不在允许范围内就拒绝跳转。这几样加上前面提到的点击统计，一套还算完整的数据分析能力就拼出来了。
当然，短链服务天然容易被滥用，安全这块省不得。防批量恶意生成，可以限制单个IP的生成频率，必要时上验证码；反钓鱼靠黑名单库或检测模型，用户提交链接时先过一遍，确认不是恶意网站才生成短码；另外HTTPS基本是标配，少了它，跳转过程很容易被中间人动手脚。
把整条流程串起来看：用户提交一个长链接，服务生成短码 abc123 并写入数据库；有人访问短链，服务器查到映射关系，返回302跳转到原始地址，点击数顺便加一。说起来不过几行逻辑，但短码怎么不冲突、跳转怎么扛住高并发、数据怎么防滥用，每个细节背后都是取舍。短链服务的技术门槛从来不在"能不能做"，而在"能不能在真实流量下一直稳"。