哈希表必刷三题：两数之和、异位词分组、最长连续序列背后的通用模板

如果你已经刷到哈希表这一块，我相信你绕不开这三道题：LeetCode 1（两数之和）、49（字母异位词分组）、128（最长连续序列）。这三题出镜率实在太高，几乎每一份算法面经里都能看到它们的身影，而且它们恰好构成了哈希表三种最核心的用法：边遍历边查历史、用 key 做聚合分组、用集合去重后做连续探测。

很多朋友刷完题之后只记得“这题用 HashMap 一下就过了”，但真到了面试现场，被问一句“为什么这里用哈希表？你的时间复杂度是怎么算的？”就卡住了。这篇文章会把三题串起来讲透，每道题都从暴力解出发，解释为什么需要哈希表，写出可以直接背的代码，最后再提炼出三套能迁移到其它题目的通用模板。不管你是正在准备校招、跳槽，还是纯粹想把算法基础打牢，照着这个思路走一遍，比零散刷几十道题都要值。

1. 三题背后的两条主线：哈希表到底在考什么

1.1 哈希表的本质和它擅长的场景

哈希表在面试里出镜率极高，但很多人对它的理解停留在“用 key 查 value 很快”。这话没错，却不够本质。哈希表的本质是把“查找某一个东西”的时间代价，从 O(n) 降到平均 O(1)。

你可以把它想象成一个带编号的储物柜：只要我根据某个规则算出物品该放哪个柜子，存取都只需要开一次门。这里的“某个规则”就是哈希函数，而两个不同物品算出同一柜号的情况叫“哈希冲突”，工程上解决冲突的方式有链地址法、开放寻址法，这也是 HashMap 底层链表转红黑树等优化的由来。面试时不用背太多底层源码，但你得知道：哈希表的 O(1) 是平均情况，不是最坏情况，如果哈希函数设计很差，理论最坏会退化成 O(n)。

回到刷题场景，哈希表真正厉害的地方不是“存数据”，而是让追问“以前遇到过的东西里，有没有和我现在需要的东西匹配的？”这个问题变成了瞬时操作。正因为这个特性，它天然适合三类问题：配对查找、按特征分组、连续可达范围探测。下面这三道题，正好就是这三类问题的代表。

1.2 三题如何覆盖哈希表的核心体系

我用一张表先给三题定个位，接下来每一题再单独展开。

注意看这道题里哈希结构的形态：第一题是“映射”的 HashMap，第二题是“映射到一个容器”的 HashMap，第三题干脆只需要 HashSet。同样是哈希，但用法完全不同，这就是为什么我把三题放在一起写，而不是单独写某一道。

1.3 用哈希表之前必须想清楚的边界

哈希表不是银弹，我见过不少人在该用数组下标的地方硬上哈希表，反而把代码写复杂了。这里给你两个非常实用的过滤器：

第一，数据范围是否足够小？如果题目明确说元素是 0 到 100 的整数，那你直接用数组 int[101] 做哈希其实是更优解，既避免了哈希冲突的开销，查询还是严格的 O(1)，不需要扩容，也不需要处理装箱。哈希表适合数据分布稀疏、范围不可控的场景。

第二，是否真的需要快速“回看”？如果每个元素只需要和它相邻的元素比较，排序往往更自然；如果你需要在遍历过程中反复确认“之前有没有见过某个值”，哈希表才是不二之选。记住这句话：哈希表解决的是“历史记忆的快速检索”，不是所有查找都要用它。

2. 第一题 两数之和：先查后存，把配对问题变成历史查询

2.1 先把题干条件看透

题目本身很短：给定一个整数数组 nums 和一个整数目标值 target，请你在该数组中找出和为目标值 target 的那两个整数，并返回它们的数组下标。你可以假设每种输入只会对应一个答案，并且你不能使用两次相同的元素。

“只有一组答案”这个条件很关键，意味着我们不需要考虑多个答案的合并情况，找到一组就可以返回。另一个隐蔽条件是“不能使用两次相同的元素”，这句话会在代码里坑到不少人，后面我会专门讲。

两个数相加等于 target，可以写成 nums[i] + nums[j] = target。如果从数学上移项，就变成了 nums[j] = target - nums[i]。也就是说，当我站在下标 i 的时候，我真正关心的不是前面所有元素，而是“前面有没有某个元素，它的值恰好等于 target - nums[i]”。如果有，那这一对就是答案。

2.2 暴力解为什么不行

最朴素的想法自然是两层循环，拿每个元素和它后面的每个元素配对相加，看看等不等于 target。这个解法时间复杂度是 O(n²)，在 LeetCode 的标准用例下 n 可以到 10⁴ 甚至 10⁵，平方级基本上会超时。

嵌套循环慢在哪里？慢在每次配对都要从头扫描数组。内层循环本质上是在做查找，而这个查找对象还是“无序的旧数据”。无序数组里的精确查找，最快的通用办法就是哈希表：先建哈希表，再对每个元素查它的互补数，查找代价就从 O(n) 变成 O(1)。这就是用哈希表替换暴力内层循环的核心逻辑。

2.3 先查后存的代码模板

先看最常用的 Python 版本，也是我认为最接近思路本质的写法：

python复制def twoSum(nums, target):
    history = {}          # 键：数值，值：该数值的下标
    for i, num in enumerate(nums):
        need = target - num
        # 先查历史：之前是否见过刚好能凑成 target 的数？
        if need in history:
            return [history[need], i]
        # 查不到再把自己存进去，供后面的元素匹配
        history[num] = i
    return []             # 按题意必有答案，这里只是兜底

每次循环只做两件事：查 need 在不在表里；不在就把当前 num 存进去。这段代码的顺序值得你用笔圈一下，它不是先存再查，而是先查再存。

再看 C++ 版本，思路完全一样，只是容器换成了 unordered_map：

cpp复制vector<int> twoSum(vector<int>& nums, int target) {
    unordered_map<int, int> mp;   // 值 -> 下标
    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 {};
}

很多教材会把这道题讲成“一遍哈希表”，关键就在“一遍”这两个字。我们不需要先把所有元素都存进去再查询，而是边遍历边存，这样既保证当前元素能和“之前的元素”配对，又天然避免了同一个元素被使用两次。

2.4 先存后查会踩什么坑

这是我认为这道题最值得讲的细节。有的写法是先在循环外面把所有元素存进哈希表，再在循环里查 target - nums[i]。这段逻辑一旦遇到 target 是两个相同值的和，就会出问题。举个例子：nums = [3, 3]，target = 6。如果先把两个 3 都存进去，哈希表里 key = 3 会存成下标 1（后面的覆盖前面的）。遍历到 i = 0 时，查 need = 3，返回 {1, 0}？如果按我上面的写法，history[need] = 1 而不是 0，虽然下标都满足结果，但逻辑上已经是“同一个位置的两个相同元素互相配对”的意思了。而正确做法是 i = 0 时直接把 history[3] = 0 存进去，i = 1 时查到之前存在下标 0，得到 {0, 1}，这才是真正“两个不同的元素”。

你肯定想问：那有没有情况必须先完整建表再查？有的，比如你要找“差值等于 k 的两数对”，如果 k 不为 0，先建表后查询也说得通，但依然要处理重复值覆盖的问题。我的建议是，只要题目要求返回两个不同元素的下标，一律采用先查后存，这是最不容易出错的做法。

2.5 两数之和能扩展成哪些变体

两数之和的思路一旦掌握，能直接迁移到一批变体题上。

如果题目不要求返回下标，只要求返回两个数值，那压根不用 HashMap，一个 HashSet 就够了。每遍历一个数，检查 target - num 是否在集合里，不在就把当前数加入集合。这里下标不再重要。

如果是三数之和，传统最优解是用“排序 + 双指针”，因为排序后可以通过移动左右指针从两端向中间逼近，天然避免重复答案，时间复杂度 O(n²)。但在某些场景下也可以先固定第一个数，把剩下的问题转成两数之和，再用哈希集合去重。两种方案我在面试时都答过，建议双指针为主，因为它对“生成结果不重不漏”控制得更好。

还有一个特别重要的延伸是带前缀和的配对问题。比如“和为 k 的子数组个数”，它的本质是把前缀和数组看成一个新数组，然后对每个位置查“之前有没有出现过 preSum - k”，这就是两数之和思想的远房亲戚。遇到子数组累加和、连续子数组整除类问题，记得往前缀和 + 哈希表这个方向想。

3. 第二题 49 字母异位词分组：key 的设计决定成败

3.1 为什么说这道题考的是“归约能力”

题目给你一组字符串数组，要求把“字母异位词”分到同一个组里。所谓字母异位词就是指两个字符串包含的字符种类和数量完全相同，只是排列顺序不同，比如 "eat"、"tea"、"ate" 是一组，"tan"、"nat" 是一组。

很多朋友看到这题第一反应是“挨个比较两个单词是不是异位词”，这个方向会很痛苦，因为两两比较的复杂度是 O(n²)。你需要换一个思路：与其比较两个对象是否等价，不如给每一类对象设计一个统一的“编号”，编号相同的自然进同一个组。

这就把问题从“两两比较”归约成了“设计 key”。哈希表在这里不是配角，而是核心：key 是经过规范化之后的字符串信息，value 是装着原始单词的列表。只要你把 key 设计对了，分组只是往桶里丢数据的事。

3.2 两种 key 方案：排序法和字符计数法

设计 key 最容易想到的方案是“排序后作为 key”。因为异位词经过排序之后一定会变成同一个字符串，比如 "eat" 和 "tea" 都排成 "aet"。这个方案直观、代码少，绝大多数面试场景下都够用。

python复制from collections import defaultdict

def groupAnagrams(strs):
    table = defaultdict(list)
    for s in strs:
        key = ''.join(sorted(s))
        table[key].append(s)
    return list(table.values())

这段代码里 sorted(s) 会把字符串拆成字符列表并排序，再用 join 拼回字符串。这里的 key 不要求能看懂原单词，只要保证：同一个异位词组内的字符串排序后相等，不同组的排序后不相等。排序法的时间复杂度是 O(k log k)（k 是单个字符串长度），整体是 O(n·k log k)。

另一种更“高级”的方案是字符计数法。既然异位词只关心字符种类和数量，那我们统计每个字符串中 26 个小写字母出现的次数，把“出现次数列表”转成只读的 tuple，作为 key。比如 "eat" 的计数数组在 'e'、'a'、't' 上各是 1，其他位置是 0，这个 26 维的 tuple 就是这个单词的“指纹”。

python复制from collections import defaultdict

def groupAnagrams(strs):
    table = defaultdict(list)
    for s in strs:
        cnt = [0] * 26
        for ch in s:
            cnt[ord(ch) - ord('a')] += 1
        key = tuple(cnt)
        table[key].append(s)
    return list(table.values())

这个方案把单个字符串的处理复杂度降到 O(k)，整体 O(nk)，不再有 log k 的排序损耗。但代码量比排序法大，如果面试不问“能不能优化”，直接用排序法足够；如果面试官追问复杂度，再把计数版亮出来，会是一个很自然的加分项。

两种方案对比下来：

3.3 字符计数 key 的边界问题

你可能会想：如果字符不是小写字母，而是 ASCII 全字符怎么办？如果你直接用 128 维数组，思路不变；如果字符集大到不可枚举，比如 Unicode 全字符，那就不能用定长数组了，可以退化回排序法，或者用 Counter 统计后把 items 排序转成 tuple。这里核心原则是：key 必须能够正确区分不同字符构成，而不是简单对字符编码求和。我见过有人用“字符 ASCII 码之和”当 key，这种设计在大多数时候能工作，但一旦遇到 "ab" 和 "bc" 这种恰好和值相等的反例就会出错，所以千万不要用和值当指纹。

字符计数 key 还有一个隐藏问题：同一个字符统计信息可以被无限复用，但在 Python 里列表本身不可哈希，所以必须转成 tuple。你在面试时如果写计数法，记得解释为什么要转 tuple：数组是可变对象，不能作为哈希表的键，只有不可变对象才可哈希。

再补充一个日常编程会遇到的坑：如果你处理的字符串含大写字母，而业务上认为 "A" 和 "a" 是同一个字符，那排序前必须先统一大小写，否则 "aB" 排序后是 "Ba"，"Ab" 排序后是 "Ab"，两者不会相等。LeetCode 这题因为限制了小写字母，所以不用考虑，但实际工程里首字母大小写归一化是一个非常常见的需求。

3.4 从分组题中学到的 key 设计通用原则

做完这题你会发现，它真正教你的是三件事。

第一，面对“按某种规则分组”的需求，不要两两比较，而是设计一个规范化的 key。这个思想可以用在很多地方，比如处理日志时把“同一接口不同参数顺序”的请求归并、把商品名里的全半角、空格、大小写差异抹平后做聚类、把地址文本归一化到同一省市区层级再聚合统计。

第二，key 的设计要满足两个条件：同组对象计算出的 key 一定要相同，不同组对象计算出的 key 一定要不同。如果条件一不满足，你会把同类数据拆到多个分组；如果条件二不满足，你会把不同类数据混在一个分组。工程里常见的错误就是 key 的“区分度不够”，比如只取日期而不取小时去聚合日志，结果把不同时段的数据揉在一起，后面的统计全偏了。

第三，value 可以是任意聚合容器，不一定是普通列表。如果题目要求去重，可以存一个 HashSet；如果要求计数，可以直接用 Counter 或累加器；如果想保留所有原始字符串包括重复项，才用列表。哈希表的 value 类型完全由你决定，这也是哈希表灵活性的来源之一。

4. 第三题 128 最长连续序列：用集合去重，只从起点探测

4.1 为什么“先排序”不是本题想要的答案

题目要求从一个无序数组中找出最长连续数字序列的长度，而且明确要求时间复杂度 O(n)。这里的“连续”不是指数组里的相邻位置，而是指数值上连续递增，比如 [100, 4, 200, 1, 3, 2] 里最长的连续序列是 1、2、3、4，长度为 4，尽管它们在原数组里是分散的。

看到“找出连续”的第一反应很可能是排序。排序之后数组变成有序的，你再遍历一遍统计连续段长度就行。时间复杂度是 O(n log n)，空间复杂度取决于你是否允许修改原数组。大部分时候排序法能顺利通过测试用例，但它不满足题目要求的 O(n)。

面试官故意把 n 的上限给得很大，目的就是逼你放弃排序，换一个“不需要全局有序”的思路。这里有个直觉：连续序列 1、2、3、4 之所以能成段，不是因为它们在排序后靠在一起，而是因为它们在数值上是“一步一个脚印”连起来的。从 1 出发有 2，从 2 出发有 3，以此类推。也就是说，我们真正关心的是“某个数是否存在于数组中”，而不是它的位置。既然只是判断存在性，哈希集合就是最合适的容器。

4.2 核心思路：去掉重复，找到每一个序列的起点

如果已经把所有数字装进 HashSet，那么对集合里的任意一个数 x，要判断它是不是某段连续序列的开头，只需要看 x - 1 在不在集合里。如果 x - 1 不在集合里，说明没有比 x 更小的接续数字，x 一定是一段连续序列最左边的那个数；如果 x - 1 在集合里，说明 x 不是起点，直接跳过。

找到了起点之后，就以起点为基准向后探测：x + 1 在不在，x + 2 在不在，直到遇到断档，统计这段的长度。

整个过程只需要两类操作：判断某个数在不在集合里（O(1)），以及从起点向后取下一个数。用 HashSet 存数据的好处是自动去重，而且可以随机判断任意数字是否存在。

4.3 为什么两层循环的总复杂度还是 O(n)

很多人看完上面的描述会担心：外层循环遍历每个数，内层 while 又要一直往后数，看起来像 O(n²)，为什么题目要求 O(n)?

关键在于“只有序列起点才会进入 while”。如果一个数 x 满足 x - 1 在集合里，它会被 continue 跳过，不会启动内层循环。真正启动内层循环的，只有每个连续段最左边的那个元素。也正因为如此，所有 while 循环合起来，总共只访问了每个连续段内的每个元素一次。想象一下集合被切成若干段：1-2-3-4 是一段，100 是单点段，200 是单点段。所有 while 里访问的元素总数就是集合大小 n，不是 n²。外层循环虽然扫描了所有数，但每个数只做了一次 O(1) 的起点判断。所以总复杂度是 O(n)。

这里还有一个代码层面容易忽略的细节：外层循环一定要遍历集合本身，而不是原数组。如果原数组里存在大量重复数字，比如 [1, 1, 1, 1, 2, 3, 4]，直接遍历原数组时第一个 1 作为起点会 while 出一个长度 4，第二个 1 又会被当作起点重新 while 一遍，造成重复工作。虽然不影响最终结果，但会让本应 O(n) 的实现退化。使用集合遍历能天然避免这类重复，这是本题最容易踩的性能陷阱。

4.4 Python 和 C++ 的高质量实现

Python 版本如下：

python复制def longestConsecutive(nums):
    num_set = set(nums)          # 去重，并提供 O(1) 存在性判断
    best = 0

    for x in num_set:
        # 只有 x - 1 不在集合里，x 才是某一段连续序列的起点
        if x - 1 not in num_set:
            cur = x
            cur_len = 1

            while cur + 1 in num_set:
                cur += 1
                cur_len += 1

            best = max(best, cur_len)

    return best

C++ 版本：

cpp复制int longestConsecutive(vector<int>& nums) {
    unordered_set<int> st(nums.begin(), nums.end());
    int ans = 0;

    for (int x : st) {
        if (!st.count(x - 1)) {
            int cur = x;
            int len = 1;
            while (st.count(cur + 1)) {
                ++cur;
                ++len;
            }
            ans = max(ans, len);
        }
    }

    return ans;
}

两个版本都很好读。如果面试官问“集合会不会因为冲突导致查找变慢”，你可以补一句：理论最坏确实会退化，但实际工程中哈希函数设计合理，所有操作基本都是 O(1)。如果数据范围很小且是整数，其实还可以把 HashSet 换成布尔数组，用下标直接标记是否存在，也是一种空间换时间的优化，适合面试时顺口提一嘴。

4.5 变式场景：连续段最长区间的业务意义

这道题的思路在很多业务场景里都有影子。

比如运营后台要判断某个用户最近是否连续活跃了超过 7 天，数据是分散的登录日期列表。你可以把日期转成时间戳或天数序号，放到 HashSet 里，然后找最长连续天数。这个场景几乎就是 128 题的原版，只是元素从整数变成了“日子”。

又比如数据库或操作系统的“空闲块合并”：磁盘上有一些零散的空闲扇区编号，需要找连续的空闲区段，以便分配大块连续空间。这同样是“从起点开始找连续块”的思想，无非还要额外判断每个块是否能用、是否被标记。

再比如股票、订单、传感器上报事件中的连续时长检测：上游不确定哪些时间点有数据，你想知道哪些时间段是不间断覆盖的，可以把时间戳量化到秒级别，存进 HashSet，找出最长无缝时间窗口。总之，凡是给定一堆点，要找连续覆盖范围的问题，都可以考虑“集合 + 起点探测”这个模板。

5. 三套代码模板直接落地：可迁移的哈希表框架

5.1 模板适配原则

哈希表题做得多了你会发现，很多新题本质上只是换了一层皮。与其每道题都从零推导，不如在熟练掌握原理后，把高频套路沉淀成模板。这里我给出三套模板和它们对应的“识别信号”，你背下来之后，做题时可以把题目往几个模板里套。

下面分别给出可以直接修改使用的伪代码级模板。

5.2 模板一：配对互补问题

这个模板的核心是先查后存的顺序，以及“每次只查以前已经处理过的元素”这条边界。无论是两数之和、两数之差，还是四数相加问题，只要你能把当前对象和历史对象之间的关系表达成一个公式，这个模板通常都适用。

python复制# 配对互补模板：适用于 a op b == target 类问题
def solve(nums, target):
    seen = {}
    for i, val in enumerate(nums):
        complement = compute_complement(val, target)  # 根据公式算出要找的历史值
        if complement in seen:
            return build_answer(seen[complement], i)
        seen[val] = i
    return default_answer()

写这套模板的时候，有两点建议。一是把“算互补值的公式”单独抽出来，这样不管题目要的是和、差还是乘积、整除，代码骨架都不用变。二是返回值是下标、是数值、还是数量，决定了 seen 里应该存什么，不要一律存下标。如果题目只要“存不存在”，用集合；如果要计数，用字典存次数。

5.3 模板二：分组归约问题

分组归约问题可以抽象成三个固定动作：定义 key、选容器、遍历。

python复制from collections import defaultdict

def group_by_key(items):
    groups = defaultdict(list)
    for obj in items:
        key = normalize(obj)          # 核心：设计稳定且区分度足够的 key
        groups[key].append(obj)       # 容器按需变化：list / set / counter
    return list(groups.values())

这里最关键的是 normalize 函数。你可以用排序做归一、用计数数组做归一、用哈希签名做归一，甚至把列表转 tuple 再做归一。一旦 normalize 写错，后面全盘皆输。判断 normalize 写对与否的标准是：自己随便构造几个同类和异类样本，跑一遍看它们是否被正确分到同一组 / 不同组。

5.4 模板三：连续探测问题

python复制def max_continuous(items):
    s = set(items)
    res = 0
    for x in s:
        # 只从没有前驱的点启动探测
        if x - 1 in s:
            continue
        y = x
        while y + 1 in s:
            y += 1
        res = max(res, y - x + 1)
    return res

这个模板最容易被错误修改的点是外层遍历对象。如果你一不小心遍历的是原数组而不是集合，并且原数组包含大量重复元素，就会造成重复启动 while。其实把这一行写成 for x in set(items) 也完全可以，重点就是迭代器访问的集合里没有重复元素。

5.5 模板使用的常见误区

模板不是背了就完事，我见过很多人把模板套错，这里列几个高频错误。

其一，把配对模板用在需要“最后才统一处理历史”的题上。比如题目要求找两个数乘积最大，或者要找目标值时，有时需要先统计所有数的频次再遍历，因为它可能涉及同一个数用两次的合法性判断。其二，分组模板里用了可变对象当 key，比如 Python 里直接拿 list 当 dict 的 key 会直接抛 TypeError，要先转 tuple 或字符串。其三，连续探测模板忘记了严格意义上的 O(n) 只成立在外层遍历集合这个前提下，遍历数组加上哈希去重并不能保证这个复杂度，因为重复元素会让很多操作白做。

6. 面试实战中的高频追问和翻车现场

6.1 面试官最可能在三个点上追问

第一刀通常砍在复杂度上。你写完代码后，面试官会问“这题时间复杂度多少？空间呢？”注意，如果你写了“哈希表平均 O(1)”但没解释为什么是平均，面试官可能会追问哈希冲突。不用紧张，你按“哈希函数 + 冲突处理 + 扩容均摊”来答就行：哈希表底层通过散列函数把 key 映射到桶，冲突后采用链表或红黑树挂载，扩容时重新分配桶，所以单次操作平均是常数时间，最坏情况是 O(n)。简单一句带过即可，不需要背源码。

第二刀会砍在“你还有没有更优解”。比如两数之和你说用 HashMap 一遍哈希，面试官可能会问“那不用额外空间能解吗？”标准答案是排序 + 双指针，代价是时间升到 O(n log n)，如果题目对空间有限制，这个 trade-off 是值得的。你需要表现出“我知道多种方案，并且能在时间、空间之间做权衡”的意识。

第三刀会砍在场景迁移。比如面试官问“128 题如果把数组改成日期字符串，你怎么处理？”这就是在考察你是否理解题目的骨架。日期字符串不能直接做减法，但可以转成时间戳或者按天编号，本质上还是数字的连续判断。能答到这一层，说明你不是在背题。

6.2 我在面试里见过的高频翻车

写这两题时翻车现场非常统一，我列几个印象深刻的。

翻车一是遍历时修改哈希表。有一个候选人想在 Python 里遍历 dict 的同时删除某些 key，直接 RuntimeError: dictionary changed size during iteration，当场尬住。正确的做法是先收集要删的 key，循环结束后再统一删除，或者用字典推导式生成新字典。

翻车二是在 49 题里用了 set 当 key，忘了 set 本身不可哈希，代码一运行就报错。写成 frozenset 也不行，因为异位词不是“集合元素相同”，而是“每个字符计数相同”，“aabb” 和 “ab” 的字符集合完全一样但明显不是异位词。这类错误说明对 key 要保留的信息量理解不够。

翻车三是 128 题忘记去重就开始 while，导致复杂度过高。比如输入 [1, 1, 1, 1]，不去重的话第一个 1 会推进到长度 1，然后第二个 1 又从头开始推一次，白白做了很多次查询。把输入转成集合再遍历，问题当场消失。

6.3 给你几条刷题阶段的实操建议

如果你目前还处在一道题要抠很久的阶段，我的建议是一次只啃一类模板。比如这个星期专门练华为高频的“两数之和变体”和“子数组前缀和”，下个星期专门练“异位词/同字母词”，再下个星期练“最长连续/区间合并”，效果远好于每天随机刷一道。

刷完之后一定要做一件事：把三题的代码关掉，自己在白板上重新靠记忆写一遍，并且口头解释每一步为什么这么做。面试的时候，口头表达能力往往比代码本身更影响评价。如果你能自然说出“先查后存是为了避免重复使用当前元素”这样的话，面试官会立刻知道你不是背答案。

还有一点小技巧：在本地建一个你自己的代码片段库，把模板汇总起来。等下次遇到类似题目，先打开模板看一眼，再根据题目改 key 的设计和容器的类型。这个习惯不仅能加快刷题速度，也能让你在面试前的快速复习中事半功倍。

我个人刷完这三题后最大的感触是，哈希表不是一种“高级技巧”，而是一种基础思维方式。它教你在处理每个元素时去思考两件事：这个元素需要和什么历史信息产生关联？这个历史信息能不能被设计成一个稳定、高效的 key？把两件事想清楚，哈希表题基本上就能顺下来。最后再分享一个学习技巧：每次遇到能用哈希表解的题目，都额外问自己一句“如果不让我用哈希表，我还能怎么解？”用这个方式逼自己掌握排序、双指针、前缀和等替代思路，才不会被单一套路锁死。