अभी लॉगिन करें 在微博上发一条带链接的动态，点下发送那一刻，原本冗长的地址就换了个模样，成了"d4t.cn/A6x9Kp2"这样的短码。这串字符看起来像随手敲出来的，实际上每个字母、每个数字都来路清楚——它们是数据库自增ID经过Base62编码转换后的结果。毕竟在字数寸土寸金的地方，一条两三百字符的长链接实在太占地方了。
很多人的第一反应是：短链接是不是把长URL"压缩"了？这是个挺普遍的误解。任何压缩算法都没法把一两百个字符稳定地塞进六七位短码里，还能原样还原。真实的做法要朴素得多：建一张映射表。数据库负责存长URL和对应的ID，Base62负责把ID翻译成短小好读的编码；有人点开短链接时，系统拿着短码反查出ID，再顺着找到长URL完成跳转。整个过程里，长URL本身一个字节都没动过。
那为什么偏偏选中62个字符？数一下就明白了：0-9、A-Z、a-z，加起来正好62个，而且每一个都能直接放进URL路径，不会触发浏览器的转义机制。相比之下，Base64字符集里的"+"和"/"在URL中都有特殊含义，硬塞进路径只会添乱。Base62的本质其实就是62进制转换，编码过程就是反复对62取模。拿数字123456举例：123456÷62得1991余14，对应字符'E'；1991÷62得32余7，对应'7'；32÷62得0余32，对应'W'；倒着一拼，"W7E"就是最终短码。解码则是逆运算，按位权值累加即可。这么算下来，一个已经存了100万条记录的服务，下一个ID 1000001编码出来不过是"4C93"——4个字符就装下一个七位数，6个字符更能覆盖五百多亿个ID，对绝大多数业务来说都绰绰有余。
落到代码上，第一步是定义字符映射表，常见写法是把"0-9、A-Z、a-z"依次排开。编码函数的核心是一个循环：取模拿到当前位的字符，整除之后进入下一轮。这里有两个细节容易踩坑：取模是从低位往高位走的，所以最后得把字符串反转；数字0这种特殊情况也要单独处理，否则会返回空串。解码函数则反过来遍历短码，逐个累加字符的位权值，之所以用reversed，是因为字符串从左往右读是高位到低位。生产环境还有个惯用技巧：编码前先给ID做一次异或运算，混入一个盐值。这样一来，外人拿到短码也反推不出真实ID，业务量自然不会暴露。
数据库设计同样不算复杂。核心表只需要自增ID、长URL、短码三个字段，短码字段加上唯一索引。实际项目里通常还会多存一份长URL的哈希值，方便快速判断这条链接之前有没有生成过短码——同一个地址重复提交，直接返回旧记录就行，不必白白消耗ID。完整的生成流程是：用户提交长URL，系统先查哈希，不存在就插入记录拿到自增ID，用Base62编码后回填短码字段。访问链路更简单：根据短码查到长URL，返回302重定向，顺手写一条访问日志，点击量、来源渠道这些统计数据就都有了着落。
有一点必须强调：Base62是编码，不是加密。它只是换了一种表示方式，任何人拿到短码都能把ID算出来。短链接的安全靠的是ID本身的不可预测性加上访问控制——分布式部署时改用雪花算法或UUID生成ID，能显著降低被遍历枚举的风险；涉及敏感内容的链接，还可以加访问密码、有效期和访问次数上限。性能方面，高并发场景一般会把短码到长URL的映射丢进Redis，热门链接的缓存命中率能做到90%以上，数据库的压力会小很多。
想动手练的人，学习路径很清楚：先把Base62的编码解码函数写出来，吃透进制转换，再搭一个最小可用的短链接服务，把生成、跳转、统计各跑通一遍，核心机制就全掌握了。运营和产品同学不必纠结实现细节，把精力放在数据统计上更划算——链接从哪里被点开、沿什么路径传播、带来了多少转化，这些才是短链接对业务真正的价值。至于中小企业主，自己造轮子往往得不偿失，直接用快缩短网址这类成熟服务省心得多：高并发、防刷、数据统计这些麻烦事人家已经处理好了，还支持批量生成和API接入，应付常见的营销推广场景绰绰有余。