std::flat_multiset查找快在o(log n)下常数更小，因连续内存使cpu预取高效、缓存命中率高；插入/删除为o(n)因需移动vector元素，且迭代器在扩容时全部失效。
std::flat_multiset 不是 std::multiset 的“平替”，它是用连续内存换查找速度、用插入代价换缓存友好性的明确取舍——选错场景时，性能可能比 std::multiset 还差。
std::flat_multiset 查找快，但快在哪儿？
它和 std::multiset 一样走 lower_bound() 和 upper_bound()，时间复杂度同为 O(log n)，但常数小得多。关键差异在内存布局：
- CPU 预取有效：访问中间元素时，相邻键值大概率已在同一缓存行（64 字节）中，后续比较无需新访存
- 遍历时无指针跳转：
for (auto& x : fm)是纯地址递增，而std::multiset每次++it都要解引用新节点指针 - 实测 1024 元素规模下，顺序遍历吞吐量可达
std::multiset的 2.3 倍以上
insert() 和 erase() 为什么是 O(n)？
因为底层是 std::vector，不是红黑树节点链表。每次修改都要维持有序性：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
insert()：先二分定位插入点，再把该位置后所有元素整体右移；若触发扩容，还要重新分配 + 全量复制 -
erase(iterator)：删除后必须左移后续全部元素；不支持erase(const key_type&)（被禁用），避免歧义 - 没有“局部旋转”或“指针重连”：移动开销直接取决于元素数量和拷贝/移动成本
迭代器失效规则比 multiset 更简单，也更危险
它没有模糊地带：
- 只要没 realloc，所有迭代器都有效（比
std::multiset更可预测） - 一旦扩容，全部迭代器立即失效（包括
begin()、end()、你刚保存的任意iterator） - 循环中边遍历边
erase()是未定义行为：for (auto it = fm.begin(); it != fm.end(); ++it) { if (...) fm.erase(it); }❌ - 安全写法只有两种：
fm.erase(key)批量删，或先收集待删位置再逆序 erase
现在能直接用 std::flat_multiset 吗？
不能默认用，得先验证标准库是否真正支持：
- 头文件
<flat_multiset></flat_multiset>很可能不存在：GCC 13、Clang 17、MSVC 17.8 及更早版本均未导出该头 - 即使包含成功，
__cpp_lib_flat_multiset宏可能未定义，或值，说明 ABI 未就绪 - 链接时报
undefined reference to 'std::flat_multiset<int>::insert()'</int>是常见失败信号 - 生产环境最稳方案仍是
boost::container::flat_multiset，头文件<boost></boost>，接口兼容、ABI 稳定、已实战十年
真正容易被忽略的点是：它的优势只在“读远多于写 + 数据量适中 + 内存敏感”三者同时成立时才兑现；其余情况，它只是把问题从 CPU 缓存换成了 vector 移动延迟。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
