必须预设桶数量并调用reserve(n)锁定初始负载因子，否则默认动态增长会导致压测结果波动；分阶段注入数据可复现特定命中率或观测负载因子劣化拐点；强制rehash需单独计时以避免干扰正常性能测量。
要准确评估 std::unordered_map 在高并发读写场景下的真实性能表现，必须主动控制其内部哈希桶数量与元素分布密度，否则默认的负载因子动态增长机制会让压测结果剧烈波动、无法复现。
手动预设桶数量以锁定初始负载因子
调用 reserve(n) 方法提前分配至少 n 个桶，使插入前的 bucket_count() ≥ n；该操作会清空当前所有元素并重建哈希表，【必须在插入任何键值对之前执行】。
例如：unordered_map
不调用 reserve 直接插入 512 个元素，不同编译器可能触发 3～5 次 rehash，每次 rehash 都导致迭代器失效、内存重分配和元素全量迁移，压测耗时中混入大量非目标开销。
分阶段注入数据模拟真实命中率梯度
方法一：构造固定热键集 + 随机冷键混合注入
先插入 100 个高频访问键（如 ID 1～100），再插入 900 个低频键（ID 101～1000）；后续压测时，按 80% 概率查热键、20% 查冷键，可稳定复现 80% 缓存命中率下的平均查找延迟。
方法二：分三轮递增写入并同步采样
① 插入 200 个元素 → 执行 10 万次 find() 并记录平均耗时与 bucket_count()；
② 再插入 300 个元素（总数达 500）→ 同样压测；
③ 最后插入 500 个元素（总数 1000）→ 第三次压测。
这三组数据能清晰呈现负载因子从 0.2 升至 1.0 过程中，查找耗时的非线性劣化拐点——多数实现会在因子 > 0.75 后出现明显延迟跳升。
强制触发 rehash 观察扩容代价
在已含 800 个元素的 map 上调用 m.max_load_factor(0.5); m.rehash(1600);
rehash 参数指定新桶数，不是元素数；传入 1600 表示要求 bucket_count() ≥ 1600，系统将向上取最近质数（如 1601 或 1607），然后迁移全部 800 个元素。
这一步必须单独计时，【不可与常规读写混在同一压测循环中】，否则会掩盖正常业务路径的性能特征。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
