تسجيل الدخول الآن 做推广时，经常会遇到这样的尴尬：活动页面刚配好，复制链接一看，就是一长串字母、数字和符号。放进短信容易超字数，印在海报或传单上，用户看着也费劲。于是，短链接成了很多运营场景中绕不开的工具。
不过，把上百个字符压缩成几个字母，并不只是简单“掐头去尾”。短链接真正靠的是一套映射和重定向机制：长网址被存进系统，前面只展示一个简短编号，等用户点击时，再自动跳回原来的地址。
可以把短链接想象成档案袋的编号。每个长地址都有一个对应的短码。短码怎么生成，常见有两种思路。
第一种是给网址“算指纹”。系统用 MD5、SHA-1 等哈希算法，把长链接转换成固定长度的字符串，再从中截取一小段作为短码，比如 dwz.cn/5DDXhH 里的 5DDXhH。这样做速度快，实现也简单，但容易出现一个问题：两个不同的长网址，可能刚好算出同样的短码。这时候系统就要处理冲突，比如加随机字符、重新生成，或者换一种截取方式。
第二种是给链接“排队发号”。它通常依赖数据库自增 ID 或分布式发号器，每来一条新链接，就分配一个唯一数字。为了看起来更像短链，系统还会把数字转换成 Base62，也就是用 0 到 9、A 到 Z、a 到 z 组合表示。比如内部编号 10000 被转换成 2Bi，拼在域名后面，就成了最终短链接。这种方式碰撞风险很低，但需要后端稳定维护一个发号流程，确保每条链接都能拿到自己的号。
生成短链只是第一步。用户点开它时，浏览器会把短码发给短链服务器。服务器在缓存或数据库里查到对应的原始长地址，然后通过 HTTP 重定向，把访问者交给目标页面。常见的是返回 301 或 302 状态码，告诉浏览器：“真正的地址在这里，你去找它吧。”所以我们会看到页面短暂跳转一下。
这里有个很实用的细节：如果是 302 临时重定向，后续只要服务器端修改映射，同一个短链就可以指向新的页面。对印出去的二维码、投出去的 Meta 广告来说，这意味着活动页换了，未必需要重新印物料，也不一定要重建广告计划。
短链系统还要扛住真实流量。尤其在大促、短信群发或线下扫码高峰，服务器可能要在短时间内处理大量点击。如果每次都去查数据库，速度很难保证。常见做法是用 Redis 等缓存把热门短码放在内存里，再配合分布式存储和分库分表分摊压力，把解析和跳转时间压到毫秒级，避免短链接变成“慢链接”。
当然，短链接不只是省字符。对运营来说，它更重要的价值在于能记录访问反馈。用户每次点击，服务器在跳转前都可以记录时间、设备类型、访问来源、地理位置等信息。这些数据汇总起来，能帮助运营判断短信、海报、社群或广告投放的实际效果，也能进一步分析用户从哪里来、点了之后又发生了什么。
更灵活一些，短链还能根据用户环境返回不同结果。比如同一个人扫海报上的码，如果是 iPhone，可以跳去 App 下载页；如果是安卓，可以引导去应用商店；如果已经在微信里，也可以直接打开小程序。面对一些限制较严的平台，还可以做跳转兼容，让流量更平稳地落到目标页面。
所以，短链接看起来只是少了十几个字符，背后却连着哈希算法、数据库、缓存、HTTP 重定向，以及一整套业务逻辑。它真正让运营方便的，不是“把网址变短”这件事本身，而是入口更轻便、数据可追踪、跳转可调整。