تسجيل الدخول الآن 短链接这东西，几乎每个人每天都在打交道。电商发来的物流短信、社群里推的活动落地页、海报角落里的二维码，背后往往都是一个只有几个字符的短码。它要解决的问题其实很朴素：原始URL动辄上百个字符，塞进短信占字数，印到物料上扫不出来，发在聊天窗口里还经常被截断。把长链接压成短码，既干净体面，又方便追踪效果。
不过不少人对短链有个误解，以为它用的是某种"压缩算法"。实际上它做的根本不是压缩，而是映射。一套完整的短链系统由三部分组成：先用哈希算法（常见的是MD5或SHA-1）对长URL算出摘要，截取前6到8位，再经Base62编码变成由数字和大小写字母组成的短码；然后把短码与原始地址的对应关系写入数据库；等用户访问短码时，服务器查出原始URL，返回一个302跳转。整条链路里，查询速度就是生命线，所以经典的技术栈搭配是Redis负责高速查询、MySQL负责持久化存储，前面再架一层Nginx专门处理重定向。顺带一提，截取哈希前几位天然存在碰撞概率，工程上一般会做一次查库校验，撞了就换盐重算，属于常规操作。
如果只是想用，不想折腾，市面上的成熟服务已经很多了。Bitly算老牌选手，支持自定义域名，API文档也完善；Rebrandly的访问统计做得细致，团队协作场景用着顺手；TinyURL胜在极简，免费随开随用，但它不能设置过期时间，链接一旦生成便永久有效，重要场合得留个心眼。以Bitly为例，调一次API缩短链接大致是这样：
curl -X POST "https://api-ssl.bitly.com/v4/shorten" \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{"long_url": "https://example.com/very/long/url?param=1"}'
而如果你的业务有特殊诉求——比如必须用自己的域名、数据要握在自己手里、或者跳转逻辑需要深度定制——自建一套也不算难。核心流程一句话就能说清：用户带着短码来访问，系统查短码库，命中就重定向到原始URL，没命中就返回404。用Node.js实现，关键代码也就这么几行：
// 生成短码
function generateShortCode(url) {
const hash = crypto.createHash('md5').update(url).digest('hex');
return base62.encode(hash.slice(0, 8)); // 取前8位哈希值
}
// Redis存储
async function saveUrlMapping(shortCode, originalUrl) {
await redis.set(url:${shortCode}, originalUrl, 'EX', 3600<em>24</em>30); // 30天过期
}
注意这里给映射关系设了30天过期，这是个值得养成的习惯。短码不是越多越好，长期不清理，存储空间和查询效率都会被慢慢拖垮。
基础能力之外，还有几个进阶玩法。想让短链更有品牌感，可以绑定自定义域名：在DNS里加一条CNAME记录指向短链服务，再配一张通配符证书（Let's Encrypt就能免费申请）启用HTTPS，你的链接就能以brand.co/abc这种形式出现。想做效果追踪，建一张访问日志表是标准做法：
CREATE TABLE access_log (
short_code VARCHAR(10) PRIMARY KEY,
visit_count INT,
last_visited TIMESTAMP
);
有了这张表，每个短码被点了多少次、最近一次访问发生在什么时候，一目了然。更灵活一点的做法是动态参数传递：直接在短码后面拼接参数，比如 https://short.ly/abc?utm_source=email ，服务端收到请求后把参数透传到原始URL上。这样一来，同一条短链就能区分流量究竟来自邮件还是朋友圈，运营复盘时省心不少。
安全层面同样不能掉以轻心。生成接口如果完全敞开，很容易被滥用去批量制造垃圾链接，最基础的防护是按IP做频率限制（例如每分钟最多10次），敏感接口再加一道验证码。HTTPS强制跳转则应成为标配：
server {
listen 443 ssl;
server_name short.ly;
return 301 https://$host$request_uri;
}
性能优化的思路归纳起来就两个字：缓存。热门短码的映射关系放进Redis，缓存过期时间与数据库保持一致，避免出现脏数据；访问量再上一个台阶，就多节点部署、用Nginx反向代理分摊压力，数据库做读写分离。对绝大多数业务而言，这套组合拳已经绰绰有余。
至于什么场景配什么方案，可以对照着选：社交媒体营销要追踪各渠道效果，用带UTM参数的短链；技术文档分享嫌长链接影响打印排版，绑个自定义域名最体面；临时活动页面只跑一周，自建服务设个7天自动失效正合适；出于接口安全考虑想隐藏真实服务地址，那就动态生成一次性短链，用完即焚。
最后再补几点提醒。医疗、金融类业务的短链必须过合规这道关，HIPAA、PCI DSS之类的硬性要求一个都不能少；重要链接别全押在免费服务上，平台一旦关停，链接会集体失效，这类教训并不少见；定期清理过期短码，既是释放存储，也是在收敛安全风险。
实操建议归结起来就一条：中小企业优先用成熟服务，像Bitly企业版这种开箱即用的产品能省掉大量运维成本；等日均请求量跨过10万这个量级，自建服务的成本优势和可控性才真正显现出来，到那时候再动手也不迟。
