用 sync.map 是因原生 map 非并发安全，而 url 缩短器需高并发读写；sync.map 专为“读多写少”优化，读性能近原生 map，且零依赖、无需显式锁。
为什么用 sync.Map 而不是普通 map？
Go 的原生 map 不是并发安全的，一旦多个 goroutine 同时读写（哪怕只是读+读+写混合），就会触发 panic：fatal error: concurrent map read and map write。URL 缩短器天然面临高并发读写：用户发短链请求（写）、点击短链跳转（读）、后台可能还要做统计或过期清理（读写）。用 sync.Map 是最轻量、零依赖的兜底方案——它专为“读多写少”场景优化，读性能接近原生 map，且无需显式加锁。
-
sync.Map的Load/Store接口返回(value, ok)，别漏判ok，否则空值逻辑会出错 - 它不支持
len()或遍历，需要计数得额外用原子变量（atomic.Int64）维护 - 如果后续要加持久化或分布式支持，现在就别把业务逻辑和
sync.Map绑太死，抽个Storage接口更稳妥
sync.Map 存什么类型？键和值怎么设计？
键必须是能比较相等的类型，string 最直接——短码（如 "aB3x"）就是天然键；值推荐结构体指针，而不是原始字符串，方便后续扩展字段（比如创建时间、访问次数、过期时间）：
type URLRecord struct {
OriginURL string
CreatedAt time.Time
Hits int64
}
// 存储：m.Store(shortCode, &URLRecord{OriginURL: "https://..."})
// 取值：if val, ok := m.Load(shortCode); ok { rec := val.(*URLRecord) }- 值类型必须一致，不能一会儿存
*URLRecord，一会儿存string，否则Load后类型断言会 panic - 键不要用原始长 URL 做 key（太长、不可控、易冲突），短码必须由服务生成（比如 base62 编码自增 ID 或随机生成 + 冲突重试）
- 如果考虑内存占用，
OriginURL很长时，可考虑用[]byte替代string（避免字符串重复分配），但需注意sync.Map本身不关心内容，只管指针安全
如何生成可靠又不重复的短码？
别用纯随机（比如 math/rand 生成 6 位 base62），冲突概率在万级数据后就明显上升；也别用时间戳哈希（易被预测、不够短）。更务实的做法是：
-
用数据库自增 ID（即使现在没 DB，先模拟一个
atomic.Int64当 ID 生成器），再转成 base62（如"aB3x"）立即学习“go语言免费学习笔记（深入）”；
每次生成后，先
Load检查是否已存在，存在则递增 ID 重试（冲突极少，基本一次命中）短码长度控制在 4–6 位：太短（3 位）最多才 238328 种组合，不够用；太长（8 位）又失去“短”的意义
避免用
time.Now().UnixNano()做种子——在容器或高并发下，多个 goroutine 可能拿到相同纳秒时间，导致相同随机序列如果真要用随机，至少用
crypto/rand生成字节，再 base62 编码，并配合Load循环检测，但性能不如自增 ID 稳定
HTTP 处理中哪些地方最容易踩坑？
短链跳转本质是 HTTP 302 重定向，但几个细节一错就失效：
跳转目标 URL 必须校验合法性（比如用
url.Parse检查 scheme 是否为http或https），否则可能被用来跳转到javascript:或file://协议，造成 XSS 或本地文件泄露http.Redirect默认用http.StatusFound（302），如果想让浏览器不缓存跳转，得手动设 Header：w.Header().Set("Cache-Control", "no-cache, no-store, must-revalidate")短码从 URL 路径取（如
/abc123），别从 query 参数取（?code=abc123），否则无法利用 CDN 缓存、也不符合短链直觉不要在 handler 里直接
log.Fatal或 panic，会导致整个服务挂掉；用log.Printf记录错误并返回 404 或 500所有外部输入（短码、原始 URL）都要做 trim 和长度限制，防止内存耗尽或拒绝服务攻击
短码生成和跳转逻辑看着简单，但并发安全、输入校验、错误路径覆盖，这三块漏掉任何一环，上线后都会变成深夜告警。
