LeetCode哈希表刷题指南：核心原理与六大题型详解

1. 哈希表核心思路与选型

1.1 哈希表本质上是什么

哈希表这东西，说透了就是“数组下标的高级版”。普通数组用整数当下标，哈希表允许你用任何类型的“键”去定位一个值——字符串、对象、元组都行。它内部通过一个哈希函数把任意键映射成一个整数下标，然后存到数组的某个位置上。

我在刷 LeetCode 时，判断一道题该不该用哈希，就看一句话：我需不需要根据某个键快速找到对应的值，而且这个键不是连续整数？

举个例子，两数之和（LC 1）这种题，你要找的是“某个数是否已经出现过”。如果你用数组，只能覆盖数值在很小范围内的场景；数值稍微一乱，数组就爆了。而哈希表，本质上是把“我用不到的那部分下标空间”给压缩掉了，只保留真正出现过的键。

深入一点，这个压缩的过程分两步。第一步，哈希函数把所有键映射到固定范围的数字；第二步，如果两个键映射到了同一个位置，就要用冲突处理策略来解决。理解这一步，你才能真正理解为什么哈希表查询平均是 O(1)，而最坏情况是 O(n)。

1.2 在 LeetCode 刷题时怎么选数据结构

我见过很多新手一上来就 unordered_map，也不管场景合不合适。这里有个很实用的选型逻辑：

• 键是字符、数字范围有限（比如 26 个字母、0~n），直接用数组，O(1) 且常数极小，哈希表那套开销全免了。典型如 LC 387（字符串中的第一个唯一字符），用 int cnt[26] 就够。
• 键是字符串、键值范围大、需要自动扩容，用 unordered_map 或 unordered_set。
• 键需要保持顺序，或者需要找“最接近的键”，用 map / set（红黑树，O(log n)）。LeetCode 里哈希题很少要求有序，所以我九成情况都用 unordered_map。
• 键是一个组合（比如两个数的和），可以把组合序列化成字符串，或者用 pair<int,int> 配自定义哈希，这个后面细讲。

有一个容易被忽略的点是：数组查表的性能远比哈希表好。哈希表要计算哈希、处理冲突、做扩容，常数很大。所以像“字符出现次数”这种场景，用数组反而是更快、更省内存的选择。你刷题时会发现，很多题用数组替代哈希表能把耗时从几百毫秒压到几十毫秒。

1.3 哈希表背后的三个核心操作

哈希表其实只有三个操作：插入、查找、删除。所有 LeetCode 哈希题，翻来覆去都是在这三个操作上做文章。

插入是“把键和值绑定，放入桶中”；查找是“输入键，快速定位值”；删除是“把键值对从桶中移除”。难点不在操作本身，而在“什么时候插入”“什么时候查找”“用什么样的键”。

比如无重复字符的最长子串（LC 3），本质上是：窗口右边界每次都要查一下“当前字符上次出现在哪”，然后决定左边界跳到哪。这就是一个“边插入边查找”的过程——窗口滑动的每一步，既有查询，又有插入，还有可能的删除。

再比如字母异位词分组（LC 49），核心思路是把“一组异位词”映射到同一个键。怎么映射？排序后的字符串，或者计数数组序列化后的字符串。这一步的关键不是哈希表操作，而是“键的设计”——你设计的键必须让同一类东西相等。哈希表只是最后负责把同键的元素聚到一起。

所以我的建议是：刷哈希题时，先想清楚“键是什么”，再想“值是什么”，最后才是选哪种容器。

2. LeetCode 六类高频哈希题型拆解

2.1 查找配对类：两数之和的两种解法

“给我一个数组，找两个数之和等于 target”，这几乎哈希章节的入门题。但很多人只背了答案，没理解逻辑。

最直观的思路是双重循环，逐个配对，复杂度 O(n²)。优化的关键点是：在遍历的过程中，往前走一步，就把当前这个数存起来；下一个数来的时候，直接查“target - 当前数”在不在容器里。这样每个数只需要查一次表，O(n) 就解决了。

C++ 实现大概是这样的：

cpp复制vector<int> twoSum(vector<int>& nums, int target) {
    unordered_map<int, int> pos;
    for (int i = 0; i < nums.size(); i++) {
        int need = target - nums[i];
        if (pos.count(need)) {
            return {pos[need], i};
        }
        pos[nums[i]] = i;
    }
    return {};
}

这里有个细节我踩过坑：先查找再插入，还是先插入再查找？ 对于两数之和这种“同一个元素不能重复用”的题，必须先查找再插入。如果反过来，遇到 target = 6, nums = [3, 3] 这种情况，第二次遇到 3 时，哈希表里已经有一个 3 了，但实际上这对应的是两个不同位置的元素，结果还算正确；可如果数组是 nums = [3]，先插入后查找，就会用同一个元素“自配对”，那就错了。

升级版是三数之和（LC 15）、四数之和（LC 18）。这类题虽然标准做法是“排序 + 双指针”，但排序后配合哈希表做去重也常有用武之地，尤其是面试追问优化时，哈希表那套思路能帮你更快意识到“为什么要排序”——因为排序后重复元素相邻，方便跳过。

2.2 计数类：字符统计的数组优化策略

计数类题目的特征是：统计每个“键”出现的次数，再做判断。比如有效的字母异位词（LC 242），两个字符串包含的字符相同、数量相同，顺序无所谓。

这类题最朴素的解法是排序后比较：

cpp复制bool isAnagram(string s, string t) {
    sort(s.begin(), s.end());
    sort(t.begin(), t.end());
    return s == t;
}

时间复杂度 O(n log n)。但更符合哈希章节气质的做法是计数数组：

cpp复制bool isAnagram(string s, string t) {
    int cnt[26] = {0};
    for (char c : s) cnt[c - 'a']++;
    for (char c : t) cnt[c - 'a']--;
    for (int i = 0; i < 26; i++) {
        if (cnt[i] != 0) return false;
    }
    return true;
}

两个字符串互相抵消，最后全为 0 才是异位词。这个思路在处理“多组字符串，互相判断是否异位词”时尤其好用，而且数组的 26 个槽位是固定的，内存极度可控。

还有一类计数题是“众数”问题。求众数的摩尔投票法虽然不依赖哈希，但哈希计数是最容易想到的暴力解：

cpp复制int majorityElement(vector<int>& nums) {
    unordered_map<int, int> cnt;
    for (int x : nums) {
        if (++cnt[x] > nums.size() / 2) return x;
    }
    return -1;
}

这类题你刷多了会发现：“先统计，再判断”是最容易想到的降维打击方案。虽然有些题有更优的数学解或双指针解，但在面试时间紧张的情况下，哈希计数能保证你拿到基础分数。

2.3 分组聚合类：字母异位词分组的键设计技巧

LC 49 要求把同一组异位词放到同一个列表里，这就涉及到“怎么把多个不同的字符串捏成同一个键”。

排序法最直接：异位词排序后完全相同，用排序后的字符串做键。

cpp复制vector<vector<string>> groupAnagrams(vector<string>& strs) {
    unordered_map<string, vector<string>> mp;
    for (auto& s : strs) {
        string key = s;
        sort(key.begin(), key.end());
        mp[key].push_back(s);
    }
    vector<vector<string>> res;
    for (auto& [k, v] : mp) res.push_back(v);
    return res;
}

另一种是用长度为 26 的计数数组，把每个字符的出现次数拼成一个字符串，比如 #1#2#0#...。这种方法避免了 sort 的 O(k log k) 开销，变成 O(k)。两种方法都能过，但如果你追求极致的性能，计数数组序列化的方案更快。

实际刷题时有个容易踩的坑：如果你用“排序后的字符串”当 key，排序的对象是原始字符串，那么收集结果时一定要把原始字符串 push 进去，而不是 key。我见过不少人把 key 存进结果，最后提交全错。

分组类的题目套路高度统一：设计键 -> 遍历元素 -> 把元素放入对应的组。键设计得巧不巧，直接决定题目难度。类似的还有“同源字符串分组”等变形题。

2.4 去重与前缀和类：最长连续序列的起点判定

最长连续序列（LC 128）是哈希题里的经典硬骨头。要求找数字连续的最长序列，而且时间复杂度必须 O(n)。关键词是“连续”，所以排序的思路被直接枪毙——排序本身至少 O(n log n)。

正确做法是用集合把所有数字存进去，然后只从连续序列的起点开始向后扩展：

cpp复制int longestConsecutive(vector<int>& nums) {
    unordered_set<int> st(nums.begin(), nums.end());
    int res = 0;
    for (int x : st) {
        if (st.count(x - 1)) continue;  // 不是起点，跳过
        int cur = x, len = 1;
        while (st.count(cur + 1)) {
            cur++;
            len++;
        }
        res = max(res, len);
    }
    return res;
}

这里最关键的优化是 if (st.count(x - 1)) continue;。为什么这句这么重要？因为如果不加，对于从 1 到 100000 的连续数组，你会在每个数字上都扩展一遍，整段序列被反复扫描，时间复杂度退化成 O(n²)（准确说是每个元素会被当起点尝试一次，但每次扩展都要查询，重复工作太多）。加了这个判断，只有序列真正起点才会进入内层循环，整体摊还 O(n)。

这种“只从链条头部开始走”的思想，在前缀和、链表中也有类似应用，值得刻进肌肉记忆。

2.5 前缀和类：和为 K 的子数组的哈希优化

“子数组和等于 k”的问题，暴力做法是先枚举起点再枚举终点，O(n²)。优化的核心是前缀和转换：

设 pre[i] 表示前 i 个元素的和。那么子数组 [j, i] 的和等于 pre[i] - pre[j-1]。要求它等于 k，就是求 pre[j-1] == pre[i] - k 的个数。于是这个问题就从“枚举位置”变成了“统计前缀和出现的次数”。

cpp复制int subarraySum(vector<int>& nums, int k) {
    unordered_map<int, int> cnt;
    cnt[0] = 1;
    int sum = 0, res = 0;
    for (int x : nums) {
        sum += x;
        if (cnt.count(sum - k)) res += cnt[sum - k];
        cnt[sum]++;
    }
    return res;
}

注意开头那句 cnt[0] = 1，它代表“前缀和为 0 的情况出现了一次”。没有它，如果整个数组的和正好等于 k，结果会漏算。这个细节我排查了差不多一刻钟才反应过来，建议你特别留意。

前缀和搭配哈希表，是“连续子数组”问题的万能钥匙。类似的还有“和为 K 的倍数”的变种（把前缀和对 k 取模后存入哈希表）。你一旦掌握了这个套路，会在很多题里看到它的影子——比如“连续数组”（LC 525）、“和可被 K 整除的子数组”（LC 974）。

2.6 双向映射与多键问题

有些题需要“键和值互相查找”，比如同构字符串（LC 205）。题目要求判断两个字符串是否同构，即 s 中的字符可以一一映射到 t 中的字符，且不同字符不能映射到同一个字符。

我第一次做这题时只建了一个映射表，结果卡在 s = "ab", t = "aa" 这种用例上。后来才明白：需要两张表，一张记录 s->t，一张记录 t->s，双向验证。

cpp复制bool isIsomorphic(string s, string t) {
    unordered_map<char, char> s2t, t2s;
    for (int i = 0; i < s.size(); i++) {
        char a = s[i], b = t[i];
        if ((s2t.count(a) && s2t[a] != b) || (t2s.count(b) && t2s[b] != a)) {
            return false;
        }
        s2t[a] = b;
        t2s[b] = a;
    }
    return true;
}

这种“双向映射”的本质是：数据之间存在双射关系，只映射一个方向会丢失信息。单词规律（LC 290）也是同样的思路，“a -> dog”和“dog -> a”两边都要验证。

多键问题是另一类高频考点，典型如四数相加 II（LC 454）。四个数组，暴力四重循环肯定超时。正确思路是：先把前两个数组的“两两之和”存进哈希表，再遍历后两个数组的“两两之和”的相反数有多少个，答案累加即可。

cpp复制int fourSumCount(vector<int>& A, vector<int>& B, vector<int>& C, vector<int>& D) {
    unordered_map<int, int> ab;
    for (int a : A)
        for (int b : B)
            ab[a + b]++;
    int res = 0;
    for (int c : C)
        for (int d : D)
            if (ab.count(-c - d)) res += ab[-c - d];
    return res;
}

这类题的核心思路就四个字：分组降维。把多重问题拆成两两组合，然后用哈希表把中间结果存下来，时间复杂度从 O(n⁴) 降到 O(n²)。

3. 原地哈希进阶：用数组本身做哈希表

3.1 什么是“原地哈希”

原地哈希不是一个容器，而是一种相当巧妙的思路：当数组元素的值域刚好在 [1, n] 范围内时，数组本身就可以当哈希表用——把元素 x 放到位置 x-1 上，这样“查 x 在不在”就是看“下标 x-1 的值是不是 x”。

这个思路化解了一个常见的困境：题目给了 O(1) 额外空间的限制，哈希表没法显式使用，但你又确实需要“快速判断某个值是否存在”。最典型的是 LC 41（缺失的第一个正数）。

题目这么要求：“只使用常数级别的额外空间”。如果直接拿 unordered_set 存，空间肯定是 O(n)，不满足要求。原地哈希的思路是：遍历数组，只要元素在 [1, n] 范围内，就把它和“它应该在的位置”上的元素交换，直到每个位置都放上了“正确”的元素（或者发现这个位置已经对了，就跳过）。

3.2 原地哈希的代码模板与易错点

以 LC 41 为例，我的实现是：

cpp复制int firstMissingPositive(vector<int>& nums) {
    int n = nums.size();
    for (int i = 0; i < n; i++) {
        while (nums[i] >= 1 && nums[i] <= n && nums[nums[i] - 1] != nums[i]) {
            swap(nums[i], nums[nums[i] - 1]);
        }
    }
    for (int i = 0; i < n; i++) {
        if (nums[i] != i + 1) return i + 1;
    }
    return n + 1;
}

这里有三个易错点，全是坑：

1. 交换条件必须写 while，不能写 if。因为交换过来的新数字可能仍然不在正确位置，要继续处理。比如数组 [3, 4, -1, 1]，把 3 放到位置 2 后，位置 0 换来了 -1，不满足继续交换的条件，循环结束；但有时候换过来的数字还是 1~n 范围，就还得继续。

2. 判断 nums[nums[i] - 1] != nums[i]，而不是判断当前位置“对不对”。如果当前位置已经有正确的值，就不需要交换；否则会出现死循环——两个位置的值反复互相交换。我初学时写过不加这个判断的版本，直接超时。

3. 等于 n 的元素要单独考虑。因为下标从 0 开始，元素值 n 应该放到位置 n-1，这个位置是存在的。但如果你用 nums[i] - 1 作为下标，元素 n 的下标是 n-1，是合法的。整个范围就是 [1, n]，不多不少。

原地哈希最适合的数字范围就是 [0, n-1] 或 [1, n]，在这个范围内它几乎无敌。超出范围的值，直接跳过不处理即可。

3.3 丢数字与重复数字的原地哈希解法

LC 268（丢失的数字）是原地哈希最简单的应用。数组包含 [0, n] 中 n 个数，缺一个。正常思路是求和相减或者异或，但用原地哈希也可以：把每个元素放到“它应该去的下标”，最后扫一遍找哪个位置没放对。

LC 448（找到所有数组中消失的数字）要求找出 [1, n] 中所有没出现的数。空间 O(1) 的解法是用“负数标记法”：遍历每个元素，把“以它的值为下标”的那个位置上的数变成负数，最后看哪些位置还是正数，就是缺失的数字。

cpp复制vector<int> findDisappearedNumbers(vector<int>& nums) {
    vector<int> res;
    for (int x : nums) {
        int idx = abs(x) - 1;
        if (nums[idx] > 0) nums[idx] = -nums[idx];
    }
    for (int i = 0; i < nums.size(); i++) {
        if (nums[i] > 0) res.push_back(i + 1);
    }
    return res;
}

为什么用负数？因为负数既起到了“标记”的作用，又不丢失原始信息的绝对值。遍历时取 abs(x) 还原原值，再定位下标。这个技巧我在好几个题里都用过，是“利用正负号做状态压缩”的经典案例。

LC 287（寻找重复数）更隐蔽。题目要求在 O(1) 空间里找重复数，而且不能改数组。严格来说它不用原地哈希，而是用“数组下标本身成环”的 Floyd 判圈法：把 nums[i] 看成“当前节点指向下一个节点的指针”，数组就成了一个链表，然后快慢指针找环的入口。但这个题的底层直觉依然是“下标和值的映射”——你要意识到这个映射关系天然存在，才可能往链表成环的方向想。

3.4 原地哈希的适用边界

不是所有范围 [1, n] 的题都能用原地哈希。如果题目要求不能修改原数组，那么原地哈希就废了，得换思路（比如 LC 287 用了快慢指针）。如果数组长度是 n，但元素范围是 [0, n]，原地哈希也能做，只是下标映射要调整成“值 x 放位置 x”。

实际刷题时我的判断标准很简单：如果题目出现了“常数级额外空间”这几个字，且元素值的范围能和有 n 挂钩，原地哈希就要进你的候选方案池。反之，如果题目明确允许额外空间，直接上普通哈希表，别跟自己过不去。

4. 哈希冲突与底层机制详解

4.1 两个不同的键映射到同一个桶

哈希表不可能让每个键都完美映射到唯一的位置——因为键的空间远大于桶的容量。所以一定会出现两个不同的键映射到同一个下标的情况，这就是哈希冲突。

理解冲突，不是为了造轮子，而是为了解释很多“诡异”的现象。比如为什么 unordered_map 在某些时候特别慢？因为冲突太多，查找退化成遍历链表。再比如为什么有人用“自定义哈希函数”能显著加速？就是因为让数据分布更均匀，冲突更少。

最常见的冲突解决方法是链地址法：每个桶里存一个链表（或其它结构），冲突的键都挂到同一根链表后面。C++ 的 std::unordered_map 默认就是这种方案。平均情况下每个桶的链表很短，查找还是 O(1)。

另一种是开放地址法：当冲突发生时，按某种探测规则去找下一个空位。常见的有线性探测（往后一个一个找）、二次探测（按平方数跳）、双重散列（用第二个哈希函数计算步长）。Python 的 dict 用的就是开放地址法。

这两种方案各有优劣。链地址法实现简单，删除方便，但需要额外的链表指针内存；开放地址法更省内存、缓存命中率高，但删除时涉及“墓碑”标记，表变满后性能急剧下降。

4.2 负载因子与扩容机制

负载因子 = 已存元素数 / 桶的总数。它衡量的是哈希表的“拥挤程度”。C++ unordered_map 的默认负载因子是 1.0，意思是元素个数达到桶数时，就会触发 rehash——重新申请更大的桶数组，把已有元素重新哈希一遍。

这个过程很昂贵，所以写算法题时如果你能预判元素规模，可以提前 reserve 来避免多次扩容。这也是很多题解里为什么会有这样一行：

cpp复制unordered_map<int, int> mp;
mp.reserve(nums.size() * 2);

reserve 的意义在于：一次性分配足够的桶，避免插入过程中反复扩容引发重新哈希，把 O(n) 级别的插入成本均摊下来。实测中，对几百万级数据做哈希，reserve 前后速度可以差几倍。LeetCode 的测试数据量大时，这一步偶尔能帮你从超时边缘拉回来。

4.3 自定义哈希函数为什么重要

std::hash 对整数、字符串都有默认实现，一般情况下够用。但有两个场景你需要自己动手：

一是自定义类型做键。比如你想用 pair<int, int> 当键，C++ 标准库没有提供 hash<pair<int,int>> 的特化，编译时会报错。我常用的自定义哈希是这样的：

cpp复制struct PairHash {
    size_t operator()(const pair<int, int>& p) const {
        return (size_t)p.first * 1000003 + p.second;
    }
};
unordered_map<pair<int, int>, int, PairHash> mp;

二是容易被人为构造恶意数据的场景。LeetCode 的测试数据是固定的，一般不会卡哈希，但在实际工程里，如果你的哈希函数太简单（比如直接用 hash(x) = x % bucket_count），攻击者可以构造大量冲突数据，把哈希表拖垮成 O(n) 查找。这就是“哈希拒绝服务攻击”。工程上一般用更复杂的哈希函数，或者加随机种子。

理解这点，对刷题有另一个现实作用：当你发现用 unordered_map 反而超时，而 map 却能过时，别急着下结论。先看看是不是哈希函数分布太差、冲突太多导致的。换一种更好的“哈希手段”（比如用数组替代）通常能解决问题。

4.4 哈希表的遍历顺序问题

unordered_map 的遍历顺序是无序的，而且不要依赖它内部的顺序。同一个哈希表，在两次插入顺序相同的情况下，桶的布局可能因为扩容历史不同而不同。所以你的算法逻辑绝不能依赖遍历顺序。

与此同时，如果你需要有序遍历，有两个选择：一是用 map（红黑树），键自动从小到大排序；二是把键取出来排个序。LeetCode 上很多题要求“按字典序返回结果”，直接用 map 往往比 unordered_map + 排序更简洁，虽然时间复杂度是 O(log n) 插入。

很多时候，我会因为这一条“顺序要求”就直接换容器。比如求前 K 个高频元素时，若结果需要按频率从高到低，我用优先队列；若需要按字母序，我就用 map 或者排序后处理。

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

5.1 用 map 还是 unordered_map，用错就超时

这是一个非常常见的“隐形杀手”。 map 底层是红黑树，插入和查找是 O(log n)；unordered_map 是哈希表，平均 O(1)。刷题数据量一大，map 常常在 10⁵~10⁶ 级别就力不从心了。

我本人就在 LC 128（最长连续序列）里踩过这个坑——第一版用 set 存储，结果提交超时。倒不是说 set 就一定过不了，但 unordered_set 在这类“高频查询”的场景下明显更合适。

换容器这件事，排查起来也快：如果超时，先把 map / set 换成 unordered_map / unordered_set，再做一次性能对比。当然，你的算法本身得保证不依赖有序性。

5.2 自定义 struct 做 key 的编译错误

刷题时经常遇到“坐标点”“二维矩阵位置”这种组合键，直接塞进 unordered_map 会编译失败，因为标准库不知道如何给自定义结构体求哈希。这是我的高频翻车点。

解决方案有三种：

1. 把键序列化成字符串：to_string(x) + "," + to_string(y)。简单，但字符串拼接有开销。
2. 用 pair<int,int> + 自定义哈希（前面写过）。
3. 把坐标编码成一个 long long：x * 100000 + y（前提是坐标范围已知，不会溢出或爆掉）。

第三种方案在竞赛里最常见，速度最快。比如二维网格题，坐标范围是 [0, 10⁵]，直接 key = x * 100001LL + y，塞进 unordered_map<long long, ...> 就完事了。注意用 long long 防止溢出。

5.3 遍历哈希表时删除元素导致的未定义行为

C++ 里在 for (auto& kv : mp) 的过程中直接 erase(kv.first)，会导致迭代器失效，程序直接崩溃或者行为诡异。正确的做法是：

cpp复制for (auto it = mp.begin(); it != mp.end(); ) {
    if (条件) {
        it = mp.erase(it);
    } else {
        ++it;
    }
}

erase 返回下一个有效迭代器，这样就能安全地边遍历边删除。另一个变通做法是：先把要删的键记录下来，遍历结束后统一删除。这个技巧在处理“滑动窗口 + 哈希表”时经常用到——比如窗口收缩时删除某些键，但你又在同一个循环里遍历，容易出事。

5.4 字符串哈希的耗时陷阱

当键是字符串时，哈希函数要对每个字符做运算，耗时远超整数哈希。尤其在“大量字符串作为 key”的题里，这一部分会成为性能瓶颈。两个常见优化：

一是用数组替代字符串 key。比如字母异位词分组里，可以用 array<int, 26> 配合自定义哈希，而不是把计数数组转成字符串当 key。

二是用 id 替代字符串。如果题目的字符串集合是已知的，给每个字符串分配一个唯一整数 id，然后用整数做 key，哈希效率直接上一个台阶。

实测下来，字符串哈希的常数大概是整数哈希的 5~10 倍。当你发现测试数据导致“哈希表操作占了绝大多数耗时”时，优先从“键的类型”下手优化。

5.5 哈希表键值重复覆盖的坑

有一类题要求“返回索引”，比如两数之和。如果数组里有重复值，后插入的索引会覆盖先插入的。这时候你要想清楚：我需要的是哪一次出现的索引？比如数组 [2, 2, 3]，target 是 4，答案是 [0, 1] 还是 [1, 0] 都行，但如果你用“先插入再查找”的方式，可能在处理第一个 2 时，哈希表里还没有任何记录，导致错过答案。所以必须“边查、边存、再往后走”，而不是“先全部存完再统一查”。

另一个经典场景是“多数元素”（LC 169）或“出现次数最多的元素”。如果题目只要求返回值而不要求索引，那直接 cnt[x]++ 覆盖就行，不用纠结。

5.6 内存占用与 reserve 的平衡

LeetCode 一般给 256MB 内存，unordered_map 这种容器在数据量大时其实挺吃内存的。每个节点除了键值，还有下一个节点指针、哈希值等额外开销。这个额外开销往往是数据本身的几倍。

我见过一种“偷懒”写法，用 unordered_map 做上千万级别的计数，结果内存直接爆了，又得回来换成数组或者压缩离散化。所以当你发现题目的“值域”是连续的、范围可控时，优先用数组；当你发现值域稀疏但范围巨大时，再用哈希表。

5.7 哈希与二分的边界选择

少量题目会让你纠结“这题到底用哈希还是二分”。我的判断标准是：如果数据是无序的且需要频繁查询，用哈希；如果数据是有序的且需要范围查询、找上下界，用二分+数组。

还有一个折中方案：把无序数据排序后再二分，适合“查询次数不多，但排序代价可接受”的场景。比如“两数之和”的另一种解法就是排序后双指针，虽然时间 O(n log n)，但空间 O(1)。哈希的做法时间是 O(n)、空间 O(n)。两者没有绝对优劣，看你更在意空间还是时间。

6. 刷题顺序与个人经验小结

6.1 推荐刷题路线

如果你准备系统刷透哈希这一章，我建议按这个顺序来，由浅入深：

1. 入门：LC 1（两数之和）、LC 217（存在重复元素）、LC 242（有效的字母异位词），先把哈希表基本操作和选型节奏掌握好。
2. 进阶：LC 49（字母异位词分组）、LC 128（最长连续序列）、LC 560（和为 K 的子数组），这几道题让你学会“键设计”和“前缀和哈希”这两个核心模板。
3. 综合：LC 41（缺失的第一个正数）、LC 448（找到所有数组中消失的数字）、LC 287（寻找重复数），这三道题把“原地哈希”和“无额外空间”的思路练扎实。
4. 挑战：LC 30（串联所有单词的子串）、LC 76（最小覆盖子串），滑动窗口 + 哈希的组合拳，能覆盖字节、腾讯这类公司的高频面试题。

我自己的经验是，前面 6 道题反复刷三遍，比囫囵吞枣刷 30 道新题更有效。哈希题型的套路化程度非常高，模板一旦刻进肌肉记忆，看到类似场景能秒反应。

6.2 一个实用的技能：先写注释再写代码

刷哈希题时，我习惯先在代码里写清楚“键是什么，值是什么”。比如两数之和，我会先写：

cpp复制// key: 数字的值
// value: 该数字最后一次出现的位置

这样写有一个实际的好处：写代码的过程中不会被“下一步要查什么”绕晕。哈希题的 bug 大头来自“键值语义没想清”，比如一个 map 里同时存了频率和索引，最后拿错值。

我给学生讲题时反复强调：哈希表里的“值”到底是什么，决定了你查完之后能不能直接用。如果你的 map 值存的是“出现次数”，查询时需要的是“索引”，那就得再开一张表，或者重新设计。

6.3 最后再分享一个排查小技巧

如果你用哈希表解题，提交后 WA 了，优先检查三件事：

1. 边界用例：空数组、单元素数组、全部元素相等。哈希表的边界问题往往出在这些情况下。
2. 键的语义是否统一：查的时候用的键，和插的时候用的键，是不是同一套规则？比如字符串有没有做大小写统一、去空格、排序。
3. 顺序问题：先查再插还是先插再查，不同题目要求不同，搞反就是全错。

这三条我用了很多年，踩过的坑基本都能被它们覆盖。哈希表本身不复杂，但细节很多，每道题都值得在提交前花 30 秒在脑子里过一遍这三个问题。