短链接需用ID→短码双向映射，推荐62进制固定字符集转换；并发下依赖DB唯一索引防重，禁用全局锁；解析时须过滤非法字符、统一大小写；重定向必须用307+no-store防止缓存。
短链接核心逻辑必须绕过数据库主键自增
直接用 id 作为短码（如 https://x.co/123）看似简单，但暴露了业务量、增长节奏，且无法控制短码长度和可读性。真实项目中必须用「ID → 短码」的双向映射，常见做法是将自增 id 转为 62 进制（0–9a–zA–Z），但要注意：Go 标准库没有内置 62 进制转换，需手写或引入轻量工具函数。
关键点：
- 避免用
fmt.Sprintf("%x", id)（16 进制）——太短易碰撞，且不支持字母+数字混合编码 - 不要在每次生成时随机打乱字符表——会导致同一
id生成不同短码，破坏幂等性 - 推荐固定字符集
"0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"，按顺序映射 - 注意整数溢出：若用
int存 ID，32 位系统下最大仅约 21 亿，建议统一用int64
并发生成短码时必须加锁或用原子操作
短链接服务常被批量调用（如后台导出、爬虫预生成），若多个 goroutine 同时插入新 URL 并获取新 id，可能因竞态导致重复短码或跳号。MySQL 的 INSERT ... ON DUPLICATE KEY UPDATE 可防重复插入，但无法解决「先查后插」的经典竞态。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对「URL → 短码」的查询和插入，用数据库唯一索引（
url字段加UNIQUE）强制约束，失败则重试查 - 若用 Redis 缓存短码映射，生成阶段可用
INCR命令原子递增全局 ID，再转为短码，避免 DB 查询开销 - 不推荐在 Go 层用
sync.Mutex全局锁——会成为性能瓶颈；可用分段锁（如按 URL 哈希取模）或直接依赖 DB 唯一约束
短码解析必须做大小写归一和非法字符过滤
用户可能手动输入 https://x.co/AbC123 或复制带空格的链接，后端若不做清洗，会导致 404。更隐蔽的问题是：某些手机浏览器会把短码末尾的 l（小写 L）自动转成 1（数字一），或混淆 O 和 0。
安全处理步骤：
- HTTP 路由捕获到短码后，先用
strings.TrimSpace()去首尾空格 - 统一转为小写（或大写）：
strings.ToLower(code)，因为 62 进制字符集中大小写是不同字符 - 用正则快速过滤非法字符：
^[a-zA-Z0-9]{4,8}$，长度建议 4–8 位，太短易撞，太长影响传播 - 若匹配失败，直接返回
http.StatusNotFound，不要尝试纠错——防止被用于探测或 fuzzing
重定向响应头必须显式设置 Location 且禁用缓存
短链接本质是 30X 跳转，但很多实现漏掉关键细节：浏览器或 CDN 可能缓存 301 响应，导致目标 URL 更新后用户仍跳转到旧地址。
func redirectHandler(w http.ResponseWriter, r *http.Request) {
code := strings.TrimPrefix(r.URL.Path, "/")
target, err := getTargetByCode(code) // 查库或 Redis
if err != nil {
http.Error(w, "Not found", http.StatusNotFound)
return
}
w.Header().Set("Location", target)
w.Header().Set("Cache-Control", "no-store, no-cache, must-revalidate, max-age=0")
w.WriteHeader(http.StatusTemporaryRedirect) // 用 307 而非 301
}
重点说明：
- 必须用
http.StatusTemporaryRedirect（307）而非http.StatusMovedPermanently（301）——保证后续修改目标 URL 时，客户端不会固化跳转 -
Cache-Control头不能只写no-cache，要明确no-store防止中间代理缓存重定向响应体 - 不要依赖
http.Redirect默认行为，它默认发 302，且可能加Vary等冗余头
短链接最难的不是编码算法，而是高并发下的 ID 分配一致性、跳转链路的可观测性（比如要不要记录 referer、UA、地域）、以及如何灰度替换旧短码而不中断流量——这些往往在压测或上线后才暴露。
