金融隐士力扣打卡到第5天，我给自己安排了两道高频题：找到字符串中所有字母异位词，和为K的子数组。一道是定长滑动窗口搭配字符频次计数的典型题，另一道是前缀和搭配哈希表的入门题。这两题都属于“连续区间计数”这个大方向，但一个窗口长度固定、靠滚动更新状态，另一个窗口长度任意、靠前缀差把区间和问题转化成两个数相减的问题。热题100里它们出现频率都不低，面试中也经常作为“你能不能看出这题不能用滑窗”的试金石。
如果只是看懂题解抄一遍，收获其实很小。真正值钱的是搞清楚：为什么异位词能用固定窗口？为什么和为K的子数组偏偏不能用双指针滑窗？哈希表里到底该存次数还是位置？这篇文章我会把两道题的完整思考路径、Java实现、边界条件和常见的变式都过一遍，尽量让刷题的人能直接落地复用。
1. 这两道题为什么不建议分开刷
1.1 表面上一滑窗一前缀和，底层都在问“某个区间是否满足条件”
先看题目本身。找到字符串中所有字母异位词（LeetCode 438），给定一个字符串 s 和一个字符串 p，要求返回 s 中所有 p 的异位词的起始索引。所谓异位词，就是字符串长度相同、各字符出现次数相同的词，本质是一个排列问题。比如 s = "cbaebabacd"，p = "abc"，结果是 [0, 6]，因为 s 中下标 0 开始的 "cba" 和下标 6 开始的 "bac"，都和 "abc" 拥有相同的字符频次。
和为K的子数组（LeetCode 560），给定整数数组 nums 和整数 k，需要统计连续子数组中和为 k 的子数组个数。比如 nums = [1, 2, 3]，k = 3，结果是 2，因为 [1, 2] 和 [3] 两个连续片段都满足和等于 3。
这两题放一起，很多人第一反应是“一道滑动窗口、一道前缀和”，解法完全不一样。但把抽象层次拉高一层，它们本质上属于同一类问题：怎么快速判断一个连续区间的某些统计值是符合要求的。438 关心的是窗口内的字符频次是否和目标字符串字符频次一致，560 关心的是子数组的元素和是否等于固定值 k。一个是频次状态，一个是数值状态，但都需要在遍历过程中高效维护、高效查询。
1.2 放在同一天刷，能顺便记住一套判断模型
很多人刷题是“一题一题孤立刷”，今天记住滑动窗口模板，明天写了前缀和模板，碰到变形题还是认不出来。我习惯把同类别的题安排在同一天，重点不是各写一遍，而是对比它们的判断条件。
438 之所以能用滑动窗口，关键条件是窗口长度固定为 len(p)。既然长度恒定，滑动时只需要把右边新字符加入窗口、把左边旧字符移出窗口，就能 O(1) 维护当前窗口内的频次状态。560 不行，因为子数组长度不固定，如果试图用左右指针调整窗口，你会发现没有一个清晰的“什么时候收缩窗口”的规则。
看清这个差异之后，以后再遇到“连续”和“计数”关键词的题，你会习惯性先问自己三个问题：
- 区间长度是否固定。
- 窗口对应的统计值是否具有单调性。
- 如果不具备单调性，能不能用前缀差值来去掉“区间长度可变”这个变量。
这三个问题都可以从今天这两道题里得到答案，所以我一直觉得这两题是同一个知识块的上下篇，拆开刷反而少了那层顿悟感。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 字母异位词：从字符频次匹配到定长滑动窗口
2.1 异位词的本质是“字符频次相等”，不是“字符串相等”
先明确一个容易犯错的点：异位词不是要求窗口内字符串和 p 字符串排序后相等，而是每个字符出现的次数都相同，并且总长度相同。比如 p = "abc"，那 "cba"、"bac"、"acb" 这些排列都算，因为它们底层字符数量分布是 a:1, b:1, c:1。判断两个字符串是否是异构，最稳定的方式就是比较长度为 26 的频次数组，不是先排序再 equals，也不是拿 HashSet
如果 p 的字符分布是 a:2, b:1，某个窗口内也是 a:2, b:1，那就认为匹配。所以问题就变成：在 s 中不断截取固定长度 len(p) 的子串窗口，判断窗口的频次数组和 p 的频次数组是否完全相等。
最直接的暴力写法是枚举每个起点 i，取 s.substr(i, i+m) 统计频次比较，每次统计都要遍历 m 个字符，总代价是 O((n-m+1) * m)，这还没考虑数组比较的 26 次循环。当 s 很长或 p 很长时，这个复杂度就会很尴尬。优化的突破口就在于：相邻窗口之间其实只有两个字符发生了变化，左端移出一个，右端加入一个，中间字符的频次根本不用重新统计。
2.2 双频次数组的 Java 实现
固定长度滑窗最直观的写法是用两个数组，一个记录 p 的频次 pcnt，一个记录当前窗口的频次 wcnt，每次滑动后调用 Arrays.equals 比较一次。
java复制public List<Integer> findAnagrams(String s, String p) {
List<Integer> res = new ArrayList<>();
int n = s.length();
int m = p.length();
if (n < m) {
return res;
}
int[] pcnt = new int[26];
int[] wcnt = new int[26];
for (int i = 0; i < m; i++) {
pcnt[p.charAt(i) - 'a']++;
}
for (int i = 0; i < n; i++) {
// 右边字符进入窗口
wcnt[s.charAt(i) - 'a']++;
// 窗口长度超过 m 时，移除左边字符
if (i >= m) {
wcnt[s.charAt(i - m) - 'a']--;
}
// 当前窗口完整覆盖 [i-m+1, i]
if (Arrays.equals(pcnt, wcnt)) {
res.add(i - m + 1);
}
}
return res;
}
建议直接用 Arrays.equals(pcnt, wcnt)，因为数组是引用类型，直接用 == 只会比较两个数组的引用是否相等，不会比较内容。手动写 for 循环比较也可以，但要注意循环范围是 0 到 25，别越界。每个窗口比较 26 次，总复杂度 O(26n)，因为常数很小，LeetCode 上是完全没有问题的。
从代码可以看出来，左端字符什么时候删除很关键。我的写法是在加入当前字符之后，如果 i >= m 才删除 s.charAt(i - m)，这样保证窗口始终只保留最近 m 个字符。比如 i = m 时，窗口会加入 s[m]，然后移除 s[0]，最终覆盖区间 [1, m]；起始下标是 i - m + 1，正好是 1，没毛病。
2.3 变式场景：官方 O(n) 解法的差分计数逻辑
双数组的方式简单直观，但懂行的人会提醒你，还有更“精妙”的写法，思路是只维护一个数组和一个差异变量 diff。diff 的含义是“当前窗口和 p 的频次数组中，有多少个字符的频次还不一致”。每次滑动时，不是完整比较 26 个字符，而是只更新新旧两个字符对 diff 的影响，把整轮比较的时间降成 O(1)，总时间优化到 O(n)。
用 diff 的技巧是初始化时把 pcnt 和 wcnt 的差异算出来。窗口每加入一个新字符 c，就执行 wcnt[c]++；如果之前已经一致，加完之后就会不一致，diff 加一；如果之前差 1，加完之后一致，diff 减一。移除字符时反过来操作。当 diff == 0，说明所有字符的频次都一样，当前窗口就是一个异位词起点。
这个写法确实快一些，但实际笔试中不写也完全能通过。我觉得值得理解但不建议盲目追求这种“炫技”方案，因为在紧张的面试环境下，越是在小处精简的代码越容易写错边界，最后 debug 反而花更久。如果面试官追问“还能不能优化”，你只要能解释 diff 的思想就够了，不需要现场默写出满分版。
2.4 这类题常见的三个坑
第一，先判断 n < m 直接返回空列表。字符串 t 比 p 长或者等长时还好，如果 p 比 s 还长，那 s 里不可能存在 p 的异位词，不判断的话后面启动窗口时可能出现数组越界或异常。
第二，窗口“加入新字符”和“移除旧字符”的顺序要一致。有些写法是先移除再加入，那移除时的下标是 i - m 还是 i - m + 1 就要重新推导，极易出错。这里比较推荐统一流程：每次循环先把当前字符加入窗口，如果窗口超出 m，再移除窗口最左侧字符，最后比较。
第三，如果 p 中包含非小写字母，比如题目改成 ASCII 可打印字符，那数组范围就不能固定 26，应该扩展到 128 甚至 256，否则会下标越界。刷题时表面看是“模板题”，一旦数据范围改动，很多抽象习惯就会崩，最好对这一点有预期。
3. 和为K的子数组：为什么加法数组不能用双指针滑窗
3.1 负数一来，滑动窗口收缩条件就没了
先说我见过的很多初学者反应。看到“连续子数组”“和为 k”，第一反应是滑动窗口，让右指针向右扩展，如果窗口和大于 k 就移动左指针缩小窗口。这个思路在全正数数组里是完全正确的，因为序列全是正数时，窗口越长和越大，具备单调性，可以依据当前窗口和与 k 的比较结果决定指针怎么动。
但 560 的数组里包含负数，这就出大问题了。窗口扩大时，加入一个负数反而会让总和变小；窗口缩小时，丢弃一个负数可能会让总和变大。左右指针不再能通过大小关系决定下一步动作。比如 nums = [-1, 1, -1, 1]，k = 1，如果窗口和已经大于 1，你敢左移指针吗？可能丢掉 -1 后总和变大，反而等于 k 了。单调性不存在，双指针就不成立，这就是为什么不能用滑窗解决。
这个判断将来会反复用到。看到“子数组和”且“元素可能为负数”，第一反应应该是前缀和，而不是滑窗，这个条件反射能帮你避开很多无效思考。
3.2 前缀和把区间和变成两个前缀和相减
假设 pre[i] 表示 nums[0] 到 nums[i-1] 的前缀和，那么 pre[0] = 0，代表空数组的前缀和。nums[j..i] 这个连续区间的和，可以写成 pre[i+1] - pre[j]（这里稍微注意下标习惯，我习惯把前缀和数组长度定义为 n+1，pre[k] 表示前 k 个数之和）。
如果这个区间和等于 k，那么 pre[i+1] - pre[j] = k，移项得到 pre[j] = pre[i+1] - k。
换句话说，我们遍历到某个位置 i 时，想统计有多少个以 nums[i] 结尾的子数组和为 k，只需要看“之前已经出现过的前缀和当中，有多少个等于 pre[i+1] - k”。有多少个等于它，就有多少个起点 j 能和当前终点凑成满足条件的子数组。
这是一个很典型的“通过两数之差反推存在性”的思想，和一个很老的题目非常像：两数之和。两数之和找的是两个数相加等于 target，这里找的是“历史前缀和 + k = 当前前缀和”，本质上就是两数之和问题套在“前缀和数组”上。
3.3 哈希表存的是“前缀和出现次数”，不是“是否存在”
为什么需要哈希表？因为要在遍历的每一步快速知道历史上某个前缀和出现了多少次。用一个 Map<Integer, Integer>，key 保存前缀和值，value 保存该前缀和值已经出现的次数。这里最容易写错的是把 value 当成 boolean 来判断是否出现过，那样会重复计数时失败。
举个例子，nums = [1, -1, 1, -1]，k = 0。前缀和序列是 0、1、0、1、0。前缀和为 0 出现了多次，它意味着从这些位置中间能切出多个和为 0 的连续区间。如果哈希表只记录“出现过”，那第二个 0 出现时，只能知道前面存在过一个 0，却不知道前面其实有两个可以与当前形成合法子数组的历史前缀和。所以必须用次数。
维护的代码非常短，但每一步都值得停下来想清楚：
java复制public int subarraySum(int[] nums, int k) {
Map<Integer, Integer> prefixCount = new HashMap<>();
prefixCount.put(0, 1);
int pre = 0;
int count = 0;
for (int num : nums) {
pre += num;
// 从历史前缀和中寻找 pre - k
count += prefixCount.getOrDefault(pre - k, 0);
// 当前前缀和加入哈希表
prefixCount.put(pre, prefixCount.getOrDefault(pre, 0) + 1);
}
return count;
}
很多人不理解 prefixCount.put(0, 1) 这一行为什么必不可少。看一个最简单的例子：nums = [3]，k = 3。遍历到第一个数时，pre = 3，我们想知道历史中有没有 pre - k = 0。这里的 0 并不仅仅代表空数组前缀，它代表的是“下标 0 之前的那个虚拟前缀”，也就是没有取任何元素时的前缀和。当 pre 等于 3 时，能通过查询 pre - k = 0 找到这个虚拟前缀，说明从数组开头到当前位置的这一整段可以作为合法子数组。如果没有预先放置 0，这个场景就漏掉了，结果会从 1 错成 0。
那为什么不能把 put(pre, ...) 写在 count += ... 之前？这和 k = 0 有关。假设调换顺序，先更新当前前缀和，再查 pre - k。当 k = 0 时，当前元素本身也可能被错误计数。更准确的表述是：由于哈希表会记录当前这个 pre，查询 pre - k 等于 pre，就会把当前空前缀也算进去，凭空多出一个长度为 0 的子数组，导致结果偏大。所以必须强制让每次查询只基于“当前元素之前已经出现过的前缀和”，当前前缀和要等查询结束后再更新。
为了把这个顺序理解死，我建议你手动走一遍 nums = [1, 2, 3]，k = 3的例子：
- 初始 prefixCount = {0: 1}，pre = 0，count = 0；
- 处理 1，pre = 1，查询 pre - 3 = -2，不存在，count = 0；写入 {1: 1}；
- 处理 2，pre = 3，查询 pre - 3 = 0，存在且次数为 1，count = 1；写入 {3: 1}；
- 处理 3，pre = 6，查询 pre - 3 = 3，存在且次数为 1，count = 2；写入 {6: 1}。
最终 count = 2，和预期一致。其中 count 第一次增加对应的区间是 [1,2]，第二次增加对应的区间是 [3]，恰好一个都不漏。
3.4 暴力优化为什么要先做前缀和
如果不提前缀和，直接枚举子数组起点和终点，最直观的写法是三重循环：外层定起点，内层定终点，最内层把区间元素加起来，复杂度 O(n^3)。稍微好一点的是做前缀和数组，枚举起点和终点后用 pre[j] - pre[i] 求区间和，复杂度降到 O(n^2)。在很多场合 O(n^2) 也能过一部分用例，但碰上 n = 10^5 级别就会超时。
这里的核心优化思想是：不再枚举起点，而是固定终点 i，把所有可能的起点都通过“哈希表查历史前缀和”一步解决。这样每个元素只处理一次，时间复杂度 O(n)，空间复杂度 O(n)。面试时如果要求“不使用额外空间”，那就退回到排序？不行，子数组强调连续性，排序会破坏原始顺序，所以 560 基本上做不到 O(1) 额外空间，只能用哈希表或者 O(n^2) 暴力，这点可以提前和面试官说清楚。
4. 同一天刷这两题，值得刻意对比的三件事
4.1 滑窗什么时候能用、什么时候不能用
刷完两道题，一个很直接的收获是对“窗口”概念的边界有了更清晰的判断。窗口能够滑动，本质上需要两个前提之一成立：要么窗口长度固定，加入和移出正好保持窗口长度不变，所以不需要根据某个条件去收缩；要么窗口内某种统计值随区间伸缩具备单调性，可以通过比较统计值和目标值来决定移动哪个指针。
438 属于第一类，窗口长度永远等于 p 的长度，所以只需按固定节奏滚动。560 如果所有数字全为正数，属于第二类，可以用双指针；一旦出现负数，第二类条件不成立，就不能再用滑窗。
日常刷题可以把这个模型抽象为一张简单的判定脑图：看到“子数组/连续区间”关键词，先想区间是否定长；再想元素是否为正；如果都不满足，再看能不能用前缀和。用这个流程去套很多题都会顺手很多。比如 209 长度最小的子数组，因为全是正数，可以用双指针收缩；862 和至少为 K 的最短子数组，因为有负数，双指针失效，必须引入前缀和加单调队列。
4.2 哈希表里存频次还是存次数，取决于你统计的对象
438 和 560 都用到了某种“记录状态再比对”的思路，但记录的对象天差地别。438 直接拿很窄的 int[26] 当哈希表，key 是字符，value 是频次，查询规模固定，用数组比 HashMap 快。560 的 key 是前缀和，value 是前缀和出现次数，查询的是“某个数值历史上出现多少次”。
更进一步，后续你可能还会遇到 560 的变式“求和为 K 的最长子数组长度”。那个问题里哈希表应该存什么？存前缀和第一次出现的位置，而不是出现次数，因为要求最长长度，一个前缀和越早出现越好，之后重复出现就不用更新了。同一个前缀和思想，value 是“次数”还是“最早下标”，是由题目问的是“数量”还是“长度”决定的。这个细节如果自己没做过对比，光靠看题解很容易忽略。
4.3 异位词和前驱题/后续题的关系
438 有一道非常直接的兄弟题：LeetCode 567 字符串的排列，题目问 s2 中是否包含 s1 的某个排列。如果你把 438 的代码写熟了，567 基本是 438 的退化版，只需要在发现第一个异位词时直接返回 true。再往后，LeetCode 30 串联所有单词的子串把“字符”这一层换成“等长单词”，则需要把所有单词按固定长度切分，本质上还是同一种定长滑窗思路。
另一条线是 560 的后续题。LeetCode 523 和 974 问的是“和可被 K 整除的子数组”，做法是把前缀和 mod K 之后的余数放进哈希表，因为只需要关心前缀和对 K 的余数，两个前缀和余数相等就说明它们之间的区间和能被 K 整除。这里要注意负数取余在 Java 里结果是负数，需要统一调整成 (sum % k + k) % k，这些小坑都会在日后的题里冒出来。等刷到这些题，你再回头看今天两道题，会觉得今天是在给后面的整个题族打地基。
5. 实战复盘：我提交时遇到的那些边界条件
5.1 字符串长度和窗口形成条件的细节
438 第一版我写完就踩了个低级错误：没判断 n < m，直接开始遍历。当 p 比 s 长时，m > n，窗口永远无法覆盖完整 p，虽然不会越界，但可能返回错误结果，或者因为后面访问 s.charAt(i - m) 导致负数下标异常。后来我习惯在方法开头先写防御性判断，省得后面 debug。
另一个容易错的地方是窗口左端下标。我用的是 i - m + 1 作为答案加入列表的下标，这个式子成立的前提是窗口覆盖区间 [i - m + 1, i]，也就是说从加入窗口的第 i 个字符开始，窗口内恰好有 m 个字符。在循环刚开始的那几轮，窗口还不完整，但由于 Arrays.equals 不会在窗口不足 m 时误判吗？其实也有可能误判。比如 s 前几个字符的频次恰好和 p 的频次一样，但长度不足 m，理论上不可能是异位词。所以用双数组时最好只在 i >= m - 1 后才做比较，不过如果两个数组比较的是“频次完全相同”，而 p 有 m 个字符，短窗口的某些字符频次可能碰巧和 p 一样，比如 s = "ab", p = "abc"，遍历到 i=1 时，窗口内是 "ab"，pcnt 里 c 是 1，wcnt 里 c 是 0，不会相等，所以安全。但为了避免逻辑混乱，更严谨的写法还是加一个 if (i < m - 1) continue;，不过不加也不影响结果，看个人习惯吧。
5.2 560 中 k 等于 0 时的特殊行为
很多刷题的朋友会在 k = 0 时迷路。如果 k = 0，代码里的查询条件是 pre - 0，也就是在哈希表里找等于当前前缀和的历史出现次数。只要当前前缀和和某个历史前缀和相等，就说明它们之间的元素和是 0，存在一个合法子数组。比如 nums = [1, -1, 0]，k = 0，手动走几个循环就能看到结果会统计到 [1,-1]、[0]、[1,-1,0] 等区间。
这里最容易出问题的还是先查后存的顺序。如果顺序不对，每个前缀和都会和“自己刚被插入的自己”配对一次，导致所有 k = 0 的测试用例结果偏大。我自己第一次写这段代码时就栽在这上面，最后通过 debug 输出每一步 map 内容才发现：当前元素的前缀和还没“站稳”，就被拿来查了一遍，白白多算一个长度为 0 的子数组。
再有一点，当 k = 0 且数组中存在多个相同前缀和时，前缀和出现次数会比实际可配对数量少 1 吗？不会。因为查询发生在当前前缀和入 map 之前，所以当前前缀和不会和自己配对，只有当这个前缀和已经出现过，后续再出现时才会形成一次配对，这正是符合“子数组至少包含一个元素”的要求。
5.3 性能细节和防溢出习惯
438 的双数组方案空间只有两个 int[26]，可以忽略不计。560 的哈希表最坏情况会存 n+1 个不同的前缀和，空间 O(n)，面试里可以说用空间换时间，这是不可避免的。
一个平时不太会注意的点是前缀和可能超出 int 范围。虽然 560 的原始数据范围是 -1000 到 1000，长度 2 * 10^4，前缀和用 int 完全够，但面试官经常会改条件或者问变式，一旦数值范围放大，建议直接用 long 保存前缀和，避免累加时溢出。我在本地写模板时会直接写 long pre = 0，虽然题目里多此一举，但顺手养成的习惯在复杂度压力大的变式题里能救命。
Java 中 HashMap 的 getOrDefault 用法很顺手，但如果同一个前缀和反复出现，put 操作会频繁触发装箱和扩容。数据量小无所谓，数据量大时可以考虑先预估前缀和种类数，用 new HashMap<>(n + 1) 初始化容量，减少扩容次数，这是很多大厂面试官会盯的微优化细节。
5.4 这类题怎么沉淀模板
第 5 天打卡结束时，我给自己留了一张简短的检查表。遇到异位词或固定长度区间匹配问题，优先想频次数组加定长滑窗；遇到连续子数组和、连续区间计数问题，先判断元素是否全为正数，全正则双指针可行，有负数立刻转前缀和加哈希表。每次写完，别急着提交，多问自己一句“我有没有给自己埋了一个边界条件的雷”，比如 n < m、k = 0、数组含 0、前缀和重复出现等。
如果把 LeetCode 热题 100 当作一个完整项目来做，每天两道题的节奏会让“模型识别”能力逐渐长在脑子里。今天这两道题一前一后正好把滑窗和前缀和连成了一条完整的知识链，这比自己零散刷十道题有用得多。