std::flat_multimap比std::multimap快在连续内存布局提升缓存局部性，尤其适合批量插入后只读或范围查询场景；但单元素插入为O(n)，需批量构造避免性能暴跌，内存通常高15%~25%。
std::flat_multimap比std::multimap快在哪？
它底层用std::vector存键值对，连续内存布局带来更好的缓存局部性，尤其在只读或批量插入后很少修改的场景下，迭代和查找（lower_bound/upper_bound）明显更快。但别被“快”误导——它不支持insert单个元素的O(log n)摊销复杂度，而是O(n)，因为要挪动后续所有元素。
所以真实适用场景很窄：键重复率高 + 插入基本一次性完成 + 后续主要是范围查询或遍历。比如日志按时间戳归档、传感器数据按设备ID分组、词频统计后只做区间聚合。
插入大规模重复键时怎么避免性能暴跌？
直接循环调用insert会触发多次vector重分配+元素移动，O(n²)级开销。必须改用批量构造：
- 先把所有
std::pair<const key t></const>塞进临时std::vector，并提前reserve好容量 - 用该
vector初始化std::flat_multimap，构造过程自动排序（内部调用std::sort） - 如果已有数据且需追加，别用
insert，改用std::vector拼接+重建（代价高但可控）
示例：
立即学习“C++免费学习笔记（深入）”；
std::vector<std::pair<int, std::string>> raw_data; raw_data.reserve(10'000'000); // 预估总量 // ... 填充数据，键大量重复 std::flat_multimap<int, std::string> mm(std::move(raw_data)); // 一次性构造，排序+去重逻辑由容器接管
查重复键对应的全部值，为什么不能用equal_range直接遍历？
equal_range返回的std::pair<iterator, iterator>确实能圈出所有匹配键的连续段，但注意：这个连续段在内存里真连续——不像std::multimap靠指针跳转，这里就是vector里一段连续地址。所以遍历时CPU缓存友好，但也有陷阱：
- 若键分布极不均匀（比如99%的键是同一个值），
equal_range返回的迭代器跨度极大，一次遍历可能跨越数百万元素，operator++仍是O(1)，但实际耗时取决于是否触发缓存未命中 - 不要在循环里反复调用
equal_range查同一键——结果不变，缓存住pair就行 - 若只需统计数量，用
count比equal_range快（内部优化为二分查找长度）
内存占用比std::multimap高还是低？
通常更高。原因有三：
-
std::flat_multimap无法像红黑树那样复用节点内存，每个键值对都占完整空间，没指针开销但也没共享结构 - 排序要求导致无法利用插入顺序局部性——即使你按递增键插入，容器仍会重新排序，可能打乱原有缓存友好布局
- 删除操作（
erase）不缩容，空洞残留；而std::multimap删节点就释放内存
实测：1000万条int→int键值对，flat_multimap内存占用约比multimap高15%~25%，具体取决于键重复模式和分配器行为。
真正省内存的场景反而是键类型很大（如std::string）且重复极高——此时vector的紧凑布局优势压倒指针额外开销，但得实测验证，不能默认成立。
