最轻量的短链接ID映射方案是将全局单调递增ID转为62进制字符串，需避免暴露主键趋势或使用易重复、不可逆的time/MD5方法。
短链接生成必须解决ID映射问题
直接用自增ID转62进制（a-z, A-Z, 0-9）是最轻量的方案，但要注意：数据库主键不能暴露真实增长趋势，也不能被预测。别用 time.Now().Unix() 拼接或MD5哈希原始URL——前者并发下重复，后者无法反查且存储冗余。
推荐做法是用一个独立的 id_generator 服务或表维护全局单调递增ID（如 PostgreSQL 的 SEQUENCE 或 MySQL 的 AUTO_INCREMENT），每次发号后立刻转为62进制字符串：
func toBase62(id int64) string {
const table = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"
if id == 0 {
return "a"
}
var result []byte
for id > 0 {
result = append(result, table[id%62])
id /= 62
}
// 反转
for i, j := 0, len(result)-1; i < j; i, j = i+1, j-1 {
result[i], result[j] = result[j], result[i]
}
return string(result)
}
- 避免在HTTP handler里直接调用DB自增——高并发时易成瓶颈，可预取一批ID缓存（比如每次取1000个）
- 62进制字符串长度随ID增长而变长，10万内基本是3~4位，够用；超千万建议加盐或换Snowflake ID
- 别把原始URL当key做Redis SETNX——URL长度不定、特殊字符多，容易触发协议解析异常或截断
路由跳转必须绕过重定向循环和Referer泄漏
短链访问路径如 /abc123，需301/302跳转到原始URL。常见错误是没校验目标URL协议，导致跳转到 javascript:alert(1) 或 //evil.com，引发XSS或CSP绕过。
必须强制校验并补全协议：
立即学习“go语言免费学习笔记（深入）”；
func normalizeURL(raw string) string {
if strings.HasPrefix(raw, "http://") || strings.HasPrefix(raw, "https://") {
return raw
}
return "https://" + strings.TrimPrefix(raw, "//")
}
- 用
http.Redirect(w, r, target, http.StatusFound)（即302），不是301——便于后期灰度或AB测试变更目标 - 务必设置
w.Header().Set("Cache-Control", "no-cache, no-store, must-revalidate")，防止CDN或浏览器缓存错误跳转 - 不要在跳转前读取并透传
r.Referer()，短链本身不应成为Referer追踪入口
Go Web框架选原生net/http还是Gin？
对短链这种I/O密集、逻辑极简的服务，net/http 足够，且无额外依赖、启动快、内存开销低。Gin等框架带来的中间件、路由树优化，在QPS
一个可上线的最小服务结构：
func main() {
http.HandleFunc("/", homeHandler)
http.HandleFunc("/api/shorten", shortenHandler)
http.HandleFunc("/api/", redirectHandler) // /api/xxx → 302 to original
log.Fatal(http.ListenAndServe(":8080", nil))
}
-
redirectHandler必须用http.ServeFile或显式http.Redirect，别用http.FileServer自动路由——它会尝试找物理文件，导致404而非跳转 - 所有handler开头加
if r.Method != "GET" && r.Method != "POST" { http.Error(w, "Method Not Allowed", 405); return }，防止OPTIONS/CORS探测干扰 - 别在handler里用
log.Printf打印每条请求——改用结构化日志库（如zerolog）并采样输出，否则IO拖慢吞吐
Redis缓存短链映射时Key设计有坑
缓存层不是“加了就快”，Key设计不合理会导致击穿、雪崩或误命中。常见错误是用 "short:" + shortCode 单一前缀，没区分业务类型，也没设TTL策略。
推荐分层Key结构：
- 主映射：
"url:short:" + shortCode，TTL设为7天（业务可配置），值为原始URL（string） - 防刷计数：
"cnt:short:" + shortCode + ":" + r.RemoteAddr，TTL 1小时，限制单IP每小时最多访问10次 - 写入时先
SETNX再EXPIRE，别用SETEX——Redis 6.2+已标记为legacy，且原子性不如两步
如果Redis挂了，服务不能直接500。要在 redirectHandler 中 fallback 到DB查询，并记录告警日志，而不是 panic 或忽略错误。
短链的核心复杂点不在编码或跳转，而在ID不可预测性、跳转安全性、缓存与DB一致性这三处。随便抄个“base62 + Redis”模板上线，不出两周就会遇到爬虫爆破、跳转劫持或缓存穿透问题。
