穆晶波1. 训练营第六天：从哈希表到双指针的进阶之路
刷题刷到第六天，卡哥（代码随想录作者）把四道题安排在一起，表面看都是“求和”和“查找”类问题，实际上是一次非常典型的算法思维升级训练：先用哈希表解决需要快速查找的问题，再用双指针解决有序数组上的组合问题。
这四道题分别是 454. 四数相加 II、383. 赎金信、15. 三数之和、18. 四数之和。前两道是哈希表的经典应用，后两道是双指针的成名之战。很多人刷完前三道觉得挺顺，到 15. 三数之和 就开始翻车——去重逻辑搞不清楚、边界条件写不对、超时的更是一抓一大把。这篇文章把四道题串联起来讲，重点说清楚为什么要用某种方法，以及每道题真正的坑在哪里。
先说结论：454 和 383 属于“哈希表能暴力解但复杂度爆炸”的题，核心是空间换时间；15 和 18 属于“哈希表能做但去重太痛苦”的题，核心是排序 + 双指针。这两种思路在面试里都很高频，尤其是 15. 三数之和，几乎是中小厂面试手撕算法题目的标配。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 四个题目的底层逻辑：先判断类型再选工具
2.1 暴力解法不可行的真实原因
先说 454. 四数相加 II。题目给你四个长度相同的数组，每个数组取一个数，让四个数的和等于 0，问有多少种组合。最无脑的解法是四层 for 循环，时间复杂度是 O(n^4)。如果每个数组长度是 200，那循环次数是 200 的四次方，也就是 16 亿次，实际跑起来直接卡死。
但是这道题有个特别重要的细节：四个数组是独立的，不像 15 题那样在同一个数组里挑三个数。这意味着什么？意味着我们可以先计算前两个数组的所有两两之和，再计算后两个数组的两两之和，然后看看能不能凑成 0。这就是把四数之和拆成两个两数之和的问题，思路和“两数之和”是一脉相承的。
-
赎金信 就相对简单了。判断 ransomNote 能不能由 magazine 里的字符构成，其实就是统计 magazine 里每个字符出现的次数，再看 ransomNote 里每个字符的需求量能不能被满足。暴力做法是遍历 ransomNote，每次都在 magazine 里查找字符并删除，涉及字符串的频繁操作，效率低不说，代码写出来也很难看。
-
三数之和 是最容易让人心态崩的一道题。前面已经说了哈希表能解但去重太麻烦，你想想看，如果要在数组里找三个数 a + b + c = 0，用哈希表的话，固定一个数然后找另外两个，整个过程要处理完全相同的三元组去重问题，哪怕你想到先排序再用 set 去重，最后的时间复杂度也不理想，而且写起来极其容易漏掉边界条件。
-
四数之和 是 15 的加强版，多套一层循环而已，但剪枝和去重的细节全变了，直接拿三数之和的模板去套，很容易在边界处理上翻车。
2.2 为什么哈希表和双指针成了最优解
这四个题放在一起，有一个很核心的分类标准：问题的本质是判断“存在性”还是求“组合性”。
454 和 383 本质上是存在性问题——某个和是否存在、某个字符是否够用。这类问题天然适合哈希表，因为哈希表的查找是 O(1) 的，用空间换时间非常划算。
15 和 18 本质上是组合性问题——要找出所有不重复的组合。这类问题如果继续用哈希表，你会发现在去重上耗费的心力远超节省下来的时间。而排序 + 双指针的做法，天然把去重逻辑融合在了指针移动的过程中，只要掌握套路，代码写出来不仅干净，而且几乎不会超时。
选对工具等于成功了一半。
3. 哈希表专场：454 和 383 的关键思路与实操细节
3.1 454. 四数相加 II：分组哈希的经典范式
这道题的暴力解法是 O(n^4)，但如果你把四个数组拆成两组，先算 A 和 B 的所有组合和，存进哈希表，再算 C 和 D 的所有组合和，在哈希表里查 -（c + d），复杂度瞬间降到 O(n^2)。代码结构如下：
cpp复制int fourSumCount(vector<int>& nums1, vector<int>& nums2, vector<int>& nums3, vector<int>& nums4) {
unordered_map<int, int> umap;
for (int a : nums1) {
for (int b : nums2) {
umap[a + b]++;
}
}
int count = 0;
for (int c : nums3) {
for (int d : nums4) {
int target = -(c + d);
if (umap.find(target) != umap.end()) {
count += umap[target];
}
}
}
return count;
}
这里有一个新手很容易踩的坑：count 的累加。第一轮循环里，同一个 a + b 的值可能出现多次，所以哈希表的 value 要存的是“出现次数”而不是布尔值或者下标。在第二轮查找时，每找到一次匹配，就要加上该和值出现的总次数，而不是只加 1。我曾经见过有人把这里写成 count++，结果案例一跑就出问题——因为 C 和 D 里可能有多种组合都能凑出同一个目标值。
再补充一个内存优化的思路。如果四个数组长度不一样，怎么分组更好？实践经验是：把数组较长的两个放一组，较短的放另一组，能让哈希表的规模控制在更小的范围内。虽然时间复杂度仍是 O(n^2)，但实际内存占用会更友好。比如一个数组长度是 1000，另一个是 100，你可能希望把两个 1000 的数组放一起先算，这样哈希表最多存 100 万个键值对；反过来的话，小数组之间两两组合只有 1 万个键值对，遍历大数组的时候查找次数却多了很多。实际哪个更优要看数据分布，但核心思路是控制哈希表大小。
3.2 383. 赎金信：字符统计题的暴力优化路线
- 赎金信 的思路非常直接：用一个长度为 26 的数组（因为题目假定只有小写字母）记录 magazine 中每个字母出现的次数，然后遍历 ransomNote，每遇到一个字符就消耗一个计数，如果计数已经归零说明 magazine 中的字符不够用，直接返回 false。
cpp复制bool canConstruct(string ransomNote, string magazine) {
int record[26] = {0};
for (char c : magazine) {
record[c - 'a']++;
}
for (char c : ransomNote) {
record[c - 'a']--;
if (record[c - 'a'] < 0) {
return false;
}
}
return true;
}
这里要提醒一个点：用数组而不是 unordered_map。因为字符集只有 26 个小写字母，数组能用下标直接索引，访问是 O(1) 而且没有哈希函数的开销，写起来也更直观。不要什么题都上手一个 map，能确定范围的数据优先用数组，这是性能优化的基本素养。
另一个小坑是遍历的顺序。有人喜欢先遍历 ransomNote 记录需求，再遍历 magazine 去匹配，这样还得做一个差值比较，逻辑绕了一圈。正确做法是先把“库存”准备好，再检查“需求”，一次遍历搞定。
3.3 哈希表类题目的共性总结
刷完这两道题，你会发现哈希表的解题套路其实非常固定：
- 需要快速判断某个元素是否存在，用哈希表
- 需要记录元素出现的次数，用哈希表（或数组）
- 需要避免重复计算，很多时候也可以用哈希表做缓存
但哈希表不是万能的。15 和 18 就是典型的反例：如果用哈希表，循环套循环本身没问题，问题在于“去重”——也就是怎么保证同一个结果只出现一次。哈希表去重通常依赖先排序，然后用 set 或者判断相邻元素的方式，这会让代码变得非常难写且难以调试。所以遇到“找出所有组合”类的题目，优先想想能不能排序 + 双指针。
4. 双指针专场：15. 三数之和 的完整拆解
4.1 为什么哈希表思路在这里很痛苦
- 三数之和 的要求是：给你一个整数数组 nums，判断是否存在三元组 [nums[i], nums[j], nums[k]] 满足 i != j、i != k 且 j != k，同时还满足 nums[i] + nums[j] + nums[k] == 0。最终返回所有和为 0 且不重复的三元组。
如果用哈希表，典型做法是先固定两个数，然后在哈希表里找第三个数，找到后把三元组丢进一个 set 去重。听起来还行，实际上问题是：排序后依然可能出现同一个元素被多次使用的情况，三元组的顺序会因为指针遍历顺序而不同，去重逻辑分散在代码的各个角落，一不留神就漏掉或者多删。
我见过不下十个人在评论区问同一个问题：“为什么我用哈希表写了，set 也去重了，但还是超时/报错/少解？” 答案很简单：哈希表方案下，为了去重你得排序，排序本身是 O(n log n)，后面查找每个组合你要维护哈希表，还要维护一个结果 set，整个常数项非常大。对于一个中等规模的数组，用双指针能轻松通过，用哈希表版本可能就卡在超时的边缘。
4.2 排序 + 双指针的核心思想
排序 + 双指针的思路是这样的：
- 先把数组排序
- 固定第一个数 nums[i]，然后在 i 之后的范围里用左右指针找两数之和等于 -nums[i]
- 找到后记录结果，然后移动左右指针，同时跳过重复元素
排序的目的有二：一是让重复元素靠在一起，方便去重；二是让双指针能根据当前和的大小向左或向右移动，逐渐逼近目标值。这个思路的时间复杂度是 O(n^2)，外层固定一个数 + 内层双指针遍历。
代码模板如下：
cpp复制vector<vector<int>> threeSum(vector<int>& nums) {
vector<vector<int>> result;
sort(nums.begin(), nums.end());
for (int i = 0; i < nums.size(); i++) {
if (nums[i] > 0) {
break;
}
if (i > 0 && nums[i] == nums[i - 1]) {
continue;
}
int left = i + 1;
int right = nums.size() - 1;
while (left < right) {
int sum = nums[i] + nums[left] + nums[right];
if (sum > 0) {
right--;
} else if (sum < 0) {
left++;
} else {
result.push_back({nums[i], nums[left], nums[right]});
while (left < right && nums[left] == nums[left + 1]) left++;
while (left < right && nums[right] == nums[right - 1]) right--;
left++;
right--;
}
}
}
return result;
}
仔细看这里的两个去重逻辑：
第一个去重是外层 i 的去重：if (i > 0 && nums[i] == nums[i - 1]) continue;，意思是如果当前固定的数和上一个数相同，这次循环直接跳过。为什么是和 nums[i - 1] 比较而不是和 nums[i + 1] 比较？因为你固定 i 的时候，left 从 i + 1 开始，如果和下一个数相同就跳过，那就会漏掉 i 位置的数和其他位置组成的有效组合。
第二个去重是找到一组解之后的去重：记录完 [nums[i], nums[left], nums[right]] 后，要跳过所有和当前 left/right 相同的元素，再移动指针。如果不去重，那么下一个循环依然会算出一模一样的三元组，结果就会出现重复。
这个边界去重逻辑几乎就是三数之和最核心的考点，面试官最喜欢在这里挖坑。你把这两个去重逻辑背下来还不够，需要理解为什么在“这个位置”去重、为什么用“前一个”而不是“后一个”做比较。
4.3 常见的错误写法与调试心得
第一个常见错误是忘记排序。双指针的移动是建立在有序数组上的，如果不排序，left 和 right 该谁移动完全没有依据。
第二个常见错误是把 nums[i] > 0 当成 continue 而不是 break，或者写成了 if (nums[i] >= 0)。其实当 nums[i] > 0 时，后面所有数都比它大，任意三数之和都大于 0，后面的循环没必要继续，直接 break 是性能优化；但如果你只写 continue，后面不会进入 while，因为 left 从 i+1 开始，nums[left]也大于0，sum 一定大于0，while 里 right-- 会一直减到 left，循环结束，虽然结果没错但白白浪费外层迭代。写成 >= 0 的话会把 nums[i]==0 且左指针也为 0 的情况排除掉，比如数组 [0, 0, 0]，此时会被跳过去导致漏解。
第三个问题是忘了在 while (left < right) 内部对 sum == 0 的情况先记录结果再去重、再移动指针。如果你先移动指针再去重，边界处理会变得很麻烦，甚至出现索引越界。
给我的建议是：写完后拿一个经典用例做手跑测试，比如 [-1, 0, 1, 2, -1, -4]。排序后是 [-4, -1, -1, 0, 1, 2]，你能在草稿纸上把 i=0、i=1、i=2 时指针的移动过程完整跑一遍，基本就能确定代码没有大问题。
5. 双指针的延伸：18. 四数之和 的边界处理与剪枝
5.1 外层多套一层循环之后发生了什么
- 四数之和 要求找出所有和为 target 的四元组，target 是一个任意整数（不像三数之和固定为 0）。这导致一个关键差异：剪枝条件不能简单地判断 nums[i] > target 就 break。
在三数之和里，因为 target = 0，排序后只要第一个数大于 0，后面所有组合的和必然大于 0，可以直接剪枝。在四数之和里，如果 target 是负数，比如 target = -10，数组是 [-6, -3, -1, 0, 2, 4]，排序后第一个数是 -6，它大于 target 但和后面几个负数相加完全可能等于 -10。直接用 nums[i] > target 剪枝会把有效解剪掉。
正确写法是至少加上一个限定条件：if (nums[i] > target && nums[i] >= 0) break;。也就是说，只有当当前数已经大于 target 且当前数非负时，后面的数相加不可能再变小，才可以剪枝。
同理，内层第二层循环也要有对应的剪枝逻辑：
cpp复制if (nums[k] + nums[i] > target && nums[k] + nums[i] >= 0) break;
if (nums[k] + nums[i] + nums[right] < target) continue;
第二个剪枝是：如果当前最小的两个数加上整个数组最大的数都小于 target，说明 k 这个位置不适合固定更大的数来增大和（因为双指针是从 nums[k]+nums[i] 开始向中间夹逼的），所以直接 continue 到下一个 k。但要注意这里别 break，因为 k 后面的数可能更大，能让和变大从而满足 target。
双指针内部的逻辑和三数之和几乎一样：
cpp复制int left = j + 1;
int right = nums.size() - 1;
while (left < right) {
long long sum = (long long)nums[i] + nums[j] + nums[left] + nums[right];
if (sum > target) {
right--;
} else if (sum < target) {
left++;
} else {
result.push_back({nums[i], nums[j], nums[left], nums[right]});
while (left < right && nums[left] == nums[left + 1]) left++;
while (left < right && nums[right] == nums[right - 1]) right--;
left++;
right--;
}
}
注意 long long 的使用。四数之和的测试用例里，四个 int 相加可能溢出 int 范围，卡哥的 C++ 版本里做了一处类型转换，我在实际跑的时候确实遇到过因为溢出导致 sum 错乱的问题。用 long long 存储和，再和目标值比较，就安全了。
5.2 与三数之和的差异对照表
说实话，四数之和就是把三数之和的外部循环再加一层。很多网上的题解粗暴地把三数之和的函数封装起来，然后在四数之和里调用，这种做法可以跑通，但面试的时候不太建议。因为面试官一般会问你“复杂度是多少”“能否再优化”，如果你自己没办法把外层循环的剪枝和去重逻辑讲清楚，封装带来的好处就会被扣分。
| 对比项 | 15. 三数之和 | 18. 四数之和 |
|---|---|---|
| 外层循环层数 | 1 层（固定 i） | 2 层（固定 i 和 j） |
| 剪枝条件 | nums[i] > 0 时可以 break | nums[i] > target && nums[i] >= 0 时可以 break |
| 内层循环 | 双指针夹逼 | 双指针夹逼 |
| 去重逻辑 | i 去重 + left/right 去重 | i、j、left、right 四处去重 |
| 复杂度 | O(n^2) | O(n^3) |
| 溢出风险 | 低 | 高，必须用 long long |
实际写四数之和的时候，很多人会漏掉 j 的去重。j 的去重和 i 一样，放在内层循环开始前：
cpp复制if (j > i + 1 && nums[j] == nums[j - 1]) {
continue;
}
这里有个细节是 j > i + 1 而不是 j > 0。因为当 j = i + 1 时，如果 nums[j] 和 nums[i] 相同，这不是重复情况，因为 i 和 j 本来就是两个不同的位置索引；只有 j 在自身遍历路径上出现过相同值，才需要跳过。很多人这里直接写 j > 0 && nums[j] == nums[j-1]，在某些输入下会错误地跳过有效组合。正确的写法要和 i 的去重逻辑对应：都是和前一个位置比较，但不是和前一个索引位置的元素比较。这句话有点绕，写代码的时候一定要多琢磨一下。
5.3 复杂度变化与性能陷阱
四数之和的双指针方案时间复杂度是 O(n^3)。如果数组长度是 200，外层两层循环是 4 万次，内层双指针最大 200 次，最坏情况是 800 万次操作，完全能接受。但如果数组长度到 1000，那就是 10 亿次操作，大概率超时。因此，针对四数之和，如果面试官给出很大的 n，你需要额外思考别的优化策略，比如先预处理两两和，再在有序的两两和数组上用双指针查找，这是另一个思路，哈希表做两数和缓存也能扩展到四数问题，不过去重依旧很痛苦，一般面试的场景下不会考到那么深。
我面试候选人的时候，看到对方能自然说出“去重和剪枝是这题的难点”，基本能确定他是真的写过而不是背的模板。
6. 四道题的横向对比与易错点清单
6.1 四道题解法一览
| 题目编号 | 题目名称 | 核心思想 | 时间复杂度 | 空间复杂度 | 核心难点 |
|---|---|---|---|---|---|
| 454 | 四数相加 II | 分组哈希 | O(n^2) | O(n^2) | 统计次数并累加 |
| 383 | 赎金信 | 数组哈希 | O(n + m) | O(1) | 字符串字符处理细节 |
| 15 | 三数之和 | 排序 + 双指针 | O(n^2) | O(1)（不考虑结果） | 去重逻辑 |
| 18 | 四数之和 | 排序 + 双指针 | O(n^3) | O(1)（不考虑结果） | 剪枝与溢出 |
把这四道题放在同一天刷完，最大的收获不是记住了某一个题的解法，而是意识到一个通用的思考框架：
- 如果问题在多个独立集合里找元素组合，优先考虑哈希表
- 如果问题在同一个集合里找多个元素组合且需要去重，优先排序 + 双指针
- 如果问题只是判断字符/元素的存在与数量，数组能做到就不上哈希表
这个框架在后续刷其他题目时非常有用，比如 49. 字母异位词分组、1. 两数之和、202. 快乐数，都是同一套思路在不同场景下的变形。
6.2 易错点和常见报错速查表
整理一下我在写代码和看评论区时发现的高频代码问题，按出现频率从高到低排列：
| 错误现象 | 可能原因 | 解决方案 |
|---|---|---|
| 三数之和结果里有重复三元组 | left 去重或 right 去重没写完整 | 在 sum == 0 分支里，记录结果后先跳过重复再移动指针 |
| 三数之和结果漏掉某组解 | 外层 i 去重写成了 nums[i] == nums[i+1] | i 的去重应该和前一个元素比较（nums[i] == nums[i-1]） |
| 四数之和内存或者执行超时 | 剪枝条件不完整，导致无效循环过多 | 补上 nums[i] > target && nums[i] >= 0 的 break 条件 |
| 四数之和计算结果异常 | int 溢出 | 用 long long 存储四个数的和 |
| 赎金信返回错误 | 统计顺序反了或者忘了减计数 | 先遍历 magazine 记录可用字符，再遍历 ransomNote 消耗字符 |
| 454 统计数量偏小 | 累加时只加 1 | 累加目标值出现的总次数 |
这些都是真实刷题中极其常见的坑，我在代码随想录训练营的打卡区几乎每天都能看到类似的报错帖。建议每写完一题就把对应的错误记录到自己的笔记里，后续复习时比看知识点还有用。
6.3 关于代码风格的补充建议
这里说一点很多人不在意但面试时很加分的点：在处理这类涉及多指针的题目时，命名要清晰。三个指针如果叫 i、j、k，代码一长起来自己都会看晕。我建议在写双指针时使用 left 和 right，写多指针时使用 i、j 加 left/right，这样阅读代码的人能立刻知道哪个是固定指针、哪个是移动指针。
另外，每次写循环前先把边界条件写在前面，比如先判断 if (nums.size() < 3) return {}。虽然测试用例不一定覆盖到，但这是工程习惯的问题。训练营里很多同学刷题只求通过 LeetCode 的用例，忽略了函数对空数组和极小数组的防御性处理，等到了实际工作代码 review 的时候，这些都是要被挑出来的毛病。
7. 从刷题到面试：四道题背后的考点延伸
7.1 面试官为什么喜欢考三数之和
- 三数之和 是一道非常典型的“一题多考”题目。一个候选人能拿出的解法直接暴露了他的算法功底：只会三重循环的人，说明没有复杂度概念；用哈希表并要求去重的人，说明知道空间换时间但代码能力一般；能写出排序 + 双指针并且把去重讲清楚的人，说明真正理解了数组类问题的常用优化方法。
面试官一般还会追加一个问题：“如果数组是无序的大数据流怎么办？” 这就把考点从静态数组扩展到了流式处理场景，回答“那需要换用滑动窗口或者维护计数信息”可以加分。所以不要只背模板，一定要把思路的演进过程理清楚：暴力 -> 为什么不行 -> 哈希表 -> 为什么去重难 -> 排序 + 双指针，每一步都要有逻辑支撑。
7.2 四数相加 II 在工程中的对应场景
454 题这种“分组哈希”的思路，在实际工程里对应的场景非常多。比如两个服务之间做数据匹配，你有两个数据集，需要找出字段能配对的所有记录。如果直接用嵌套循环，两个数据集各 10 万条记录就是 100 亿次比较，服务器直接崩。这时候就可以先遍历一个数据集建立索引（哈希表），再遍历另一个数据集查找，复杂度降到一个线性级别。这个思路在 MapReduce 的 join 操作、数据库的 hash join 算法里都能找到影子。
当然不是让你在刷算法题的时候硬套工程场景，而是想说明这类题目背后的东西很值得咀嚼。刷题不只是为了面试，本身对思维的训练是实实在在的。
8. 个人实操体会与训练建议
第六天这四道题，我实际跑下来的感受是：454 和 383 属于“会了就很简单”的类型，代码量少、思路清晰，适合作为热身；15 是今天真正的分水岭，能独立把去重逻辑推理清楚的人，基本就掌握了双指针解决组合类问题的核心；18 是 15 的加强应用，多一层循环后剪枝条件的变化能检验你是不是真的理解了为什么这么写。
有些人习惯把代码抄一遍就完事，第三天就忘干净了。我的建议是每个题至少写三遍：
第一遍直接照着题解敲，熟悉代码结构和边界处理；
第二遍关掉题解凭记忆写，卡住的地方就是你的薄弱点，重点标记；
第三遍尝试自己讲给别人听，如果能把这个题为什么这样做、坑在哪里讲清楚，那才是真的掌握了。
我在训练营打卡时还有一个习惯：每道题都额外准备一组自己构造的边界用例。比如三数之和的数组全为 0、四数之和的 target 是负数、赎金信中 magazine 长度小于 ransomNote 等情况。这些用例比 LeetCode 提供的标准测试更能暴露代码的边界问题。
今天这四道题刷完之后，可以给自己出一个附加题想一想：如果四个数组不是独立的，变成同一个数组里的四数之和不能重复取同一个元素，怎么改 454 的思路？这个思路想明白了，你对“双指针”和“哈希表”两个工具的适用边界理解会再上一个台阶。