手写哈希表：C++实现开放地址法全解析

哈希表大概是我面试里被问过最多次的数据结构，没有之一。它表面上的卖点特别简单：把 key 通过哈希函数映射到数组下标，插入、查找、删除理论上都是 O(1)。可一旦你真拿着编辑器准备手写一个，三个问题马上就会冒出来：冲突了怎么处理？删掉的槽位能不能直接置空？表满了要不要扩容？这些问题背后全是细节，任何一个处理不好，看似完整的哈希表就会在某些数据下出现“查不到”“死循环”甚至数据错乱。

这篇博文想聊的，就是用 C++ 从零模拟实现一个“能真正跑起来”的哈希表。我会先把几个关键设计决策讲清楚，再给一份完整的开放地址法实现代码，最后把实操中容易踩的坑和排查方法整理出来。适合正在学数据结构、准备面试手撕题、或者天天用 unordered_map 却想搞懂底层原理的同学。

读的时候建议你把代码自己敲一遍，尤其是 insert 和 find 这两个函数，敲完之后很多模糊的地方会立刻清晰。

1. 模拟实现前，先把哈希表的设计账算清楚

1.1 哈希表到底解决什么问题

哈希表解决的核心问题只有一个：用近乎 O(1) 的时间，完成 key 到 value 的映射。数组用下标定位是 O(1)，但下标只能是整数且必须连续；二叉搜索树能够解决 key 的灵活性问题，但查找复杂度是 O(log n)。哈希表等于把这两者的优点揉在一起：通过哈希函数，把任意类型的 key 转换成一个数组下标。

这里有个很容易被忽略的点：哈希表的“O(1)”是平均复杂度，不是最坏复杂度。如果所有 key 都哈希到同一个槽位，哈希表会退化成 O(n)。所以“模拟实现”的真正难点，不是写一个能用的类，而是把哈希函数、冲突处理、扩容时机这几个零件搭配好，让最坏情况尽量少出现。

我见过不少初学者第一次手写哈希表时，写完 insert 和 find 就觉得完事了。实际上，一个工程上可用的哈希表，必须把删除、扩容、负载因子一起考虑进去。这也是为什么面试官喜欢问手写哈希表，因为这个问题看似基础，但每一层追问都能筛掉一批人。

1.2 开放地址法和链地址法：我为什么选前者

哈希表处理冲突有两大流派：开放地址法和链地址法。链地址法就是数组加链表，冲突的 key 挂到同一个链表上；开放地址法则是所有元素都住在数组里，冲突了就在数组里继续找下一个空槽。

我这次选择开放地址法，不是因为它是更优的方案，而是因为它在“模拟实现”这个场景下更有教学价值。

链地址法在工程上更常见，但它需要额外管理链表节点，写起来代码量大，还容易把关注点带到链表操作上，冲淡了“哈希”本身的核心思想。开放地址法用一个数组就能把冲突处理、删除标记、扩容问题全部暴露出来，代码量也更紧凑，非常适合用来理解哈希表的内核。

另外还有一个现实原因：面试手撕哈希表时，开放地址法的代码量更适合在有限时间内写完。很多考察哈希表的面试题，也会用开放地址法作为标准答案之一。

1.3 功能边界：这次实现到什么程度

在动笔之前，先把功能边界画清楚，能防止代码越写越失控。这次实现的目标是：

• 支持泛型 key/value，用 C++ 模板实现；
• 提供 insert、find、erase 三个核心操作；
• 自动扩容，维护合理负载因子；
• 使用开放地址法中的线性探测作为冲突处理策略；
• 支持自定义类型的 key，通过 std::hash 特化实现。

我明确不做的东西包括：迭代器、线程安全、自动缩容。迭代器会让代码复杂度翻倍，因为需要维护状态来遍历所有非空槽位；线程安全需要加锁策略，跟哈希表本身的设计是另一回事。把这些边界写清楚，不是偷懒，而是让读者先把核心机制吃透，后续要扩展也更容易。

2. 四个绕不开的设计关卡：哈希函数、冲突、扩容、删除

2.1 哈希函数：映射不是简单的取模

哈希函数的目标很直白：把任意 key 均匀地映射到一个固定范围的整数。最常见的做法是先用 std::hash 拿到一个天然的哈希值，再对容量 capacity 取模，把范围压到数组下标。

但“取模”这步有讲究。如果 capacity 是偶数，那么所有偶数 key 都会映射到偶数槽位，奇数 key 映射到奇数槽位，均匀性完全取决于 key 本身的分布。这就是为什么开放地址法里，许多实现会把容量选成质数，或者使用“与容量减一按位与”的优化技巧，但前提是容量必须是 2 的幂。两种选择各有取舍：

• 容量为质数：取模分布更均匀，但取模运算比位运算慢；
• 容量为 2 的幂：位运算快，但要依赖哈希函数本身足够随机，才能避免低位重的高冲突。

我这次的实现选择质数容量，配合 nextPrime 函数在扩容时寻找下一个质数。因为开放地址法的核心瓶颈是冲突，而质数容量能在不增加哈希函数复杂度的前提下，明显减少聚簇现象。

这里补充一个反直觉的细节：std::hash 对整数类型很多时候就是返回原值。也就是说 hash(1) 是 1，hash(17) 是 17。如果容量是 16，那么 1 和 17 会直接落在同一个槽位，立刻冲突。但如果容量是 17，1 落 1 号位，17 落 0 号位，完美错开。这就是质数容量的价值。

2.2 冲突处理：线性探测、二次探测、双重散列

无论哈希函数设计得多好，冲突都不可避免。这背后有经典的生日悖论：如果哈希表有 365 个槽位，随机放 23 个 key，就有超过 50% 的概率至少发生一次冲突。所以冲突处理策略才是哈希表真正见功夫的地方。

三种主流探测方式对比：

线性探测的原理很好理解：从哈希得到的槽位开始，如果被占了，就往下看下一个槽位，直到找到空位。它最直观，代码也最短，所以我这次就用它。但线性探测有一个肉眼可见的问题：一旦某个区域连续满了，后面的 key 会倾向于扎堆排列在连续区尾部，让这个“拥挤区”越滚越大。

生活里有个类似的场景：商场停车场如果大家都从入口往里开，找到一个空位就停，往往会在某个区域形成连续满位，后来的车只能开到更远的地方。这就是聚集现象。

二次探测通过增加平方步长能缓解聚集，但它的问题在于探测序列起点相同的话，后续步长也完全相同。双重散列最均匀，但实现时要保证第二个哈希函数与容量互质，否则探测序列可能提前循环。我建议学习时先吃透线性探测，再把另外两种作为扩展去理解。它们本质都是“如何走出一条不重复、尽量分散的探测路径”。

2.3 负载因子与扩容时机

负载因子就是当前元素个数除以容量：alpha = n / capacity。它直接决定哈希表的拥挤程度。alpha 太小浪费内存，alpha 太大冲突频发。对开放地址法来说，经验上限通常在 0.5 到 0.7 之间，我这次取 0.7。

为什么开放地址法不能像链地址法那样允许负载因子接近 1？因为开放地址法里所有元素共享同一块数组空间，一旦数组接近满，线性探测的探测链会变得很长，insert 和 find 的代价会迅速恶化，甚至出现找不到空位的情况。所以必须设置一个阈值，在数组还没完全拥挤时就提前扩容。

扩容的策略也很讲究。我选择“翻倍后取质数”，也就是 capacity = nextPrime(capacity * 2)。翻倍是为了让扩容后负载因子直接降到一半左右，这样后续插入很多元素才会再次触发扩容，摊还下来每次 insert 的成本仍然是 O(1)。

这里要提醒一个初学者常犯的错误：扩容不是简单地复制旧表内容，而是要把所有现存元素重新哈希一遍。因为容量变了，哈希函数里的取模结果也变了，原来存到 3 号位的元素，扩容后可能要放到 9 号位。这个“rehash”过程虽然在单次扩容时是 O(n)，但由于扩容次数很少，摊还后仍然是 O(1)。

2.4 删除标记：为什么不能用真删除

开放地址法最容易被忽视的坑是删除。假设 key A 和 key B 都映射到同一个槽位，A 先插入占用槽位 3，B 冲突后探测到槽位 4。此时如果直接删除 A，把槽位 3 标记成空，再查找 B 时，查找过程从槽位 3 开始，发现是空就立刻停住，B 就永远找不到了。

这就是所谓的“探测链截断”问题。所以删除时不能真正清空槽位，而是应该打一个 DELETED 标记，表示“这个位置以前有元素，现在没有，但查找时不能在这里停下，因为后面可能还排着被冲突挤走的元素”。

DELETED 槽位在插入时可以被复用。也就是说，插入新元素遇到 DELETED，可以直接占用它。但值得注意的是，DELETED 槽位多了以后，查找效率会下降，因为它们仍然会让探测链变长。所以我在 erase 里加了一个策略：删除数量超过容量的 30%，就触发一次 rehash，把所有 DELETED 槽位清掉，让表重新变紧凑。

3. C++ 模拟实现全程：从类骨架到可运行代码

3.1 节点数据结构与状态标记

我用一个枚举来表示槽位的三种状态：EMPTY、OCCUPIED、DELETED。这个状态标记是整个开放地址法实现的关键，没有它，删除逻辑就走不通。

cpp复制#include <iostream>
#include <string>
#include <functional>

enum class State {
    EMPTY,      // 从未使用，探测可在此终止
    OCCUPIED,   // 已存放有效键值对
    DELETED     // 逻辑删除，探测需跳过但可复用
};

template <typename K, typename V>
struct HashNode {
    K key;
    V value;
    State state;

    HashNode() : state(State::EMPTY) {}
};

之所以把状态独立出来，是因为 C++ 里 K 和 V 可能是没有默认构造函数的类型。如果直接用一个 bool 数组和一对 key-value 数组，删除时还需要把 key 或 value 重置掉，麻烦且容易出错。状态枚举配合 HashNode 默认构造，让每个槽位天生处在“空”的状态。

类的主体结构如下：

cpp复制template <typename K, typename V>
class HashTable {
public:
    explicit HashTable(size_t initCap = 8)
        : capacity(initCap), size(0), deleteCount(0) {
        table = new HashNode<K, V>[capacity];
        for (size_t i = 0; i < capacity; ++i) {
            table[i].state = State::EMPTY;
        }
    }

    ~HashTable() {
        delete[] table;
    }

    bool insert(const K& key, const V& value);
    bool find(const K& key, V& out);
    bool erase(const K& key);
    size_t getSize() const { return size; }

private:
    HashNode<K, V>* table;
    size_t capacity;
    size_t size;
    size_t deleteCount;

    size_t hash(const K& key) const {
        return std::hash<K>{}(key) % capacity;
    }

    bool isPrime(size_t n) const;
    size_t nextPrime(size_t n) const;
    void rehash();
};

这里我把 deleteCount 单独记一个字段，是为了在删除过多时能够及时清理。如果不记录的话，判断“DELETED 太多”就得遍历整个表，成本太高。

3.2 insert 插入：均匀分布是前提，探测是兜底

insert 的逻辑分两步：先判断是否需要扩容，然后沿着探测序列找到可以插入的槽位。

cpp复制bool insert(const K& key, const V& value) {
    if ((size + 1) * 1.0 / capacity > 0.7) {
        rehash();
    }

    size_t idx = hash(key);
    while (table[idx].state == State::OCCUPIED) {
        if (table[idx].key == key) {
            return false;   // 已存在，不重复插入
        }
        idx = (idx + 1) % capacity;
    }

    if (table[idx].state == State::DELETED) {
        --deleteCount;
    }

    table[idx].key = key;
    table[idx].value = value;
    table[idx].state = State::OCCUPIED;
    ++size;
    return true;
}

有几个细节值得展开讲。

首先是负载因子的判断条件，我写的是 (size + 1) * 1.0 / capacity > 0.7。这里用 size + 1 是因为要把即将插入的这个元素算进去。如果写成 size / capacity，就会在临界点插入后才超负载因子，导致下一次插入又要触发扩容，效率变差。

其次是 while 循环里对相同 key 的检查。因为我们的探测序列会经过所有可能存放这个 key 的位置，所以如果在某个 OCCUPIED 槽位发现了相同的 key，说明这个 key 已经在表里了，直接返回 false，不重复插入。这个重复检查必须放在冲突处理循环里，不能放在循环外。

第三，插入时如果遇到 DELETED 槽位，可以直接覆盖。因为 DELETED 本来就是无效数据，覆盖它既不影响查找，又回收了空间。覆盖后要记得把 deleteCount 减掉，否则删除计数会越积越多，误导清理逻辑。

3.3 find 查找：遇到 DELETED 不能停

find 的代码和 insert 很像，但有一个关键区别：遇到 DELETED 必须继续探测，遇到 EMPTY 才能停止。

cpp复制bool find(const K& key, V& out) {
    size_t idx = hash(key);
    size_t start = idx;

    while (table[idx].state != State::EMPTY) {
        if (table[idx].state == State::OCCUPIED &&
            table[idx].key == key) {
            out = table[idx].value;
            return true;
        }
        idx = (idx + 1) % capacity;
        if (idx == start) {
            return false;
        }
    }
    return false;
}

为什么要判断 idx == start？因为理论上如果表里全是 DELETED 或 OCCUPIED，while 循环就可能永远无法遇到 EMPTY，导致死循环。虽然我们通过负载因子上限保证了至少有一定数量的 EMPTY 槽位，但在大量删除后，表里可能充斥 DELETED，查找路径也会变长。加一个“转回起点就退出”的兜底，能让代码在任何边界情况下都不会卡死。

这是我在实际写代码时踩过的坑。第一次实现时没有加这个判断，然后在删除大量元素后执行一次 find，程序就直接卡住不动了。排查半天才意识到，是删除标记把可用空槽位都“挡住”了。

3.4 erase 删除：懒惰标记与触发清理

erase 也是先定位，再打删除标记：

cpp复制bool erase(const K& key) {
    size_t idx = hash(key);
    size_t start = idx;

    while (table[idx].state != State::EMPTY) {
        if (table[idx].state == State::OCCUPIED &&
            table[idx].key == key) {
            table[idx].state = State::DELETED;
            --size;
            ++deleteCount;

            if (deleteCount * 1.0 / capacity > 0.3) {
                rehash();
            }
            return true;
        }
        idx = (idx + 1) % capacity;
        if (idx == start) {
            return false;
        }
    }
    return false;
}

这里有两个细节。第一个是删除时把 deleteCount 加一，但不立即清理，因为频繁 rehash 代价太高。只有当 DELETED 占比超过 30% 时才做一次清理式扩容，摊还下来成本可控。第二个是 size 和 deleteCount 是此消彼长的关系：size 表示有效元素数，deleteCount 表示可复用但暂时浪费的槽位数。

有同学可能会问：删除后如果马上用 rehash 清理，不是更好吗？实际上，rehash 是 O(n) 操作，每删除一个元素就 rehash 一次会让哈希表退化得没法用。更合理的做法是把清理“积攒”起来，到影响性能时再统一做，这就是 deleteCount 阈值判断的意义。

3.5 扩容 rehash 与完整代码

rehash 的核心是“重建数组 + 重新哈希所有有效元素”。

cpp复制void rehash() {
    HashNode<K, V>* oldTable = table;
    size_t oldCapacity = capacity;

    capacity = nextPrime(oldCapacity * 2);
    table = new HashNode<K, V>[capacity];
    for (size_t i = 0; i < capacity; ++i) {
        table[i].state = State::EMPTY;
    }

    size_t newSize = 0;
    for (size_t i = 0; i < oldCapacity; ++i) {
        if (oldTable[i].state == State::OCCUPIED) {
            size_t idx = hash(oldTable[i].key);
            while (table[idx].state == State::OCCUPIED) {
                idx = (idx + 1) % capacity;
            }
            table[idx].key = oldTable[i].key;
            table[idx].value = oldTable[i].value;
            table[idx].state = State::OCCUPIED;
            ++newSize;
        }
    }

    size = newSize;
    deleteCount = 0;
    delete[] oldTable;
}

注意几个细节。第一，rehash 里不能直接调用 insert，因为 insert 里有扩容判断，rehash 过程中再扩容就乱套了。我在实现时直接在新数组上做线性探测插入，避免递归式的 rehash。第二，新表的所有槽位要初始化为 EMPTY，否则探测到的是未定义状态。第三，转移完成后要立刻 delete[] 旧表，否则内存泄漏。

isPrime 和 nextPrime 这两个辅助函数是重头戏之外的“小工具”，但对性能影响很大。

cpp复制bool isPrime(size_t n) const {
    if (n < 2) return false;
    for (size_t i = 2; i * i <= n; ++i) {
        if (n % i == 0) return false;
    }
    return true;
}

size_t nextPrime(size_t n) const {
    while (!isPrime(n)) ++n;
    return n;
}

isPrime 的循环条件是 i * i <= n，只需检查到 sqrt(n)，虽然对单个质数判断来说不是最优的，但在扩容场景下完全够用。工程上会做成一张质数表，比如 {53, 97, 193, 389, ...}，直接查表更快，但这里为了代码简洁就现场求了。

完整可运行的代码，包括 main 测试：

cpp复制#include <iostream>
#include <string>
#include <functional>

enum class State {
    EMPTY,
    OCCUPIED,
    DELETED
};

template <typename K, typename V>
struct HashNode {
    K key;
    V value;
    State state;

    HashNode() : state(State::EMPTY) {}
};

template <typename K, typename V>
class HashTable {
public:
    explicit HashTable(size_t initCap = 8)
        : capacity(initCap), size(0), deleteCount(0) {
        table = new HashNode<K, V>[capacity];
        for (size_t i = 0; i < capacity; ++i) {
            table[i].state = State::EMPTY;
        }
    }

    ~HashTable() {
        delete[] table;
    }

    bool insert(const K& key, const V& value) {
        if ((size + 1) * 1.0 / capacity > 0.7) {
            rehash();
        }

        size_t idx = hash(key);
        while (table[idx].state == State::OCCUPIED) {
            if (table[idx].key == key) {
                return false;
            }
            idx = (idx + 1) % capacity;
        }

        if (table[idx].state == State::DELETED) {
            --deleteCount;
        }

        table[idx].key = key;
        table[idx].value = value;
        table[idx].state = State::OCCUPIED;
        ++size;
        return true;
    }

    bool find(const K& key, V& out) {
        size_t idx = hash(key);
        size_t start = idx;

        while (table[idx].state != State::EMPTY) {
            if (table[idx].state == State::OCCUPIED &&
                table[idx].key == key) {
                out = table[idx].value;
                return true;
            }
            idx = (idx + 1) % capacity;
            if (idx == start) {
                return false;
            }
        }
        return false;
    }

    bool erase(const K& key) {
        size_t idx = hash(key);
        size_t start = idx;

        while (table[idx].state != State::EMPTY) {
            if (table[idx].state == State::OCCUPIED &&
                table[idx].key == key) {
                table[idx].state = State::DELETED;
                --size;
                ++deleteCount;

                if (deleteCount * 1.0 / capacity > 0.3) {
                    rehash();
                }
                return true;
            }
            idx = (idx + 1) % capacity;
            if (idx == start) {
                return false;
            }
        }
        return false;
    }

    size_t getSize() const { return size; }

private:
    HashNode<K, V>* table;
    size_t capacity;
    size_t size;
    size_t deleteCount;

    size_t hash(const K& key) const {
        return std::hash<K>{}(key) % capacity;
    }

    bool isPrime(size_t n) const {
        if (n < 2) return false;
        for (size_t i = 2; i * i <= n; ++i) {
            if (n % i == 0) return false;
        }
        return true;
    }

    size_t nextPrime(size_t n) const {
        while (!isPrime(n)) ++n;
        return n;
    }

    void rehash() {
        HashNode<K, V>* oldTable = table;
        size_t oldCapacity = capacity;

        capacity = nextPrime(oldCapacity * 2);
        table = new HashNode<K, V>[capacity];
        for (size_t i = 0; i < capacity; ++i) {
            table[i].state = State::EMPTY;
        }

        size_t newSize = 0;
        for (size_t i = 0; i < oldCapacity; ++i) {
            if (oldTable[i].state == State::OCCUPIED) {
                size_t idx = hash(oldTable[i].key);
                while (table[idx].state == State::OCCUPIED) {
                    idx = (idx + 1) % capacity;
                }
                table[idx].key = oldTable[i].key;
                table[idx].value = oldTable[i].value;
                table[idx].state = State::OCCUPIED;
                ++newSize;
            }
        }

        size = newSize;
        deleteCount = 0;
        delete[] oldTable;
    }
};

3.6 测试用例：验证删除标记的威力

写一个能展示设计亮点的测试，重点验证“删除一个冲突过的 key 之后，另一个 key 仍然能查到”：

cpp复制int main() {
    HashTable<int, std::string> table;

    table.insert(1, "one");
    table.insert(2, "two");
    table.insert(17, "seventeen");

    std::string val;
    if (table.find(17, val)) {
        std::cout << "17 => " << val << std::endl;
    }

    table.erase(1);

    if (table.find(17, val)) {
        std::cout << "after erase(1), 17 => " << val << std::endl;
    }

    std::cout << "size = " << table.getSize() << std::endl;
    return 0;
}

假设初始容量被扩容到某质数后，1 和 17 发生了冲突。如果没有删除标记，erase(1) 把槽位置为 EMPTY，find(17) 就会在探测到这个 EMPTY 时提前返回 false。而我们的实现里，删除后是 DELETED 状态，find(17) 会继续往后探测，最终找到 17。这段测试跑通，说明删除标记的逻辑是自洽的。

我自己调试时还会加一个遍历打印函数，把每个槽位的下标、状态、key 都打出来，这样能直观看到冲突之后元素到底是怎么排布的。建议你也试试，对理解探测序列帮助很大。

4. 常见问题与排查技巧实录

4.1 “插进去了，为什么查不到”

这是手写哈希表时最常遇到的问题。出现这个现象，原因通常集中在三个地方。

第一，erase 把槽位直接置成了 EMPTY，导致探测链被截断。这是最常见的原因，解决方法是把删除改成 DELETED 标记。

第二，扩容后重新哈希时逻辑写错了。比如直接拷贝旧数组，没有重新取模，那么容量一变，很多元素的真实位置就找不到了。调试方法是打印扩容前后每个 key 的 hash 值，看看是否因为容量变化而产生不同结果。

第三，find 的 while 循环里，遇到 OCCUPIED 但 key 不相等时没有继续探测，直接返回 false。这也是一种典型的截断。

排查思路是：不要靠猜，直接把哈希表内部的槽位状态打印出来，对照 key 的初始哈希下标手动模拟一遍探测过程，基本一眼就能看出问题出在哪一步。

4.2 死循环：探测序列始终找不到空位

死循环通常发生在 insert 或 find 时。insert 死循环的常见原因是负载因子判断写错，导致数组已经满了还在尝试插入；find 死循环则是因为表里的 EMPTY 槽位被 DELETED 和 OCCUPIED 挤占，探测序列一直找不到 EMPTY。

我的解决办法有两个。第一个是在 insert 入口强制检查负载因子，确保任何时候都有空槽位。第二个是在 find 和 erase 里加上 idx == start 的兜底判断，即使数据分布极端，也能退出循环而不是把程序卡死。

这里给一个调试建议：在 while 循环里加一个计数器，超过 capacity 就直接报错退出。这个方法虽然粗暴，但在开发阶段非常好用，能快速暴露“探测无终点”的问题。

4.3 自定义类型做 key：给 std::hash 做特化

如果 key 是自定义结构体，直接使用模板会编译报错，因为 std::hash 没有对应特化。解决方法也很简单：提供自己的 hash 特化，同时实现 operator==。

比如一个学生结构体，用姓名和班级联合作为 key：

cpp复制struct Student {
    std::string name;
    int classId;

    bool operator==(const Student& other) const {
        return name == other.name && classId == other.classId;
    }
};

namespace std {
    template <>
    struct hash<Student> {
        size_t operator()(const Student& s) const {
            size_t h1 = std::hash<std::string>{}(s.name);
            size_t h2 = std::hash<int>{}(s.classId);
            return h1 ^ (h2 << 1);
        }
    };
}

组合哈希时，把两个哈希值用异或乘一个系数合并，能让最终结果保持较好的分布。h2 左移一位再异或，是为了避免 name 和 classId 互换后得到相同哈希值。

有个细节提醒：做 key 的字段必须是不可变的。如果一个对象作为 key 插入后，它的某个字段变了，hash 值也会变，哈希表就再也找不到它了。这类 bug 极难排查，最好从一开始就遵守“key 只读”的原则。

4.4 性能观察与调优建议

代码跑通之后，建议做一轮简单的性能观察。我一般会统计两个指标：平均探测次数和插入过程中的扩容次数。

平均探测次数可以这样测：插入 n 个随机数后，对每个 key 执行 find，记录从起始槽位到命中之间的步数，再求平均。线性探测在负载因子 0.5 左右时，平均探测次数约为 1.5 次；负载因子 0.7 时大约会上升到 2 次多。如果你的测试数据远超这个数，说明哈希函数或容量选择有问题。

调优方向按收益排序：

• 提高哈希函数的随机性，尤其是对连续整数这种“低熵”数据；
• 把负载因子阈值从 0.7 降到 0.6，以空间换时间；
• 从线性探测升级为双重散列，减少聚集；
• 扩容时改用一个预生成的质数表，减少 nextPrime 的计算开销。

最后，虽然我们手写了一个能跑的哈希表，但生产环境中我仍然会优先选择 std::unordered_map。手写哈希表的意义在于理解原理，而不是重复造轮子。真正遇到自定义哈希表的场景，通常是在做高性能内存引擎、缓存系统，或者对内存布局有特殊要求时，到那时候再基于这套理解做工程优化也不迟。

我在实际项目里，曾经因为 unordered_map 在某个高并发场景下扩容时卡顿明显，改成了一套手写的开放地址法哈希表，配合预分配容量，才把延迟压下去。那次踩坑让我确信：了解哈希表的内部机制，不只是为了面试，更是为了在关键时刻能做出正确的判断。