17370845950

最轻量的短链接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绕过。

必须强制校验并补全协议：

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”模板上线，不出两周就会遇到爬虫爆破、跳转劫持或缓存穿透问题。