幸运小姐昨天还在链表里折腾虚拟头节点，今天翻开《代码随想录》第六天的任务清单，迎面就是三个字：哈希表。说实话，第一次刷到这里我挺兴奋的，因为哈希表是第一个能让你明显感觉到“空间换时间”威力的数据结构，也是后续无数难题的地基。这一天的题目看起来简单，四道题全是LeetCode上的基础题，但如果你只是照着题解抄一遍，那就亏大了。第六天的真正价值在于帮你建立一套“什么时候该用哈希表、该用哪种哈希结构”的判断直觉，这种直觉后面做三数之和、滑动窗口、LRU Cache的时候全都会用上。
这篇文章写给正在按《代码随想录》路线刷题的人，也写给那些刷了不少题但看到哈希表题目还是凭感觉瞎蒙的人。我会把第六天涉及的核心原理、四道题怎么一步步解、解题过程中最容易踩的坑、以及我自己反复翻车的经验全部拆开讲清楚。你不需要是算法天才，只需要跟着思路走一遍，再把代码亲手敲一遍，基本就能拿下哈希表这个专题的第一层。
1. 第六天到底在学什么：从“找东西”说起
1.1 为什么偏偏是第六天安排哈希表
很多人刷《代码随想录》只盯着题目列表，却忽略了它的章节安排其实暗含了一条非常合理的学习曲线。前几天的内容集中在数组和链表，这两种结构有一个共同点：它们都是“存数据”的容器，存取方式要么靠下标，要么靠指针。到了第六天突然切换到哈希表，很多人会觉得很突兀，其实这是刻意设计的。数组和链表是把数据“存进去”，哈希表则是解决“找出来”的问题。没有前面几天的线性结构打底，你很难理解哈希表到底在优化什么。
另一个原因是，第六天的四道题里，有三道都涉及“判断一个元素在不在集合里”或者“统计元素出现的次数”。这类需求如果用暴力解法处理，复杂度往往是O(n²)，一旦数据量上来直接超时。而哈希表的核心能力就是把“查找一个元素是否存在”这件事从O(n)降到O(1)。第六天的目的很纯粹，就是在你还没被复杂题目折磨之前，先把这个最核心的查找能力练熟。
我个人的理解是，哈希表这一天是整个刷题计划里第一个“转折点”。前五天你练的是怎么遍历、怎么操作指针，从第六天开始，你的思维要从“怎么存”切换到“怎么快速找”。这个思维转换越早完成，后面学双指针、动态规划的时候就越不吃力。
1.2 哈希表的本质：把查找变成一次计算
哈希表的基本原理用一句话概括就是：通过一个哈希函数，把我们要查找的key直接映射到存储数组的某个下标上。这样查找的时候不需要逐个遍历对比，而是直接根据key计算出下标，一次定位到位。这个过程很像你去图书馆找书，如果你知道书的具体编号，就能直接走到对应书架；如果不知道编号，只能一排一排扫过去。
理解了这个本质，你就能明白为什么哈希表的查找是O(1)。它不是在“找”，而是在“算”。一个key进来，哈希函数算出位置，然后直接访问。当然，现实世界没有完美的哈希函数，不同的key可能算出同一个位置，这就是哈希冲突。处理冲突的常见手段有链地址法和开放地址法，无序的哈希表容器底层通常用链地址法解决冲突。这部分原理我在下一节详细展开，这里只需要记住一个结论：哈希表的时间复杂度是平均O(1)，但前提是哈希函数设计合理，负载因子不过高。
第六天的题目不会要求你手写哈希表，语言自带的容器完全够用。但你必须知道底层发生了什么，否则你连“为什么这题用数组而不用set”这种问题都答不上来，更别提面试时手撕哈希表的设计题了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 哈希表的核心机制：冲突、扩容与选用逻辑
2.1 哈希函数与冲突处理
哈希函数的作用是把一个任意类型的key转成一个非负整数下标。对于整数类型，最简单的做法是直接取模；对于字符串类型，常见做法是把字符的ASCII码加权求和再取模。关键点是，哈希函数的输出范围必须落在表的大小范围内，否则访问就越界了。
但无论哈希函数设计得多好，冲突几乎无法避免。业界常用的解决方案有两种。第一种是链地址法，也就是数组的每个槽位存一个链表，冲突的元素挂到同一个链表上。查找的时候先算出下标，再在链表里顺序遍历。这种做法实现简单，unordered_set和unordered_map底层的哈希桶用的就是这种思路。第二种是开放地址法，冲突时往下一个空位放，查找时也沿着同样的探测序列走。这种方法对负载因子更敏感，用得不如链地址法广泛。
还有一个概念必须提，就是负载因子。负载因子 = 元素个数 / 表大小。负载因子越高，冲突概率越大，查找性能越差。所以哈希表在元素数量超过阈值时会自动扩容，重新分配一个更大的表，然后把所有元素重新哈希一遍。这个操作代价很大，但均摊下来每个插入操作仍然是O(1)。你把元素插进unordered_set的时候，它内部可能已经默默扩容好几次了。
这些原理听起来有点绕，但对你做题很有实际帮助。比如你遍历一个超大数组往里塞set的时候，如果提前知道元素数量级，可以在创建容器时预留容量（C++的reserve，Java的初始容量设置），减少扩容次数，实测能省不少时间。这种细节在LeetCode上可能体会不明显，在真实项目和面试手写题里却很有价值。
2.2 数组、set、map三选一，判断标准是什么
第六天题目里，有的用数组，有的用set，有的用map。新手最常问的问题就是这三者到底怎么选。我总结了一套自己的判断逻辑，按顺序问三个问题就能锁定答案。
先问第一个问题：数据的范围是否有限且紧凑？比如题目限定只有小写字母，那就是26个；限定字符集是ASCII，那就是128个。这种情况下，优先用数组。因为数组本身就是一张最极致的哈希表，key直接就是下标，没有任何哈希计算开销，也没有冲突，性能是所有哈希结构中最好的。C++里开一个int[26]清空为0，然后遍历字符串做加减操作就行，比用unordered_map快一个量级。
如果数据范围很大或者不固定，进入第二个问题：是否需要同时存储“key对应的另一个值”？如果只需要判断元素在不在集合里，不需要关联任何额外信息，那用set就够了。比如求两个数组的交集，结果只需要去重后的元素集合，不需要知道出现次数，不需要下标，unordered_set就是最轻量的选择。
如果需要存储关联信息，比如两数之和里每个元素对应的下标，那必须用map。map的每个键值对就是key和value的绑定，能在一个结构里同时解决“查是否存在”和“取出关联数据”两个需求。
再补一个很多人忽略的细节：哈希结构在C++里有unordered_set和set之分，前者无序但平均O(1)，后者有序但O(log n)。刷题默认用unordered版本，除非题目要求输出有序结果。Java里对应的是HashSet和TreeSet，HashMap和TreeMap，同理。这个选择别看不上，真有人用set然后发现顺序不对，卡了半天才发现是红黑树和哈希表的区别。
3. 四道经典题目逐题拆解：从简单到套路成型
3.1 第1题：有效的字母异位词，数组哈希的基本功
题目要求判断两个字符串s和t是不是字母异位词，也就是组成字母相同但顺序可以不同。我见过不少人一上来就排序比较，那两个字符串排序后相等，也能过，但时间复杂度是O(n log n)，而且完全没体现哈希表的精髓。
这题的正解思路很简洁：因为题目明确说了只有小写字母，范围就是a到z共26个，直接开一个长度为26的数组。遍历s时对每个字母对应的下标计数加一，遍历t时减一。最后检查数组里有没有非零值，有就说明两个字符串的字母构成不一样。
为什么用数组而不是map？原因就是我前面说的，范围有限且紧凑，数组就是最高效的哈希表。用unordered_map也能做，但每插入一个键值对都涉及哈希计算和可能的扩容，常数开销大得多。这里其实还隐含着一个优化思路：用统计频率来抵消顺序差异。两个字符串只要每个字母出现的次数一致，就一定是异位词，不需要真的去排列组合。
cpp复制class Solution {
public:
bool isAnagram(string s, string t) {
int record[26] = {0};
for (char c : s) {
record[c - 'a']++;
}
for (char c : t) {
record[c - 'a']--;
}
for (int i = 0; i < 26; i++) {
if (record[i] != 0) {
return false;
}
}
return true;
}
};
这个解法的时间复杂度是O(n)，空间复杂度O(1)，因为数组大小恒定是26。很多题解会说这是“空间换时间”，实际上这里空间代价几乎可以忽略不计。我建议你把这道题背下来，因为它是一种非常经典的“数组哈希”模板，后面遇到“字符串重排”“字符统计”类题目，第一反应就应该是这个方法。
3.2 第2题：两个数组的交集，set的天然去重能力
题目给两个数组，要求返回它们的交集，结果里每个元素必须唯一。这题有个误区：不少新手一看“元素唯一”就想着先排序再手动去重，或者用两层循环暴力加一个标志位，不仅代码丑，复杂度还容易超。
用哈希表的思路就顺畅得多。先遍历第一个数组，把所有元素丢进一个unordered_set里，相当于建立了一张“存在性查询表”。然后遍历第二个数组，每遇到一个元素就去set里查，查到了就是交集成员。但要注意，结果也需要去重，所以不能直接往vector里塞，而是再开一个unordered_set来存结果，最后再转成vector返回。
这里就体现出set和数组的本质区别了。数组的长度是固定的，下标必须是非负整数，而这里的数值范围可能很大，也可能有负数，数组根本没法直接用。set的好处是不关心具体范围，也不关心正负，只要类型能算哈希就行。所以选set不是因为set更高级，而是因为数组在这个场景下根本不适用。
cpp复制class Solution {
public:
vector<int> intersection(vector<int>& nums1, vector<int>& nums2) {
unordered_set<int> result_set;
unordered_set<int> nums_set(nums1.begin(), nums1.end());
for (int num : nums2) {
if (nums_set.find(num) != nums_set.end()) {
result_set.insert(num);
}
}
return vector<int>(result_set.begin(), result_set.end());
}
};
时间复杂度和空间复杂度都是O(n + m)。这里有个我踩过的坑：如果题目允许重复元素怎么办？那就是另一道题了（LeetCode 350）。349和350的差别就在去不去重，一旦看错题目，全盘皆输。所以读题的时候第一件事就是确认“输出是否需要去重”。
3.3 第3题：快乐数，用set破解“死循环”陷阱
快乐数的定义是：对于一个正整数，每一次将该数替换为它每个位置上的数字的平方和，重复这个过程直到变成1，如果能变成1就是快乐数，如果陷入无限循环就不是。这题的难点不在计算平方和，而在于怎么判断“无限循环”。
数学上有个事实：如果是非快乐数，这个变换过程一定会进入一个循环，而且循环里的数字是固定的几个数。网上有些题解直接判断“如果得到4就返回false”，因为4确实会进入4、16、37、58、89、145、42、20这个循环。但这属于记结论的解法，不够通用，而且面试时你未必记得住这些数字。
更稳妥的做法是使用set记录过程中出现过的每个数。如果某个数重复出现，说明已经进入循环，直接返回false；如果某次计算结果是1，返回true。为什么set能解决这个问题？因为set就是用来判断“元素是否曾经出现过”的标准工具，这正好回到哈希表的核心能力上。
cpp复制class Solution {
public:
int getSum(int n) {
int sum = 0;
while (n) {
int digit = n % 10;
sum += digit * digit;
n /= 10;
}
return sum;
}
bool isHappy(int n) {
unordered_set<int> seen;
while (n != 1) {
if (seen.find(n) != seen.end()) {
return false;
}
seen.insert(n);
n = getSum(n);
}
return true;
}
};
注意这里有一个隐蔽的细节：while循环的条件是n != 1，循环体里先判断n是否出现过，再插入，最后计算下一个数。这个顺序不能乱。如果先插入再判断，会把初始的n误判成“曾经出现过”，导致错误结果。而且这里判断的是当前的n而不是计算后的sum，很多人写顺手了容易写反。
这道题还有一个值得延伸的思考：除了用set，还能不能用快慢指针？如果把它看成链表找环的问题，快慢指针其实也完全可行，而且空间复杂度能降到O(1)。这个思路你可以在刷完第六天之后自己验证一下，因为《代码随想录》后面讲链表和双指针时会多次用到类似思想。
3.4 第4题：两数之和，map才是这道题的真正主角
两数之和是LeetCode的1号题，也是无数人算法之路的第一道题。题目很简单：给定数组nums和一个目标值target，找出数组中两个数之和等于target的下标。暴力解法就是两层循环，O(n²)，数据量一大直接超时。
哈希表的优化思路是：遍历数组的同时，把已经访问过的元素值和它的下标存入哈希表。对于当前元素nums[i]，如果target减去它得到的差值已经在哈希表里，那说明找到了两个数，直接返回。因为需要存储“值”和“下标”两个信息，所以要用unordered_map而不是set或数组。
这里有个非常关键的顺序问题：每次遍历时，应该先查表再插入，还是先插入再查表？正确答案是先查再插。如果你先把当前元素放进map，再查target - nums[i]，那当target等于2倍的nums[i]时，你会把同一个元素自己匹配给自己。比如nums[0]=3，target=6，如果先插入，查差值3时发现map里有3，就返回(0, 0)，但要求是两个不同下标的数，这显然是错的。先查后插能保证差值是“之前出现过的元素”，天然避免了自己匹配自己。
cpp复制class Solution {
public:
vector<int> twoSum(vector<int>& nums, int target) {
unordered_map<int, int> map;
for (int i = 0; i < nums.size(); i++) {
auto iter = map.find(target - nums[i]);
if (iter != map.end()) {
return {iter->second, i};
}
map.insert({nums[i], i});
}
return {};
}
};
这题虽然代码很短，但信息量很大。它教会你两件事：第一，当你需要同时根据key查value时，用map而不是set；第二，哈希表类题目中，插入和查询的先后顺序直接决定结果是否正确。这两个点，第六天的四道题里有两道都踩了相关的坑，后面做滑动窗口、前缀和的时候还会继续遇到。
4. 刷题现场的翻车记录与排查技巧
4.1 数组下标的越界和负数问题
数组哈希最容易被卡的地方就是下标计算。字母异位词那题，记录数组是int record[26] = {0}，遍历字符串时写的是record[s[i] - 'a']++。这里必须确保s[i]是小写字母，否则减出来的数值可能越界。如果题目描述里只说“字符串”，没说“仅包含小写字母”，那就不能直接开26的数组，得先确认字符集范围。我遇到过有人把题目换成包含大写字母的版本，结果没改数组大小，下标变成负值，程序直接崩溃。
另一个常见错误是把字符当成整数直接当下标。比如字符'a'的ASCII码是97，如果你写record[s[i]]++，数组长度就必须是128或者256，否则越界。虽然也能AC，但浪费空间，而且容易在扩展题里翻车。我的习惯是永远先做一次减基准值的操作，让下标从0开始，这样既直观又不容易错。
排查这类问题的方法很简单：在提交前先手动走一遍边界用例。空字符串、单个字符、全是同一个字符，这些极端情况跑通了，基本就稳了。
4.2 暴力解法超时后，先别急着换数据结构
很多人一看到“超时”两个字，第一反应是换更高级的容器，比如从set换到unordered_set，或者从vector换成数组。但实际上，第六天这些题目如果超时，绝大多数情况下不是数据结构的问题，而是算法本身还在用O(n²)的暴力遍历。我见过有人用unordered_set套了两层循环，复杂度还是O(n²)，只是把常数从1.0降到了0.8，该超时还是超时。
正确的排查路线应该是：先算时间复杂度，确认有没有不必要的双重循环；再检查是不是在循环体内重复创建了哈希容器，导致每次迭代都有构造和析构开销；最后才考虑换成性能更好的底层结构。数据结构是在算法复杂度已经达标的前提下做常数优化的，它不能弥补复杂度量级的缺陷。
两数之和这题就是典型。你即使用unordered_map写成两层循环，时间复杂度还是O(n²)，因为哈希表只是存储结构，真正决定复杂度的是你的遍历逻辑。只有改成“边遍历、边查表”的一层循环，复杂度才真正降到O(n)。这是我刷题过程中反复强调的点：先算法，后结构，再微优化。
4.3 两个容器的“查了又插，插了又查”顺序陷阱
哈希表题目里，最隐蔽的错误往往不是语法层面的，而是逻辑顺序问题。两数之和的先查后插前面已经讲过，这里再补充一个类似的场景。快乐数那题，如果你把seen.insert(n)写在if判断之前，那第一轮就会把初始值插入set里，然后第二次循环时发现这个数已经出现过了，直接return false，所有数字都会被判断为非快乐数。这种错误编译器不会报错，逻辑也“能跑通”，就是结果全错，特别恶心。
排查顺序类问题的方法也简单：选一个能一眼看出中间过程的例子，手动模拟一两轮循环。两数之和就选一个target是某个数两倍的用例；快乐数就选4这个数走两步，4变成16，如果顺序反了，你会发现set里出现了4导致误判。这种手动走查看似笨拙，却是定位逻辑顺序错误最快的方式。
如果递归或者循环嵌套层级多，我建议在关键步骤加临时输出，打印出当前遍历到哪一步、哈希表里存了什么、查到了什么。确认逻辑无误后再删掉调试语句。这种做法看似多花几分钟，实际上能省下在错误方向上反复尝试的几个小时。
4.4 使用哈希表时，初始化清空和内存复用的细节
用数组哈希时，初始化是一个容易被忽略的细节。C++里int record[26] = {0}是将数组所有元素初始化为0的写法。但如果你在循环里复用同一个数组，比如要处理多组输入，必须记得每轮处理前重新初始化，否则上一轮的计数会残留，导致结果出错。
用unordered_set和unordered_map时也有类似问题。如果你在一个测试用例里声明了容器，下一轮测试用例开始前要确保容器已经清空。很多在线评测平台是多组测试数据跑同一个进程的，容器不清空会让数据串组。解决方法是尽量在循环体内部声明容器，让它的生命周期跟着每一轮走，自然就不会串数据。
性能方面，如果你频繁地创建和销毁大容器，会带来不小的开销。一个可以优化的点是：如果知道数据量的上限，可以在创建容器时调用reserve或传初始容量参数，减少扩容的复制成本。这种优化在LeetCode上效果可能不明显，但在本地处理大规模数据和面试手写代码时，是个不错的加分点。
5. 第六天刷完之后的进阶方向与个人体会
5.1 从四道题延伸出去：哈希表还能怎么考
第六天的训练让你掌握了哈希表最基础的三板斧：数组做频率统计、set做存在性判断、map做关联记录。但哈希表在真正的算法面试里远不止这些玩法。比如“最长连续序列”这类题，核心思路也是先把数组塞进set，然后只对连续序列的起点往后查；再比如“字母异位词分组”，本质是把每个字符串排序后的结果作为map的key，把原字符串存进对应的value列表。
哈希表也经常和前缀和结合。“和为K的子数组”这类题目，用暴力法是O(n²)，但如果用map记录每个前缀和出现的次数，就能在遍历一次的过程中同时完成查询和统计，复杂度降到O(n)。这个思路比两数之和又进了一步，它不只是“查一个差值”，而是“查一个聚合值出现过的次数”，这是哈希表在计数类场景里的经典应用。
还有一类综合题，比如设计LRU Cache。LRU本身需要O(1)的get和put操作，单纯用map做不到淘汰顺序管理，单纯用链表做不到O(1)的随机访问，必须用map配合双向链表。这类题目虽然难，但底层依赖的能力仍然是你第六天练的这些基本功：知道什么时候用哈希表，知道哈希表存什么、查什么。
5.2 我个人的刷题复盘方法
刷完第六天，我强烈建议你做一次“主题式复盘”。别急着往后冲，先停下来问自己几个问题：哈希表的查找复杂度为什么是O(1)？什么情况下适合用数组代替哈希表？set和map的区别是什么？如果这题面试官要求不用语言自带容器，手写一个最简单的哈希结构，你能写出来吗？
我自己复盘时会做一件事：把当天四道题的解法关键词写下来，比如“字母异位词 -> 数组频次抵消”“两数之和 -> 边遍历边查map”。这也就是把每种题型压缩成一个套路标签。后面刷题遇到新题时，先在脑子里过一遍这些标签，能匹配上就直接套模板，匹配不上再现场想。这个方法帮我减少了很多“一看就会，一写就废”的尴尬时刻。
还有一个习惯是隔天重刷。第六天学完，第七天先不急着看新内容，把四道题重新敲一遍，要求自己不看题解，代码一次通过。如果哪道题卡住了，说明当时只是看懂了，还没真正消化。重刷的这一遍往往比第一遍收获更大，因为大脑需要主动回忆和输出，这个过程才是真正的内化。
5.3 关于刷题节奏的一点建议
最后说点掏心窝的话。很多人在刷题计划进行到第六天时，会开始焦虑，觉得自己进度慢，看到别人一天刷十道就慌了。但《代码随想录》这套路线的安排是有它的逻辑在的：每天不用多，扎扎实实把几道核心题目吃透，比贪多嚼不烂强得多。我当年第六天只刷了这四道题，但每一道都做了至少两遍，还额外写了不同语言的版本。
不要小看这几道基础题。它们在LeetCode上可能只算简单或中等难度，但它们承载的是哈希表这一整个专题的骨架。骨架稳了，后面的树、图、动态规划里那些复杂状态设计，才不会因为基础查找逻辑没想清楚而卡壳。如果你已经刷完第六天，不妨试着把这四道题讲给一个没学过哈希表的人听，能讲明白，才算真的会了。