短链接系统必须用数据库主键id映射为短码（如base62），而非哈希截断；需预留扩展字段、区分301/307重定向、异步更新点击数以保障高并发下的正确性与性能。
短链接生成不能只靠 hash 函数
直接对原始 URL 做 md5 或 sha256 然后截取前 6 位，看似简单，但会撞车、不可控、难维护。哈希值不是 ID，它不保证唯一性，也不便于后续扩展（比如要加访问统计、过期时间）。真正上线的短链系统，必须用数据库主键或自增 ID 做源头，再把它「映射」成短字符串。
推荐做法是：插入 URL 到数据库，拿到新生成的 id（int64 最稳妥），再用进制转换（比如 base62）把它变成短码。这样既唯一，又可逆，还能控制长度。
-
base62比base36多用 26 个字母，同样长度能表达更多 ID，6 位base62能覆盖约 560 亿个链接 - 避免用
uuid或随机字符串做主键——写入性能差、索引碎片多、无法按时间排序 - 别在应用层做“重试生成直到不重复”，这是并发下的典型坑，DB 层唯一约束 + 重试逻辑才可靠
数据库设计要预留扩展字段
一开始只存 original_url 和 short_code 很诱人，但很快就会遇到问题：用户要查点击量、要设过期时间、要限制单日调用量。这些都得加字段，而线上加 ALTER TABLE 在大表上可能锁表几秒甚至几分钟。
建议第一版就包含这些字段：
-
id（主键，BIGINT或SERIAL） -
original_url（TEXT，别用VARCHAR(2048)，URL 可能带长参数） -
short_code（VARCHAR(12)，留足未来支持自定义短码） -
created_at（TIMESTAMP WITH TIME ZONE） -
expires_at（TIMESTAMP WITH TIME ZONE，允许为 NULL） -
click_count（INTEGER DEFAULT 0，用原子更新，别 SELECT+UPDATE） -
unique index on short_code（必须建唯一索引，否则并发插入会出错）
HTTP 路由和重定向要注意 301 vs 302
用 Go 的 http.Redirect 时，默认是 http.StatusFound（302），浏览器会缓存这个跳转结果——如果之后改了目标地址，用户可能还在旧地址兜圈。生产环境应区分场景：
- 普通短链跳转用
http.StatusTemporaryRedirect（307），确保每次请求都走服务端，方便统计和灰度 - 确认永久不变的链接（如品牌活动页）才用
http.StatusMovedPermanently（301），但一旦用了就不能轻易改 - 别在中间件里统一写死状态码，每个 handler 显式指定更安全
- 重定向前务必校验
short_code是否合法（长度、字符集）、是否过期，否则可能跳到空页面或报 500
高并发下计数器别用 UPDATE ... SET click_count = click_count + 1
看起来简洁，但在每秒几千次点击时，会成为数据库热点。PostgreSQL 的行级锁会让大量 UPDATE 排队，MySQL 在默认隔离级别下也可能触发间隙锁争用。
更稳的做法是：把实时点击数和最终落库分开。
- 用内存计数器（如
sync.Map或groupcache）先攒一批，比如每 10 秒或每 100 次写一次 DB - 或者用 Redis 的
INCR做轻量计数，定时同步回 PostgreSQL - 如果必须强一致，至少把
UPDATE改成带条件的：WHERE id = ? AND expires_at > NOW()，避免过期链接还被计数
短链系统的难点不在生成，而在「怎么扛住突发流量 + 怎么不让数据错乱」。很多团队卡在并发写和缓存一致性上，而不是算法本身。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
