Login Now 你有没有好奇过，一条动辄上百个字符、塞满参数符号的网址，是怎么被压成短短几个字符的？更让人想不通的是，点开这个短链接，浏览器为什么还能准确找到原来那个页面？这背后其实没什么神秘的黑科技，思路朴素得很：给长地址起一个短代号，再让服务器记住两者的对应关系。不过真要把这套机制落地，里面的细节还是值得拆开来聊聊的。
很多人第一反应会想到哈希算法。哈希做的事，就是把任意长度的数据映射成固定长度的摘要。把长链接丢进 MD5、SHA-256 这类算法里，不管原网址有多长，出来的都是一串定长字符，理论上可以当作这条链接的"指纹"。但原始哈希值往往还是一长串字母数字混排，读起来照样费劲，所以还得再加工一层。常见的做法是 Base62 编码，用 0-9、a-z、A-Z 这 62 个字符重新表示一遍，把结果进一步压缩，最后得到的字符串又短又方便传播。
可惜这里有个绕不开的坑：哈希冲突。不同的长链接算出来，有可能撞上完全相同的结果。要是真只靠哈希生成短码，两条不同的网址就会共用同一个短链接，跳转时必然乱套。所以在实际工程里，哈希通常只是辅助手段，真正挑大梁的是数据库映射。
数据库方案的思路就直接多了。不管是第三方短链接平台，还是自己搭建的开源项目，底层都离不开 MySQL、MongoDB 这类存储。流程大致是这样的：用户提交一条长链接，系统先把它写进库里，再分配一个全局唯一的标识——最省事的做法是用自增整数 ID，也可以按特定算法生成唯一字符串。然后才轮到短码出场：把这个 ID 转成 62 进制，位数立马就降下来了。比如 ID 为 123 的记录，转换后两个字符就能表示，直接拿来做短链接的主体。有些系统还会往里掺入时间戳或随机字符串，按自己的规则拼接，免得短码被人按顺序一个个枚举出来。
到这一步，长链接和短链接的映射关系就算正式建好了——数据库里清清楚楚记着哪个短码对应哪条原始网址。这张"对照表"，正是整个短链接服务的命根子。
最后一环是重定向。用户在浏览器里输入短链接，或者扫了印在海报上的二维码，请求会先抵达短链接服务器。服务器拿着短码去库里一查，找到对应的长链接，再通过 301 永久重定向或 302 临时重定向把请求转交过去，浏览器收到指令后自动向长链接再发一次请求，用户这才看到目标页面。这两种重定向各有讲究：301 会被浏览器缓存，之后再访问可能直接绕过短链服务器；302 则每次都要经过服务器中转，虽然多绕一跳，却能完整记下每一次点击。整个过程通常在毫秒之间完成，用户几乎察觉不到中间还转了一道手。
串起来看，长短链接转换无非三件事：存进去、起个短名字、访问时照着名字把人送过去。听着简单，但正是编码、存储、重定向这三块环环相扣，才撑起了如今随处可见的短链接服务。