folly::sorted_vector_map不能无脑替代std::map，因其底层为vector+二分查找，插入/删除为O(N)，仅适合读多写少、键轻量、迭代频繁的场景；写多或键大时性能断崖下跌。
为什么 folly::sorted_vector_map 不能无脑替代 std::map
它不是“更快的 std::map”，而是为特定读多写少、键类型轻量、迭代频繁的场景设计的。一旦写操作变多，或者键值较大，性能反而会断崖下跌。
常见错误现象：insert() 或 erase() 在中等规模（比如 >1000 元素）容器里明显卡顿；用 std::string 当 key 时内存暴涨；遍历结果意外无序（误以为它自动维持插入顺序）。
-
folly::sorted_vector_map底层是std::vector+ 二分查找，每次修改都要移动内存，O(N)插入/删除 -
std::map是红黑树，O(log N)所有操作，稳定但指针跳转多、缓存不友好 - 只有当读操作占比 >90%、元素数通常 int/
size_t这类小类型时，才值得切
folly::sorted_vector_map 初始化和查找怎么写才不踩坑
构造时别直接传 initializer_list——它不会自动排序，必须显式调用 sort() 或用带排序逻辑的构造方式，否则 find() 返回 end() 即使 key 存在。
使用场景：配置项索引、状态码映射表、编译期已知范围的 ID → 名称查表。
立即学习“C++免费学习笔记（深入）”；
- 正确初始化：
folly::sorted_vector_map<int, std::string> m{{1, "a"}, {3, "c"}, {2, "b"}};<br>m.sort(); // 必须加这一句 - 查找必须用
find()或at()，不能依赖 operator[]——它会触发默认构造并插入，破坏有序性 - 迭代器失效规则和
std::vector一致：任何非 const 修改（insert/erase）都会让所有迭代器失效
什么时候该坚持用 std::map 而不是硬切 folly::sorted_vector_map
只要出现以下任一条件，就别换——强行替换会让代码更慢、更难维护。
- key 是
std::string或自定义类型，且sizeof(key) > 32字节（拷贝开销压倒二分收益） - 写操作频率超过每秒几十次（比如事件循环中频繁更新计数器）
- 需要按插入顺序遍历（
folly::sorted_vector_map按 key 排序，不是插入序） - 需要
lower_bound/upper_bound以外的区间操作，比如equal_range对非唯一 key 的支持较弱
编译和链接时最常漏掉的两件事
它不属于标准库，也不是头文件-only；漏掉任一环节都会报 undefined reference 或模板实例化失败。
- 必须链接
-lfolly，且确保 folly 版本 ≥ 2021.07.05.00（旧版sorted_vector_map缺少 move 构造，容易隐式拷贝） - 头文件是
<folly/container/SortedVectorTypes.h>，不是<folly/Map.h>或其他路径 - 如果用 CMake，得确认
find_package(folly REQUIRED)后，target_link_libraries 正确传递了 folly 的 INTERFACE_INCLUDE_DIRECTORIES
复杂点在于：它的性能优势高度依赖数据分布和访问模式，而不是“用了就快”。测之前先用 perf record -e cache-misses 看看原 std::map 瓶颈到底在分支预测、缓存未命中，还是分配器开销——否则优化就是蒙眼换轮胎。
