sync.Map 不能用于请求合并，因其仅支持线程安全的键值存取，缺乏等待聚合、超时控制和批量触发机制；真正需要的是按 key 分组+等待超时+批量触发三件套。
为什么 sync.Map 不能直接用在请求合并里
因为请求合并不是缓存读写，而是「等待+聚合」：多个并发请求进来，得先拦住、攒一批，再统一发出去。而 sync.Map 只负责线程安全地存取键值，不提供等待机制，也没法让 goroutine 暂停并集体唤醒。
常见错误现象是：用 sync.Map 存 pending 请求，但没配对的 sync.WaitGroup 或 chan 协调，结果部分请求永远等不到响应，或漏掉某些请求。
- 真正需要的是「按 key 分组 + 等待超时 + 批量触发」三件套
- key 通常是查询参数（比如
user_id列表），不是单个 ID - 超时时间必须严格控制，一般设为
5ms–20ms；太短合并率低，太长用户感知延迟
golang.org/x/sync/singleflight 能不能直接拿来 batch
不能。它只解决「相同 key 的重复请求去重」，不是 batch：singleflight.Do 对每个 key 最多跑一次函数，但如果你传入 100 个不同 user_id，它会发起 100 次独立调用，不会自动聚合成 IN (..., ..., ...) 查询。
使用场景错位很典型——有人以为加了 singleflight 就算做了 batch，结果 DB QPS 没降，只是避免了完全相同的请求重复执行。
立即学习“go语言免费学习笔记（深入）”；
- 它内部用
map[interface{}]*call+sync.Mutex，无批量维度 - 返回值是单个结果，不是切片；无法反向映射回原始多个请求的响应
- 若强行把整个请求体当 key（比如 JSON 字符串），会导致 key 冲突率极低，几乎不起作用
手动实现 batch 的最小可靠结构：用 map[string]chan []Result + 定时器
核心思路是：所有同类型请求（比如查用户）先进同一个队列，由一个 goroutine 统一收拢、截断、查库、分发。关键不在“怎么存”，而在“怎么截流”和“怎么分发”。
示例中，batcher 是一个结构体，持有：mu sync.RWMutex、pending map[string][]*pendingReq（key 是 SQL 模板哈希）、flushTimer *time.Timer。
- 每次请求来，先算 key（推荐用
fmt.Sprintf("select_user_by_id_in_%d", len(ids))这类稳定字符串，别用原始参数拼接） - 把请求的
id和响应chan <- []User塞进pending[key] - 如果 timer 未启动，就
time.AfterFunc(10*time.Millisecond, b.flush)；已启动则忽略 -
flush()中清空pending[key]，构造批量 SQL，查库，再遍历原请求列表，挨个塞结果到各自chan
注意：不要在 flush 里做阻塞操作（如慢 SQL），否则整个 batch 队列卡死；建议用 context 控制 DB 查询超时。
DB 层批量查询的坑：MySQL IN 参数数限制和 PostgreSQL unnest 性能差异
MySQL 默认 max_allowed_packet 和 IN 参数上限（实际受 sort_buffer_size 影响）会让大 batch 直接报错 ERROR 1390 (HY000): Prepared statement contains too many placeholders；PostgreSQL 虽无硬限制，但 WHERE id = ANY($1) 在数据量大时不如 JOIN unnest($1::int[]) AS v(id) 快。
- MySQL 安全批量上限建议 ≤ 500 个 ID；超过需分片，比如每 400 个一组并发查
- PostgreSQL 用
unnest时，确保$1是int[]类型，不是字符串数组，否则索引失效 - 无论哪种 DB，批量查询后必须严格按原始请求顺序返回结果；别图省事用 map 回填，会乱序
最易被忽略的是：batch 合并后，错误处理粒度变粗了——一次 DB 错误会影响所有 pending 请求。得在 flush 里拆解错误（比如部分 ID 不存在），再分别通知对应请求方，而不是一股脑返回 error。
