17370845950

短链接服务需确保短码唯一性、存储高效、路由轻量及基础防护。采用哈希截取+重试生成短码，DB主键索引+Redis缓存加速查询，通配路由302跳转，校验URL合法性、限频与权限管控。

短链接服务的核心是把长 URL 映射成短字符串（如 abc123），再通过该字符串快速查回原始 URL。Golang 实现的关键在于：唯一性生成、高效存储、无状态路由和防滥用控制。下面分四块讲清楚核心逻辑。

短码生成：避免冲突且可扩展

不能用自增 ID 直接转进制（易暴露总量和顺序），推荐用「随机 + 冲突重试」或「雪花 ID 变体」。更稳妥的是基于时间戳+随机数哈希后截取：

• 对原始 URL 做 SHA256，取前 6 字节转 base64（去掉 +// 和 =，用 a-zA-Z0-9 共 62 进制）
• 若 DB 中已存在该短码，加一个随机后缀再哈希，重试最多 3 次
• 不建议纯随机（6 位 62 进制约 568 亿组合，初期够用但需预留扩容，比如升到 7 位）

存储设计：快查快写，兼顾一致性

核心表只需两张：url_mapping（short_code 主键，original_url，created_at，visit_count）和可选的 url_stats（按天记录访问来源/IP/UA）。关键点：

• MySQL 或 PostgreSQL 都行，short_code 建唯一索引，查询走主键，毫秒级
• 高并发场景下，可用 Redis 缓存热 key（如 cache:abc123 → original_url），过期时间设 24h，DB 作为兜底
• 写操作先写 DB 再删缓存（或用延迟双删），避免脏读

HTTP 路由：302 重定向要轻量

短链访问路径通常是 /abc123，Gin 或 net/http 都能高效处理：

• 注册通配路由 GET /:code，提取 code 后立即查缓存 → 查 DB → 记录访问 → 返回 302
• 302 响应头必须设 Location: ，不要用 301（会缓存，改链困难）
• 加一层中间件校验短码格式（如只含 62 进制字符、长度 6–8）、拦截空 UA 或高频恶意请求

基础防护：防止刷号和跳转风险

上线前至少堵住三类问题：

• URL 白名单检查：拒绝 javascript:、data:、内网地址（如 127.0.0.1、192.168.x.x）等非法协议和地址
• 频率限制：单 IP 每分钟最多创建 5 条，用 Redis 的 INCR + EXPIRE 实现滑动窗口
• 短码不可逆：不提供「反查所有短链」接口，管理后台需登录鉴权，导出限流

基本上就这些。不复杂但容易忽略细节——比如没做短码格式校验导致 SQL 注入（如果拼接查询）、没设缓存过期导致旧链接无法更新、301 误用让运营改链失败。把这四块理清，一个稳定可用的短链服务骨架就立住了。