哈希表刷题指南：从核心原理到题型套路与避坑实战

哈希表这块内容，我在LeetCode上反复刷过好几轮，从最早看到哈希题就只会无脑 unordered_map，到后来能根据题目条件判断到底该用哈希、排序还是双指针，中间踩了不少坑。这篇就把我在“哈希章节”里的思路整理和实现经验完整写出来，从最核心的原理讲到具体题型套路，再到底层实现和避坑指南，争取让你看完之后，再遇到哈希表相关题目时不是“背答案”，而是真的知道“这题为什么能想到用哈希”。

先说个整体感受：哈希表的题，本质就两类——一类是“利用哈希做O(1)查找”，另一类是“利用哈希做统计”。前者比如两数之和、最长连续序列，后者比如字母异位词分组、前K个高频元素。但真正拉开差距的，是你能不能在空间受限时想到“原地哈希”，以及你能不能理解哈希冲突对时间复杂度的影响。这两点，我会在后面重点展开。

1. 哈希的核心逻辑：先想清楚这题为什么需要哈希

1.1 哈希表的本质是“空间换时间”

很多初学者一上来就背哈希表的时间复杂度是O(1)，但你要问他为什么是O(1)，他答不上来。哈希表的本质是：把你要查找的key，通过一个哈希函数，直接映射到数组的某个下标，这样你不需要遍历整个数组，只需要在映射到的那个位置看一眼就行。这就是“空间换时间”。

举个例子，你在一个班级里找“学号为2024001的同学”，如果名单是按学号顺序排好的，你可以二分查找；如果名单是乱序的，你只能一个一个看。但如果你有一个柜子，每个学号对应一个抽屉，学号是多少就直接打开哪个抽屉，那就是O(1)。哈希表就是那个柜子。

这个类比很朴素，但它能帮你理解一件事：哈希表的O(1)是有条件的。条件就是哈希函数设计得好，让不同的key尽量均匀分布到不同位置。如果所有的key都映射到同一个位置，那就是“哈希冲突”，所有数据都会挤在一条链表里，查找退化成O(n)。这也是为什么在LeetCode上，有些极端测试用例能让你的哈希表代码TLE（超时）——不是你的算法错了，而是你的哈希函数被卡了。

1.2 数组是天然的哈希表，但只有“key值范围有限”时才能用

我在刷题时经常遇到的一种情况：题目明明可以用数组解决，但很多人一上来就写哈希表。比如LeetCode 242“有效的字母异位词”，题目说字符串只包含小写字母，那就是26个字符。这时候你可以直接用 vector<int> count(26, 0)，遍历s的时候count[s[i] - 'a']++，遍历t的时候count[t[i] - 'a']--，最后检查是否全为0即可。

为什么数组可以？因为字符’a’到’z’的ASCII码是连续的，s[i] - 'a' 就是一个范围在0到25的整数，天然就是一个完美映射，不会发生冲突。这就是“数组即哈希”的思想，哈希函数就是 s[i] - 'a'。

数组作为哈希表的核心优势是：不需要计算哈希值、不需要处理冲突，还能直接通过下标访问，性能远高于 unordered_map。但前提是key的取值范围必须已知且有限。如果题目条件里出现“不超过10^5”“只有26个小写字母”“值域在10000以内”这类字眼，第一反应应该是数组，而不是哈希表。

反过来，如果key的范围很大，比如是字符串、是浮点数、是任意整数，那就只能上真正的哈希表了。比如两数之和里，你需要查找“target - nums[i]”在不在集合里，nums[i]可以是任意int，你不可能开一个INT_MAX大小的数组。这时候才轮到哈希表出场。

1.3 什么时候该用哈希、什么时候该用排序，是一个高频混淆点

这是我刷题早期最容易纠结的地方。很多题目既可以用哈希，也可以用排序，而且两者能达到同样的时间复杂度级别。举几个典型例子：

• 查找重复元素：哈希法用set记录已经出现过的元素，遍历一遍，O(n)时间O(n)空间；排序法先sort再遍历相邻元素，O(nlogn)时间O(1)空间（如果不算排序栈的话）。两个都能做，关键看题目是否允许修改原数组、空间限制是多少。

• 字母异位词分组：可以用哈希，把每个字符串排序后作为key，value是分组列表；也可以把每个字符串的字符计数数组作为key。排序法是O(n·klogk)，计数法是O(n·k)，后者更优，但实现稍复杂。

• 最长连续序列：最经典的做法是哈希。题目要求O(n)时间，如果你先排序再遍历，那就是O(nlogn)，会超时。这是“必须用哈希”的典型。

我的判断标准是这样的：如果题目要求O(n)的时间复杂度，那就不要想排序，直接想哈希；如果题目没提时间要求，只是让你找重复或者找对应关系，那可以先想排序，因为排序的空间占用更可控。 另外，如果题目要求返回的是下标，那排序往往不行（因为你排序之后下标就丢了），除非你用pair存原始下标。如果只要求返回值，排序往往更简单。

2. 刷题前的工具选型：不同语言下哈希表的正确打开方式

2.1 C++：unordered_map、map、数组，三者的区别要分清

C++刷题选手最常用的就是 unordered_map 和 unordered_set。但很多人忽略了一个关键点：map 和 unordered_map 的底层实现完全不同。map 是红黑树，插入删除查找都是O(logn)；unordered_map 是哈希表，平均O(1)。在LeetCode的语境下，你几乎永远应该选 unordered_map，因为刷题默认追求O(n)或O(nlogn)的复杂度，map 的O(logn)查找在循环里用多了，整体复杂度就可能变成O(nlogn)甚至更高。

但这里有个隐藏的坑：unordered_map 的O(1)是“平均”情况。在C++的STL实现里，unordered_map 的扩容策略是当负载因子（元素个数/桶数）超过1.0时，将所有元素重新哈希到更大的桶数组里。这个扩容操作是O(n)的，虽然均摊后还是O(1)，但如果你在循环里频繁插入，可能触发多次扩容，常数很大。这就是为什么有些题明明算法复杂度是对的，却跑得比别人慢很多。

我个人的经验是：如果你能预估到元素个数，可以先 reserve 一下。比如：

cpp复制unordered_map<int, int> mp;
mp.reserve(10000);
mp.max_load_factor(0.7);

reserve(10000) 会预先分配足够的桶，避免多次扩容；max_load_factor(0.7) 会提高查找性能（减少冲突），但会增大内存占用。刷题时内存通常不是瓶颈，所以可以放心把负载因子调低一点，实测在大量哈希冲突的测试用例里，能明显提升速度。

再一个容易被忽略的：当你用 unordered_map 的 operator[] 访问一个不存在的key时，它会自动插入一个默认值。这在某些场景下是个坑。比如：

cpp复制for (int x : nums) {
    mp[x]++;  // 如果x不存在，会插入一个0然后+1
}

这本身没问题。但如果你做的是查询操作，比如“判断某个key是否存在”，一定用 find 而不要用 operator[]，否则会在不知不觉中污染数据。

2.2 Python：dict的底层是开放寻址法，但Python选手几乎不用关心

Python的 dict 就是哈希表，底层采用开放寻址法（open addressing），而不是拉链法。这意味着当发生冲突时，Python会通过探测序列寻找下一个空位，而不是挂链表。这也是为什么Python的 dict 在删除元素时不能简单地把位置置空，而是标记为“已删除”之类的特殊状态。

不过对于刷题来说，你基本不需要关心Python dict 的底层实现。你只需要知道：

• dict.get(key, default) 比 dict[key] 更安全，不会因为key不存在而抛异常。
• set 就是只有key、没有value的哈希表，适合去重和存在性判断。
• 在 Python 中，dict 的key要求是可哈希的（hashable）。整数、字符串、元组都是可哈希的，但列表、字典本身不可哈希。如果你需要把列表作为key，可以转成元组。

Python在刷题上的优势是写起来快，但劣势是常数较大。有些人用Python刷同样的题，即使复杂度一样，还是比C++慢很多倍。这个只能接受，但要注意别因为Python的常数问题，写出理论复杂度已经很高（比如O(n^2)）的代码——那样大概率TLE。

2.3 Java：HashMap的扩容和冲突处理机制

Java选手用 HashMap，底层是数组加链表/红黑树。当链表长度超过8（且数组长度超过64）时，链表会转成红黑树，避免冲突严重时查询退化成O(n)。这个设计在应对极端哈希冲突时比C++ STL的纯链表方案更稳健。

但Java的 HashMap 同样有扩容开销，初始容量是16，负载因子是0.75。如果你知道大概数据量，可以提前 new HashMap<>(expectedSize)，避免多次resize。刷题时我会根据题目的n来预估容量，比如n <= 10^5，就直接 new HashMap<>(n * 2)，减少扩容次数。

一个实用的坑：Java里 HashMap<Integer, Integer> 的 getOrDefault（对应C++里要先find再判断）在LeetCode上非常常用，写起来比 containsKey 加 get 两步高效多了，建议形成肌肉记忆。

3. 题型模型拆解：把哈希章节拆成四类套路

刷多了哈希题你会发现，它们不是散乱的，而是有套路的。我按自己的理解，把LeetCode的哈希题分成四个模型：

3.1 模型一：枚举 + 哈希存储（两数之和模型）

这类题的核心思路是：遍历一遍数组，边遍历边把已经见过的元素存进哈希表，在遍历到当前位置时，用哈希表查询“我需要的那个值”是否已经出现过。

最经典的当然是LeetCode 1“两数之和”。题目：给定数组nums和目标值target，返回两个数的下标，使得两数之和等于target。

最直白的暴力解法是双重循环，O(n^2)。但如果你换一个思路：遍历到nums[i]时，我需要找的是 “target - nums[i]” 这个值在不在数组里，并且它的下标不等于i。如果在，直接返回；如果不在，把nums[i]存进哈希表，继续遍历下一个元素。

cpp复制vector<int> twoSum(vector<int>& nums, int target) {
    unordered_map<int, int> mp;  // val -> index
    for (int i = 0; i < nums.size(); i++) {
        int need = target - nums[i];
        if (mp.find(need) != mp.end()) {
            return {mp[need], i};
        }
        mp[nums[i]] = i;
    }
    return {};
}

这里有一个关键细节：为什么不先一次性把所有元素都存进哈希表，再遍历一遍找答案？ 那样做也正确，但你需要额外判断“找到的下标不能是同一个元素”。比如nums = [3, 2, 4]，target = 6，如果你先存了3->0，2->1，4->2，然后查询的时候发现mp[2] = 1，mp[4] = 2，没问题。但如果nums = [3, 3]，target = 6，你存了3->0，第二次查的时候mp[3]是0，是不是就返回了[0, 0]？不对了。所以要么存的时候保留所有等值下标，要么边遍历边存，这样能天然避免“同一个元素用两次”的问题。

凡是“枚举+哈希存储”的题，核心都是这个思路：查一个、存一个。边遍历边存的好处是，你不需要处理“自己和自己配对”的边界情况。

这个模型可以推广到很多题，比如：

• LeetCode 167 两数之和II（输入有序数组）：其实可以用双指针O(n)空间O(1)，但如果你没注意到“有序”这个条件，用哈希也能做。
• LeetCode 454 四数相加II：把前两个数组的所有两两之和存进哈希表，再遍历后两个数组的两两之和，查负值。
• LeetCode 560 和为K的子数组：类似，但需要存前缀和出现的次数，不是下标。

3.2 模型二：去重与统计（计数模型）

哈希表另一个主要用途是“计数”或“去重”。这种题的典型特征是：你需要知道某个元素出现了多少次，或者需要判断某些元素是否已经出现过。

LeetCode 242“有效的字母异位词”就是最基础的计数题。它问两个字符串所含字母是否完全相同，只是顺序不同。一种解法是统计s中每个字符出现次数，再遍历t减掉次数，最后检查所有计数是否为0。上面说过，因为只有26个字符，可以直接用数组。

但如果字符范围不确定，比如LeetCode 49“字母异位词分组”，你没法直接用数组，因为字符串的key是任意字符串。这个题的思路是：设计一个“哈希key”来表示异位词这一等价类。

两种常见做法：

1. 排序法：把字符串内部排序，排序后相同的字符串就是同一组异位词。例如“eat”排序后是“aet”，“tea”排序后也是“aet”。用 map<string, vector<string>>，以排序后的串为key。

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

2. 计数法：把每个字符串的26个字母出现次数拼成一个字符串作为key，例如“eat”可以表示成“10000000000000000000000000”这种形式（第e位为1，第a位为1，第t位为1）。这个key比排序更精确地表达了“元素组成”。

这两种做法对比下来，计数法的理论复杂度是O(n·k)，排序法是O(n·klogk)。当字符串长度较大时，计数法更快。但计数法写起来稍微麻烦一点，我刷题时喜欢先用排序法，AC之后再考虑优化。

统计模型里最经典的高频题是LeetCode 347“前K个高频元素”。这个题要你返回数组中出现频率最高的前K个元素。思路非常清晰：

第一步，统计频率。 用哈希表统计每个元素出现次数，这是计数模型的标准操作。

cpp复制unordered_map<int, int> freq;
for (int x : nums) freq[x]++;

第二步，找前K个高频。 这一步有几种做法：

• 把所有pair扔进优先队列（大顶堆），弹出K个。时间复杂度O(nlogn)，简单直观。
• 维护一个大小为K的小顶堆，堆顶是当前K个最高频中最低的。遍历所有频率，如果新频率比堆顶高，就弹出堆顶，插入新元素。时间复杂度O(nlogK)，适合K远小于n的情况。
• 用桶排序（bucket sort）：频率最大为n，开一个大小为n+1的数组，下标为频率，值为对应的元素列表。从后往前遍历，取K个。时间复杂度O(n)。

cpp复制vector<int> topKFrequent(vector<int>& nums, int k) {
    unordered_map<int, int> freq;
    for (int x : nums) freq[x]++;
    int n = nums.size();
    vector<vector<int>> bucket(n + 1);
    for (auto& [val, cnt] : freq) {
        bucket[cnt].push_back(val);
    }
    vector<int> res;
    for (int i = n; i >= 1 && res.size() < k; i--) {
        for (int x : bucket[i]) {
            res.push_back(x);
            if (res.size() == k) break;
        }
    }
    return res;
}

这个解法很有意思，它用的是“数组即哈希”的思想——把“频率”当作下标。

3.3 模型三：O(1)查找的启发式题目（查缺补漏）

有一类题目，它的核心不是计数，而是利用哈希表做到“在O(1)时间内判断某个元素是否存在”，从而把暴力解法优化到线性。

LeetCode 128“最长连续序列”就是这个模型的巅峰之作。题目：给定一个未排序的整数数组，找出数字连续的最长序列（不要求序列元素在原数组中连续）的长度，要求时间复杂度为O(n)。

最容易想到的思路是排序后遍历，但排序是O(nlogn)，不符合O(n)的要求。这时候你被迫使用哈希表。

核心思路：

1. 先把所有元素放入一个 unordered_set<int>，去重并方便O(1)查找。
2. 遍历数组中的每个元素x，如果 set 中存在 x - 1，说明x不是某个连续序列的起点，跳过。
3. 如果 set 中不存在 x - 1，说明x是一个序列的起点，我们从这个起点开始，不断检查 x + 1、x + 2……存在与否，计数。
4. 记录最长长度。

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

很多人会担心这个解法的时间复杂度：外层循环O(n)，内层while循环可能也是O(n)，那么整体不是O(n^2)吗？

关键在于那行 if (s.count(x - 1)) continue;。这个判断保证了：只有序列的起点才会进入while循环。 比如数组是[1, 2, 3, 4]，遍历到1时，while循环会走4步；遍历到2、3、4时，都会因为存在x-1而被跳过，不会进入while。所以内层while循环的总执行次数，是所有连续序列的长度之和，最多为n。整体时间复杂度是O(n)，不是O(n^2)。

这个题是哈希“O(1)查找”优势的最典型体现，也是我在面试里高频遇到的题。它的核心技巧“判断是否为起点”，值得背下来。

同属这个模型的还有：

• LeetCode 202“快乐数”：按规则计算每个数的“平方和”，判断是否会陷入循环。用set记录出现过的数，如果在循环中重复出现，就返回false。
• LeetCode 219“存在重复元素II”：判断数组中是否存在重复元素，且下标差不超过K。用哈希表记录每个元素最近一次出现的下标，遍历时检查即可。

3.4 模型四：哈希索引下的下标/映射问题

最后一种模型是“哈希表存的是下标或映射关系”。这类题的典型特征是：你需要根据某个值快速找到它在原数组里的位置。

LeetCode 1“两数之和”其实也属于这个模型（存的是下标）。再举一个更典型的：LeetCode 219“存在重复元素II”，除了上面的set做法，还有一种做法是哈希表存下标。

cpp复制bool containsNearbyDuplicate(vector<int>& nums, int k) {
    unordered_map<int, int> mp;  // value -> last index
    for (int i = 0; i < nums.size(); i++) {
        if (mp.count(nums[i]) && i - mp[nums[i]] <= k) {
            return true;
        }
        mp[nums[i]] = i;
    }
    return false;
}

这里 mp 存的是每个值最近一次出现的下标，每遍历到一个新元素，就用当前下标和上次出现的下标比较，看距离是否不超过K。

另一种常见变体是LeetCode 290“单词规律”和LeetCode 205“同构字符串”，它们本质上都是“建立双向映射关系”。比如“同构字符串”是要检查s和t的字符是否一一对应。关键是：不仅要检查 s->t 的映射唯一，还要检查 t->s 的映射唯一。

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

这类“双映射”题目，是一个经典易错点：很多人只检查了一个方向的映射，导致“ab”和“aa”这种用例出错。

4. 原地哈希与手写哈希：空间不够时的进阶玩法

4.1 原地哈希：当题目暗示“值域有限”时的骚操作

前面提到过，数组就是天然的哈希表。但有时候，题目不让你额外开辟O(n)的数组，而是要求常数空间或者只允许在原数组上操作。这时候“原地哈希”（in-place hashing）就派上用场了。

原地哈希的核心思想是：把数组本身当作哈希表，利用下标和值之间的对应关系来存储信息。

最经典的题目是LeetCode 41“缺失的第一个正数”。题目：给你一个未排序的整数数组，请你找出其中没有出现的最小的正整数。要求时间复杂度O(n)并且只使用常数级别额外空间。

这个题如果没有常数空间的限制，最简单的做法是开一个布尔数组，标记哪些正数出现过，然后从1开始找第一个没出现的。但空间限制把这条路堵死了。

原地哈希的做法是：把值为x的元素放到下标为x-1的位置上。 举个例子，如果数组中有数字3，我们希望它出现在下标2的位置。遍历一遍数组，把所有在[1, n]范围内的数字x，交换到下标x-1的位置。第二遍遍历，检查每个下标i，如果nums[i] != i+1，说明i+1这个数没出现过，返回i+1。

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;
}

为什么用while而不是if？因为交换过来的新元素，可能也需要放到它该去的位置。比如数组[3, 4, -1, 1]，第一轮i=0，nums[0]=3，把3和下标2的元素交换，得到[-1, 4, 3, 1]；此时nums[0]变成-1，不在[1,n]范围内，退出while。继续i=1，nums[1]=4，要把4放到下标3，交换得到[-1, 1, 3, 4]；此时nums[1]变成1，1在[1,n]范围内而且下标0应该是1的位置，所以继续交换nums[1]和nums[0]，得到[1, -1, 3, 4]。注意，这里nums[1]变成-1后才退出。

这个while循环保证了每个元素最多被交换一次（准确地说，是每次交换都会把至少一个元素放到正确位置，所以总交换次数不超过n），因此整体时间复杂度是O(n)。

还有一个更简单的原地哈希例子：LeetCode 442“数组中重复的数据”。题目说数组长度n，元素值在[1, n]之间，有些元素出现两次，找出所有出现两次的元素。

这个题的原地哈希技巧是：用“下标为x-1的位置上的值的正负”来标记“x是否出现过”。 遍历数组，遇到值x，就把下标x-1上的值取为负数。如果某次取负时发现已经是负数了，说明x已经出现过一次，记录到答案中。

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

注意：遍历时x可能已经被前面的操作取过负了，所以要 abs(x) 取绝对值，因为原始值可能在前面被标记过了。

这两个题的共同点在于：题目明确说明了元素值范围是[1, n]或者正整数，这就是“值域有限”的信号。看到这个信号，你应该第一时间想到“能不能用数组代替哈希表”，如果空间限制很严格，则进一步想到“能不能在原数组上做文章”。

4.2 手写规则：哈希函数和哈希冲突的工程细节

虽然刷题时我们用现成的哈希表居多，但理解哈希函数和冲突处理方式，能帮你解决两类问题：一是有些题目会“卡”STL的哈希，你需要手写一个更稳的哈希函数；二是面试官喜欢追问底层原理。

C++ STL的 unordered_map 底层是“数组 + 链表”（拉链法）。当两个不同key映射到同一个桶时，它们会挂在同一条链表上。查找时先计算桶索引，再在链表里顺序查找，所以最坏情况是O(k)，k是桶内元素个数。

哈希函数的选择决定了冲突的多少。C++对整数的默认哈希实际上就是“取模”——hash(key) % bucket_count。在早期C++标准里，bucket_count是质数时取模结果更均匀，所以STL的默认桶数量通常是质数，比如13、29……但后来改用一些更复杂的哈希策略，对普通整数来说，效果基本一致。

不过有一类特殊情况：如果key是自定义类型（比如结构体、pair），STL没有默认哈希函数，你需要自己定义。LeetCode上有些题目会用到pair作为key，这时候你需要手动写一个简单的hash functor：

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

这里的1000003是一个大质数，用来尽量分散结果。这个写法不完美，但足够应对刷题场景。

再说一下“哈希冲突被卡”这个坑。有些LeetCode题目是专门设计来卡住默认哈希的。比如如果题目设计了一堆整数，它们的哈希值都映射到同一个桶，那unordered_map查找就退化成O(n)，你的代码可能TLE。实践中，如果遇到这种极端情况，我的临时方案是换用 map（红黑树，O(logn)查找，不受哈希冲突影响），或者手写一个“随机偏移”的哈希函数：

cpp复制struct custom_hash {
    static uint64_t splitmix64(uint64_t x) {
        x += 0x9e3779b97f4a7c15;
        x = (x ^ (x >> 30)) * 0xbf58476d1ce4e5b9;
        x = (x ^ (x >> 27)) * 0x94d049bb133111eb;
        return x ^ (x >> 31);
    }
    size_t operator()(uint64_t x) const {
        static const uint64_t FIXED_RANDOM = chrono::steady_clock::now().time_since_epoch().count();
        return splitmix64(x + FIXED_RANDOM);
    }
};

这个splitmix64算法的效果是：把连续的整数均匀打散到不同的桶里，从而避免被“卡冲突”。如果你在LeetCode上遇到TLE但怎么想都觉得复杂度没错，可以试试换成这个哈希函数，有时确实能救回来。

其实明白了这些底层机制，刷哈希章节的很多“玄学TLE”都能解释清楚。你不需要成为哈希函数专家，但至少要知道：STL的哈希不是万能稳定的，极端情况下你可以干预它。

4.3 哈希表常数的优化思路

除了手写哈希函数，还有一些实际提升性能的小习惯，刷题多了会自然形成：

• 能用数组就不上哈希表：数组访问是连续的，CPU缓存友好；哈希表计算哈希值时，还伴有取模、内存跳转等操作，常数大得多。只要值域允许，优先数组。
• 避免重复哈希计算：在循环里如果需要反复用同一个key查哈希表，能不能把这个key提前算好？比如两数之和里，nums[i]每次都是固定的，没必要每次都用 mp.find(nums[i]) 再取一次哈希，但其实STL已经帮你缓存了内部状态，这个优化空间不大。
• reserve / max_load_factor：前面已经提过，在知道数据规模的前提下，提前 reserve 可以避免多次扩容。
• 用find而不是count再访问：很多人喜欢写 if (mp.count(x)) return mp[x];，但这样会哈希两次。正确做法是：

cpp复制auto it = mp.find(x);
if (it != mp.end()) {
    return it->second;
}

一次 find 拿到迭代器，直接 it->second 访问值。count 再 operator[] 会做两次查找，虽然常数不大，但高频循环里累计起来肉眼可见。

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

5.1 unordered_map 常见使用错误

我在刷题过程中，遇到过不少因为 unordered_map 使用不当导致的bug，这里列一个速查表：

先说“遍历时删除”这个坑。如果需要在遍历哈希表时删除部分元素，C++里你可以这样做：

cpp复制for (auto it = mp.begin(); it != mp.end();) {
    if (should_delete(it->second)) {
        it = mp.erase(it);  // erase返回下一个迭代器
    } else {
        ++it;
    }
}

这里 erase(it) 会返回下一个有效的迭代器，避免了迭代器失效的问题。

5.2 哈希表乱序导致的“输出顺序不对”

LeetCode上很多题要求返回结果列表，而哈希表的遍历顺序是不确定的。当你用哈希表收集答案后，如果题目没有明确要求顺序（比如“任意顺序”），那没问题；但如果题目要求按某种顺序输出，你就要注意了。

最典型的场景是“字母异位词分组”和“前K个高频元素”。LeetCode 49的题目明确说了“可以以任意顺序返回结果”，所以直接遍历哈希表push_back就行。但LeetCode 347如果没有明确“任意顺序”，你可能需要对频率排序后再输出。

我在实际做题时踩过一个坑：LeetCode 49我用 unordered_map 分组后，直接遍历map收集结果，提交时发现有时输出顺序和预期样例不一样，但AC了。后来仔细看题才发现题目写了“可以以任意顺序返回结果”。所以以后做题，看到“任意顺序”这四个字，就放心遍历哈希表；没写这四个字，就要注意输出的排序规则。

5.3 为什么我的代码总是TLE？聊聊哈希的性能陷阱

如果你确定算法复杂度没问题，但代码还是TLE，优先级从高到低排查这几个点：

1. 是不是用了 unordered_map 却频繁 operator[] 查询不存在的key？ 这个行为会不断插入新元素，导致哈希表膨胀，后续操作越来越慢。
2. 是不是在循环里复制了很大的数据结构？ 比如 unordered_map<int, vector<int>>，每次访问value时如果不小心写成 auto v = mp[key]，就会复制整个vector，O(n)的复制操作在循环里会爆炸。正确写法是 auto& v = mp[key]。
3. 是不是被哈希冲突卡了？ 尝试换 map 或者手写哈希函数，看时间是否有改善。
4. 是不是可以预处理却每次重复计算？ 比如统计字符频率时，如果同一个字符串在循环里用了多次，可以提前把它的频率数组算好，存成key。

这里特别强调第2点。C++里 mp[key] 返回的是引用，但如果你 auto v = mp[key]，auto 会自动推导成值类型，相当于复制一份。这个坑我踩了不止一次。正确的习惯是：

cpp复制for (auto& kv : mp) {
    // kv.second 是引用，不会复制
}
// 或者
auto& vec = mp[key];

5.4 哈希冲突的极端场景：为什么C++的unordered_map有时“很慢”

最后再详细聊一个容易被忽视的性能问题。C++的 unordered_map 在遍历和插入时的常数，实际上比 map 小，但比数组大得多。但在一个特殊场景下，unordered_map 会“很慢很慢”——当大量的key发生哈希冲突，全部落在同一个桶里时，每次查找都是O(n)的链表遍历。

LeetCode有一些题目被社区广泛吐槽“用unordered_map会卡”。比如某些设计为“卡hash”的用例，输入的整数在默认哈希函数下大量落到同一个桶。这时候你的O(n)算法实际执行是O(n^2)。

如果遇到这种题，有几种对抗策略：

• 用一个自定义哈希函数，比如上面提到的splitmix64。
• 改用 map（红黑树），虽然从O(1)变成O(logn)，但不会退化成O(n)，而且红黑树的常数通常比退化的哈希表小。
• 看题目数据范围，如果值域不大，改用数组。

我曾经在某场周赛（后来想起来是LeetCode周赛430的某题）里遇到过这种：“nums数组很大，值域很广，要求统计频率”，我用 unordered_map 做统计出现了TLE，换成 map 反而过了。原因就是测试数据里存在针对默认hash的冲突用例。后来我学乖了，在重要比赛里，涉及大量整数哈希的题，优先考虑手写哈希或者 map 兜底。

6. 新手刷哈希章节的路径建议

如果你刚开始刷LeetCode，我个人建议按下面这条路径推进，每个阶段都踩实了再进入下一阶段：

第一阶段：掌握数组替代哈希表的技巧。 先刷LC 242数组法、LC 387字符串中第一个唯一字符、LC 349两个数组的交集。这些题用数组就能做，目的是建立“值域有限时用数组”的直觉。这个阶段的核心练习是：读完题，先问自己“key的取值范围是多少？”。这个问题会在之后的每一个哈希题里都伴随你。

第二阶段：掌握 unordered_map/map/dict 的基本增删查。 刷LC 1两数之和、LC 217存在重复元素、LC 219存在重复元素II、LC 350两个数组的交集II。这个阶段的目标是熟练使用“查一个、存一个”的边遍历边处理模式，以及 find 和 operator[] 的区别。

第三阶段：综合应用。 刷LC 49字母异位词分组、LC 347前K个高频元素、LC 128最长连续序列、LC 560和为K的子数组。这些题需要你灵活设计哈希的key，而不仅仅是“存个int进去”。做LC 49时去想“什么是异位词的良好key”，做LC 560时去想“前缀和配合哈希的巧妙之处”。

第四阶段：原地哈希和手写哈希。 刷LC 41缺失的第一个正数、LC 442数组中重复的数据、LC 268丢失的数字、LC 448找到所有数组中消失的数字。这组题是哈希进阶的分水岭，做会它们，你就从“会用哈希”变成了“理解哈希”。

到这里，哈希章节的基本盘就差不多了。后面再碰到哈希题，不管它包装得多花哨，你都能快速识别出它属于哪个模型，然后一步步拆解。

在LeetCode上刷哈希章节，确实是一个从“背接口”到“懂思想”的过程。你最开始可能只是学会了 map[x]++ 这种写法，但刷到后面，你会开始思考哈希冲突、负载因子、原地哈希，甚至会去手写一个哈希函数来对抗卡数据的用例。这些思考深度，最终会反映在你的解题速度和代码质量上。我希望这篇关于哈希章节的思路和实现整理，能帮你少走一些我走过的弯路。