17370845950

短链接的核心逻辑是通过自增ID与Base62编码构建可逆映射，将长URL转为短码并存入数据库或Redis，用户访问时查表302重定向，同时校验URL、防刷、返回404。

短链接的核心逻辑是什么

短链接本质是把一长串原始 URL 映射成一个极短的字符串（比如 abc123），用户访问这个短码时，服务端查表重定向到原地址。关键不在“缩短”，而在“可逆映射 + 高效跳转”。不需要压缩算法，也不需要实时计算——用数据库或缓存存一对映射就够了。

用 Base62 编码生成易读短码

避免用纯数字（太长）、避开 0/O/l/I 等易混淆字符，Base62（0–9 + a–z + A–Z）是常用选择。核心思路：给每条新链接分配一个自增 ID（如 MySQL 的 AUTO_INCREMENT），再把这个 ID 转成 Base62 字符串。

• 例如 ID=12345 → 编码后可能是 "3d7"，作为短链接后缀
• 解码时反向操作：收到 /3d7 就解出 12345，查数据库拿到原 URL
• Java 可手写简单编码器，也可用开源库如 com.google.guava:guava 配合自定义字符集

存储与跳转流程要轻量可靠

推荐用 MySQL 存核心映射表（short_code、original_url、create_time、visit_count），加唯一索引在 short_code 上。首次生成时检查是否已存在，避免重复；高并发下可用 REPLACE INTO 或先 SELECT 再 INSERT ON DUPLICATE KEY UPDATE。

• 用户请求 GET /s/abc123 → Controller 根据 abc123 查库 → 找到原 URL → 返回 302 重定向
• 顺便更新 visit_count，方便后续统计
• 不想依赖 DB？可用 Redis 存 short_code → original_url，设置过期时间支持临时链接

加一层基础防护和体验优化

上线前至少做三件事：校验原始 URL 格式（防止 http://evil.com/xxx）、限制单日生成数量（防刷）、返回 404 而不是 500（查不到短码时）。

• 前端提交时用 JS 粗略校验 URL 格式，后端用 java.net.URL 再解析一次
• 短链接页面可加个简单跳转提示页（带倒计时和手动跳转按钮），提升体验也利于埋点
• 考虑加个「自定义短码」选项：用户填 abcd，系统检查是否被占用，可用则直接绑定

基本上就这些。不复杂但容易忽略细节——重点是映射可靠、跳转快、不出错。