一张 std::unordered_map 如果放在请求路由、缓存索引、对象表这类热路径上，性能问题往往不会很体面。它不是慢得一眼可见，而是每次请求多走几次内存跳转，最后堆成尾延迟。
Tessil 维护的 hopscotch-map，就是冲着这个问题来的。它是一个 C++17 header-only 库，基于 hopscotch hashing 和开放寻址，提供 map 和 set 的替代实现。文档里的表述是 most cases 下更快、更省内存。这个限定很重要：它不是 std::unordered_map 的无脑替换件。
我更在意的是，换它之前要回答三个问题：你的哈希质量够不够好？代码能不能接受更激进的失效规则？你要的是普通性能优化，还是要防 hash DoS？
它解决的不是语法问题，是热路径里的内存问题
std::unordered_map 的优点很硬：标准、稳定、可移植，团队新人也容易读懂。代价是实现通常偏节点化，元素分散，缓存局部性不一定好。
hopscotch-map 走开放寻址路线。元素更集中，冲突通过 hopscotch hashing 处理，目标是减少内存跳转。这正是很多服务端代码里哈希表慢的来源。
接入成本不高。它是 header-only，把 include 目录加进 include path 就能用；用 CMake 时，也可以通过导出的 tsl::hopscotch_map target 接入。前提是项目能使用 C++17。
核心类主要有三组：
| 类别 | 核心类 | 主要用途 |
|---|---|---|
| 普通版本 | tsl::hopscotch_map/set | 常规性能敏感场景，默认优先试 |
| prime 版本 | tsl::hopscotch_pg_map/set | 哈希低位质量可疑时使用 |
| bounded 版本 | tsl::bhopscotch_map/set | 有 hash DoS 风险时考虑 |
和早年的 dense_hash_map 这类性能容器相比，它更贴近现代 C++ 项目。它不要求给 key 预留哨兵值，还支持异构查找、预计算 hash、可选存储 hash，也支持 move-only 和非默认构造类型。
对服务端和基础设施开发者来说，这意味着一件事：它可以进入候选名单，但不该直接全仓替换。更现实的做法，是先找 profile 里占比高的几张表。
怎么选版本：先看 hash，再谈快
hopscotch-map 默认版本使用 power-of-two 增长策略。桶映射可以用位运算完成，速度更友好。
但它有一个现实限制：如果哈希值低位质量差，碰撞会被放大。指针地址、递增 ID、简单整数 key，或者一些封装得很薄的业务 key，都可能有这种风险。
这时继续调 load factor 未必是正解。换成 prime 版本，往往更值得先验证。
| 版本 | 增长策略/特征 | 适合谁用 | 我的判断 |
|---|---|---|---|
tsl::hopscotch_map/set | 默认 power-of-two，避免较慢取模 | 哈希函数质量较好、追求吞吐的热路径 | 默认试它，但要测碰撞 |
tsl::hopscotch_pg_map/set | prime 增长，对低位重复更稳 | key 低位模式明显，或 hash 质量不确定的模块 | 用一点速度换分布稳定 |
tsl::bhopscotch_map/set | key 需要 LessThanComparable，查找/删除最坏 O(log n) | 外部输入可控性弱、有 hash DoS 风险的入口 | 不是默认推荐，只在风险明确时用 |
这里不能把 bhopscotch 当成高级版。文档里的意思更接近：没有 DoS 风险时，普通 hopscotch 通常更合适。
所以选型顺序应该很朴素。内部热路径，先试普通版本；低位 hash 可疑，试 pg；入口数据可能被构造攻击，再评估 bhopscotch。舍本逐末，容易把容器优化做成风险引入。
真正的迁移成本在语义，不在 include
替换 std::unordered_map 最容易低估的，是接口语义差异。
hopscotch-map 的 API 接近标准容器，但它不是节点式容器。插入、rehash 这类修改操作，可能比 std::unordered_map 更广泛地使迭代器、引用和指针失效。
这会直接影响两类代码。
一类是保存 value 指针的老代码。比如把 map 里的对象地址交给别的结构缓存，之后又继续插入元素。换成开放寻址容器后，这种写法要重点排查。
另一类是在遍历中修改容器的代码。原来依赖某些迭代器或引用仍然有效，现在要重新确认规则。这里不要凭标准容器经验猜。
还有一个小坑：迭代器解引用返回的是 const std::pair<Key, T>，不能直接改 second。要修改 mapped value，需要走迭代器的 value()。
异常约束也要看。move-only 类型可用，但需要 nothrow move constructor。原因很直接：开放寻址在搬移元素、rehash 时，很难像节点容器那样维持同样的强异常保证。关闭异常编译也能用，只是抛出路径会变成 std::terminate。
对性能敏感项目维护者，我会建议按这个顺序落地：
| 动作 | 要看什么 | 不通过时怎么办 |
|---|---|---|
| 用 profile 找热表 | 哈希表是否真的在 CPU 或尾延迟里占比高 | 不在热路径就别换 |
| 做小范围 A/B benchmark | 吞吐、延迟、内存、rehash 次数 | 没收益就保留标准容器 |
| 检查 key 和 hash | 低位分布、碰撞、是否有外部可控输入 | 试 pg 或 bhopscotch |
| 审失效依赖 | 是否保存指针、引用、迭代器 | 改生命周期或放弃替换 |
| 跑回归和压力测试 | 插入、删除、rehash、异常路径 | 先修语义问题，再谈性能 |
这套动作对 C++ 服务端、存储引擎、网络代理、基础设施组件最有用。它们最常见的情况不是缺一个更快容器，而是缺一个可控的替换边界。
如果一个模块 key 分布清楚、生命周期简单、很少保存内部引用，hopscotch-map 值得试。反过来，如果代码大量依赖节点稳定性，或者 hash 函数本来就粗糙，先换容器不一定是优化，可能只是把旧问题换个地方爆出来。
回到开头那张热路径里的哈希表。hopscotch-map 的价值，不是让人把 std::unordered_map 从项目里清出去，而是给性能瓶颈一个更细的选择：快可以要，但要把失效规则和 hash 风险一起买单。