Se Connecter Maintenant 翻翻手机里的营销短信，十有八九都能看到一串短短的网址；再把某个商品页的原始链接复制出来，往往长到一屏都放不下，里面塞满参数、符号和看不懂的编码。把后者变成前者，正是短链接技术在做的事。听起来有点神秘，拆开看原理其实并不复杂，真正考验功力的，是工程上的细节。
先澄清一个常见误区：短链接并不是把长链接"压缩"出来的。网址不是文件，没法压缩，真正的做法是建立一个一一对应的映射。系统收到一条长链接，给它分配一个简短标识，把这层对应关系记下来，再拼出一个短网址。等用户点开短网址，服务器查一下映射表，找到原始地址，告诉浏览器"去那边"，浏览器就自动跳过去了——整个过程通常在零点几秒内完成，用户几乎察觉不到。打个比方，这相当于给一栋地址冗长的大楼起了个外号，你报出外号，门卫自然知道该把你往哪儿指。
具体实现上，最常见的方案是数据库映射，行内一般叫"发号器"模式。平台在后台维护一个数据库，每收到一条长链接，就分配一个唯一标识——可以是自增的数字ID，也可以是一串随机字符——再把标识和长链接的对应关系写进库里。假设某条长链接拿到的ID是12345，拼上平台域名，就成了 short.com/12345 这样的短链接。用户访问时，系统按ID查库，取出原始地址，执行跳转。自增ID的好处是天然不重复，实现也简单，但纯递增的编号容易被有心人按顺序遍历，把别人生成的链接一个个翻出来，所以不少平台会改用随机字符串，或者把ID打乱之后再对外展示。
另一条路是哈希算法。思路很直接：把长链接丢进哈希函数，算出一个固定长度的哈希值，截取其中一段当短码。同一条长链接算出来的哈希值永远相同，所以天然支持去重——同一条链接重复提交，系统直接返回已有的短码就行。麻烦出在哈希冲突上：哈希值长度有限，长链接的数量却近乎无限，理论上不同的链接总有可能撞出同一个值。工程上的应对办法不少，比如检测到冲突就往原链接后面添点随机内容重新计算，或者采用多级哈希，总之得保证每个短码只对应一个目标地址。
还有一种常和发号器搭配使用的手段：字符编码转换，典型代表是Base62。十进制只有0到9十个符号，Base62则凑齐了数字和大小写字母，一共62个字符。同一个数字用62进制写出来，位数会明显更短——一个七八位的十进制ID，转成Base62可能只要四五个字符。别小看省下来的这一两位，短链接本来就是锱铢必较的东西，每短一个字符，放进短信和海报里都更友好。不过要说明一点：编码转换只负责把编号"写短"，唯一性仍然得靠数据库那一层来保证。
短码生成只是第一步，用户点击之后怎么跳，同样有讲究。HTTP协议里最常用的是301和302两种重定向。301表示永久迁移，搜索引擎会把权重转移给目标页，浏览器还可能记住这次跳转，下次再访问短链接时干脆不再请求服务器，直接奔目标地址去。302则是临时跳转，每次访问都得老老实实经过短链服务器。有意思的是，营销场景里大家反而偏爱302——因为每跳转一次，服务器就多一次记录点击的机会。短链接平台提供的点击量、来源、设备这类统计数据，正是靠这个环节收集的。换成301，浏览器缓存一旦生效，后续访问就绕过了统计。
链接量少的时候，随便一台机器、一张表就能跑起来；可等平台上积累了成百上千万条映射，存储和查询效率就成了真问题。常见的优化包括给短码字段建索引、用Gzip之类的压缩技术减少存储占用，以及把访问频率高的热门链接放进内存缓存——查内存远比翻磁盘快，用户点击热门短链时才会有"秒开"的体验。这些手段单拎出来都不新鲜，难的是在高并发下依然稳得住。
效率之外，安全同样绕不开。短链接有个天生的软肋：从外表根本看不出它指向哪里，点开之前完全是开盲盒。这个特性一旦被滥用，钓鱼网站和恶意软件就有了伪装的外衣。所以正经平台通常都会配套一批防护措施：生成时做内容审核，拦截已知的恶意域名；限制同一IP的生成频率，防止被人批量刷接口；上线后持续监测访问行为，发现异常流量及时掐断。作为普通用户，碰到来历不明的短链接，多留个心眼总没错。
回到开头的问题——长链接是怎么变成短链接的？答案概括起来就两件事：后台存好映射，前台负责跳转。围绕这两件事，再叠加编码优化、缓存加速、重定向策略和安全审核，一套完整的短链服务就搭起来了。这项技术如今的用武之地远比想象中广：社交媒体有字数限制，链接短一点，文案就能多写几句；短信按字数计费，省下的字符都是真金白银；二维码图案的疏密和链接长度正相关，链接越短码越稀疏，印在物料上也更容易扫出来；更不用说海报、名片这类需要手动输入的场景。理解了背后的原理，下次再看到那些短小精悍的网址，你大概就能猜到它背后整套的运转逻辑了。