短链接生成不必强制用Base62，但更合理：Base64含+和/需URL编码且易被拦截，Base62全字符URL-safe；须自定义映射表而非截取Base64；源头推荐混淆后的自增ID而非UUID；表设计应避免唯一索引重试，用SELECT FOR UPDATE+INSERT IGNORE；解析需区分raw模式与重定向，并统一用307防止缓存问题。
短链接生成必须用 Base62 而不是 Base64？
不是必须，但 Base62 是更合理的选择。Base64 里包含 + 和 /，在 URL 中需编码成 %2B、%2F，徒增长度且易出错；还可能被某些代理或 CDN 拦截。Base62 只用大小写字母加数字（0-9a-zA-Z），共 62 个字符，全部 URL-safe。
常见错误是直接调用 base64.StdEncoding.EncodeToString() 后硬删掉 + 和 /，结果字符集不连续、解码时无法对齐——Base62 必须自定义映射表，不能“截取”Base64。
实操建议：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 手写两个映射数组：
encodeTable = []byte("0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ")，decodeMap建map[byte]int加速查表 - 编码时对整数做除 62 取余，从低位往高位拼；解码则按权展开：
for _, b := range bs { n = n*62 + decodeMap[b] } - 别用浮点或字符串中间转换，整数运算更快更稳
用自增 ID 还是 UUID 做短码源头？
用自增 id（数据库主键）更合适。UUID 随机性强，无法保证短码单调增长，不利于缓存预热、分库分表路由，也难做趋势分析（比如今天生成了多少条）。
立即学习“go语言免费学习笔记（深入）”；
但直接暴露自增 ID 有风险：容易被爬虫遍历、推测总量、反查原始链接。所以必须做混淆——不是加密，而是「不可逆的数值映射」。
实操建议：
- 用固定异或掩码（如
id ^ 0x5DE4E6A2）或简单 Feistel 网络（2~3 轮，每轮用id & 0xFF查表扰动）打乱顺序 - 避免用
crypto/rand为每个 ID 生成随机 salt，性能扛不住；也别用哈希（如md5(id)），碰撞概率虽低，但短码必须唯一，哈希后还要去重重试，逻辑变重 - 如果服务初期量小，可先用
id直接 Base62 编码，加一层 Nginx 或中间件限速防遍历，后续再平滑切到混淆方案
MySQL 表结构怎么设计才扛住高并发写入？
核心矛盾在于：短码要全局唯一、查询要快、写入不能锁表太久。别一上来就加唯一索引 short_code 然后靠数据库报错重试——高并发下大量 Duplicate entry 错误会拖垮应用和 DB。
真实瓶颈不在存储，而在「分配+写入」的原子性。自增 ID 本身是串行的，但只要确保「ID 分配」与「记录插入」不跨事务，就能避开冲突。
实操建议：
-
short_code设为VARCHAR(8)主键（8 位 Base62 最多支持 62⁸ ≈ 218 万亿种组合），original_url建TEXT+INDEX（用于防重复提交） - 插入前先用
SELECT ... FOR UPDATE查original_url是否已存在，有则直接返回旧short_code；没有则INSERT IGNORE新记录——利用唯一索引快速失败，比应用层重试更轻量 - 别把
created_at当索引前缀字段，写入热点集中在最新分区；如果用时间分表，注意short_code本身已足够做 sharding key
短码解析时为什么总遇到 302 循环或跳转丢失？
根本原因是没区分「前端跳转」和「API 查询」场景，所有请求都走重定向，但搜索引擎爬虫、微信内嵌浏览器、curl 测试常带 User-Agent 或 Accept 头，服务端却统一返回 302，导致跳转链路被截断或降级失败。
另一个隐形坑是：短码解析后直接 http.Redirect()，没设 http.StatusMovedPermanently (301) 或 http.StatusTemporaryRedirect (307)，浏览器缓存了错误跳转，改配置后用户本地仍跳旧地址。
实操建议：
- 加一个
?raw=1参数开关：带该参数返回纯 JSON（{"url": "..."}），否则才 302；这样前端埋点、灰度验证、监控都能用同一接口 - 重定向务必显式指定状态码：
http.Redirect(w, r, target, http.StatusTemporaryRedirect)，避免依赖 net/http 默认的 302（它会清空 POST body，而 307 不会） - 别在重定向响应头里塞太多自定义 header（如
X-Trace-ID），部分客户端会丢弃；真要透传，改用 URL query 参数拼接
最麻烦的其实是缓存——CDN 或浏览器对 301 缓存极深，上线后改跳转逻辑，老用户半天看不到新行为。上线前务必确认所有短码跳转路径只用 307，留出调试窗口。
