上机考试中的字符串模式匹配与边界处理实战复盘

1. 写在前面：D3打卡，为什么我会卡在第72小时

先交代下背景。这两天一直围绕“上机”这两个字打转——一边是华为OD的机试备考，一边是复试上机的准备，两个场景都需要在限定时间内、在没有IDE辅助的情况下，靠纯键盘把一道题完整写出来。DHU上机打卡D3，Day 3，算是我给自己定的一个短期强化训练节点。说实话，头两天那叫一个手忙脚乱：在IDE里写得飞起，一进模拟机试环境就大脑空白，连Scanner怎么导包都要想三秒。但今天这一打卡，整体状态终于有点上线了，也踩出不少值得复盘的细节。

这篇文章我不打算写什么励志鸡汤，就把今天实际做了什么、每步怎么想、碰了哪些坑、下次怎么避，原原本本梳理一遍。如果屏幕前的你也在准备华为OD机试、应对考研或保研复试的上机环节，那我这几天的经验大概率对你有参考价值。尤其是我今天做的一道字符串处理相关的真题变形，里面涉及的模式匹配思维，在OD机试里反复出现，复试上机里也经常拿来当开胃菜，值得逐行拆解一遍。

2. 打卡目标拆解：D3这天的核心任务是什么

2.1 从热身到实战的节奏设计

第3天这个节点挺特殊的。头两天我还在“熟悉题型”，从第三天开始才算真正进入“模拟考试”状态。我给自己定的D3任务分三层：

1. 热身层：15分钟，3道基础输入输出题，目标是把Scanner、BufferedReader、字符串切割这些基本功重新焊死在手上。
2. 核心层：约90分钟，2道中高难度题，重点覆盖“字符串模式匹配”和“贪心区间覆盖”两个类型，这是华为OD机试的高频区间。
3. 复盘层：30分钟，把每道题的思路、代码、出错点梳理到本地笔记里，再跑一遍边界测试用例。

这个分配比例不是拍脑袋想出来的。上机考试和平时写项目完全是两回事——它考的不是你“会不会”，而是你在“时间有限、环境陌生、不能查资料”的三重压力下还能不能稳定输出。前两天的教训让我明白：上手就做难题等于自杀，人会慌；一直做简单题又起不到训练效果。第三天正好是找到平衡点的关键窗口。

2.2 为什么第3天开始就要用“无补全模式”

这一趴必须专门拿出来说，因为它是今天状态上线的最大功臣。前两天的练习我都是直接在本地IDE里写，有什么类不会，Tab一敲就出来了，编译错误也提示得清清楚楚。但这种舒适区的代价是灾难性的——我第二天的模拟测试里，一个简单的Arrays.sort()排序我就想了大概一分钟才想起来需要导入java.util.Arrays，这在考试现场就是一个隐形炸弹。

所以D3开始，我做了一个决定：所有练习一律用记事本/在线编辑器裸写，不开代码补全、不依赖编译器自动导包，写完再手动编译。模拟真实机试的输出环境。同时给自己定死了一项纪律：每道题写完必须手写一遍关键API的参数含义，比如substring(beginIndex, endIndex)的endIndex是开区间、split的正则陷阱，光写过一遍和默写过一遍的记忆深度完全不一样。

注意：如果你平时用的IDE是IDEA或VSCode，强烈建议从备考第一天开始就练习裸写代码。至少每练三道题，就要有一道是完全不靠IDE辅助徒手写完的。习惯自动补全之后，你在机试环境里的“第一反应能力”会明显退化，这不是危言耸听。

3. 今天的重头戏：一道真题变形里的模式匹配攻防

3.1 题目背景与题意拆解

今天核心层做的第一道题，是这样一个变形（原题来自某轮OD机试的书面回忆，我调整过细节）：

小明有一个聊天记录的字符串列表，每条记录形如用户名:内容。现在需要根据关键词列表（多个词，不区分大小写）进行过滤，要求输出所有“内容中同时命中了全部关键词”的记录，按原文出现的顺序输出。命中判断时忽略大小写，且关键词之间用空格分隔。如果某条记录没有命中任何一个关键词，不输出；如果所有记录都不满足，输出NONE。

看起来平平无奇对吧？但在实际手撕这道题的时候，它至少埋了三个考基本功的坑：

1. “不区分大小写”的处理，是统一转小写，还是正则里加(?i)标志？
2. “同时命中全部关键词”意味着需要拆词判断，但记录内容里可能包含标点符号，关键词命中是“作为连续子串出现”还是“作为独立单词出现”？
3. 多关键词“同时命中”的顺序问题——关键词在内容里出现的先后顺序有要求吗？本题明确无顺序要求，但很多人在考场上想当然地理解为“按顺序连续匹配”，直接导致思路跑偏。

我一开始就差点被第二点带沟里。题目说的是“命中”，从上下文推测应该是子串匹配——只要该关键词作为字符串的子串出现就算命中，不强制要求前后是空格或标点边界。但有一种很常见的变体是要求“单词边界”，比如搜cat不应该命中category。这两种理解代码实现天差地别，复盘的时候一定要看清原题描述。如果原题没提“独立单词”，就老老实实按子串来。

3.2 第一版实现与翻车现场

看到这道题，我脑子里第一反应是Python的all()配合in操作符一把梭；但在华为OD机试里，用Python当然可以，问题不大，但Java/C++是更主流的选项，我按Java来练。很快写出了第一个版本：

import java.util.*; public class Main { public static void main(String[] args) { Scanner sc = new Scanner(System.in); int n = Integer.parseInt(sc.nextLine()); List<String> list = new ArrayList<>(); for (int i = 0; i < n; i++) { list.add(sc.nextLine()); } String[] keywords = sc.nextLine().split(" "); List<String> ans = new ArrayList<>(); for (String record : list) { String content = record.split(":", 2)[1]; String lower = content.toLowerCase(); boolean hit = true; for (String kw : keywords) { if (!lower.contains(kw.toLowerCase())) { hit = false; break; } } if (hit) { ans.add(record); } } if (ans.isEmpty()) { System.out.println("NONE"); } else { for (String s : ans) { System.out.println(s); } } } }

代码看起来完整，但问题也一堆。第一，keywords数组在切分时只用了空格split(" ")，这在小规模测试里没问题，但如果关键词之间是多个连续空格，或输入行首尾带空格，split(" ")会产生空字符串，后续的contains("")永远为true，这会导致错误命中。第二，题目说的是“聊天记录字符串列表”，如果记录里没有:分割符怎么办？split(":", 2)的结果长度至少是1，万一列表长度为1，取[1]直接数组越界。第三，也是最关键的逻辑隐患——contains做的是子串匹配，如果题目其实要求单词边界，这版代码就是错的。虽然今天这题按子串理解能过，但考场上的模糊题目，应该再多一步假设确认。

第一版跑完自测用例勉强通过，但我不太放心，追加了几个刁钻用例：一条记录内容为空、关键词用大写混合小写、连续多个空格分隔关键词、记录内容包含冒号。果然，第二个用例就崩了——record.split(":", 2)[1]在内容为空时返回空串倒是没崩，但拦截了[0]和[1]的关系；连续多空格关键词用例则直接导致contains判断失效。这轮测试的结论是：任何看起来“没问题”的输入处理，都必须用split的正则帮忙垫一道保险。

3.3 边界加固后的稳定版本

针对翻车点，我改成这样：

import java.util.*; import java.io.*; public class Main { public static void main(String[] args) throws IOException { BufferedReader br = new BufferedReader(new InputStreamReader(System.in)); String line = br.readLine(); // 空行处理 if (line == null || line.trim().isEmpty()) { System.out.println("NONE"); return; } int n = Integer.parseInt(line.trim()); List<String> records = new ArrayList<>(); for (int i = 0; i < n; i++) { String rec = br.readLine(); if (rec != null && !rec.trim().isEmpty()) { records.add(rec.trim()); } } String kwLine = br.readLine(); List<String> keywords = new ArrayList<>(); if (kwLine != null) { // 正则切分：一个或多个空格 for (String w : kwLine.trim().split("\\s+")) { if (!w.isEmpty()) { keywords.add(w.toLowerCase()); } } } List<String> ans = new ArrayList<>(); for (String record : records) { // 只处理包含冒号的记录 int idx = record.indexOf(':'); if (idx < 0 || idx == record.length() - 1) { continue; } String content = record.substring(idx + 1).toLowerCase(); boolean hit = true; for (String kw : keywords) { if (!content.contains(kw)) { hit = false; break; } } if (hit) { ans.add(record); } } if (ans.isEmpty()) { System.out.println("NONE"); } else { for (String s : ans) { System.out.println(s); } } } }

改动点不多，但每一处都是明确对应一个刚才暴露的问题：用indexOf(':')替代简单split，规避了无冒号记录越界；用split("\\s+")替代split(" ")，规避了多空格产生空串；对输入做trim()和空值判断，避免读入脏数据。这套写法，基本就是正式上机时我会直接拍的版本。

如果你在现场碰到类似题，请你至少做到这一步。考场上不急着一口气写完整，先在草稿纸上把输入的边界问清楚：长度范围、是否可能为空、分隔符是空格还是逗号、关键词大小写是否敏感。花两分钟问清楚这些问题，比最后被边界用例卡住强得多。

4. 环境与工具链：DHU上机多久能适应裸写

4.1 从IDE到记事本的不适感

第3天的打卡，一大半时间其实不是在练算法，而是在练“没有IDE的手感”。我发现一个特别有意思的现象：当我在记事本里写代码时，我会不由自主地更小心——变量名取得更完整、空行更多、注释更多，因为我知道没有高亮、没有自动提示，一旦写错一个字母，排错的成本远高于IDE里标红直接告诉我哪里错。这种“被迫仔细”其实是好事，它逼你在写每一行之前先在脑子里预编译一遍。很多上机考试的高分技巧，说白了就是这个：想清楚再落笔，代码一遍成型率高，自然节省大量调试时间。

今天我还特意试了在线编辑器（比如一些OJ的网页版编辑器），体验和本地IDE完全两个世界。字体、缩进、括号匹配都可能不一样，习惯IDEA的炫酷主题之后，突然回到黑白屏会有种“裸奔”的错觉。但我建议你越早适应越好，因为华为OD的机试环境和复试上机的环境，大概率不是你日常用的那套舒服皮肤。

4.2 华为OD机试环境的一些细节

我在准备华为OD机试这块，梳理了几个环境细节，虽然每个平台可能有差异，但底层逻辑接近：

• 编译器版本偏旧：Java 8或11是主流，C++通常是C++11/14。不要在代码里依赖太新的语法特性（比如Java的List.of()或C++的auto在某些环境下是OK的，但std::format之类就不太稳）。
• 代码提交后通常是黑盒评测：看不到详细报错，只有AC、WA、TLE之类的返回。这意味着你不能靠打印调试信息来排查，得在本地把逻辑想清楚。
• 输入数据量可能很大：尽量用BufferedReader而不是Scanner读大量数据；输出尽量用StringBuilder攒起来一次性输出，而不是频繁System.out.println。

这些细节单拎出来都不是决定你能否进面的关键，但它们在模拟考场上积少成多，直接影响你的最终分数。尤其ScannervsBufferedReader，在数据量超过10万行的输入场景下，性能差距可以达到数倍。平时练习时花30秒多写一行BufferedReader，考试时可能帮你省下3分钟的I/O时间，这3分钟够你多调一版动态规划了。

4.3 复试上机与OD机试的关键差异

再聊聊“复试上机”这个场景。经历过的人应该懂，考研复试/保研机试和华为OD机试的侧重点不完全一样：

准备策略也因此不同。OD机试要重点练“快速读懂题目+一次AC”，复试上机反而要多练“把题做对，同时代码结构清晰、注释得体”。像今天这种记录过滤题，在复试上机里如果只是AC了，评卷老师可能还要看你代码是否易读；但在OD里，答案对就完了。所以我现在做练习时，会故意先按OD模式写一版干净利落的，再花时间“美化”一版可供复试参考的代码结构，相当于一份精力两次训练。

提示：如果你既准备OD又准备复试上机，别用两套完全割裂的方案。算法题的核心解题能力是共通的，差异主要在环境和代码风格，把基础打牢比什么都强。但至少提前一个月开始熟悉考试系统，别在考场上被输入输出的格式坑了。

5. 时间分配与做题顺序：今天这份时间表可以抄

5.1 为什么“先写简单题”不是最优策略

大多数人做上机题的习惯是：拿到题，从第一题开始，按顺序做。但我的模拟测验今天给了很明确的反馈——最优策略是按“分值/难度比”排序，先把最好拿的分拿到手。OD机试一般3道题，分值分布可能是100分的基础题、200分的进阶题、300分的压轴题，但难度也会递增。如果你卡在第1题用了40分钟，后面两题的思考时间会被严重压缩。

我今天的顺序是：热身题做了15分钟后，先快速扫描全部题目，判断第2题（字符串关键词过滤）是我最有把握的，就先写它，拿到稳定AC后再回头处理压轴贪心。这样心态上很稳，因为已经有了保底分。复试上机如果只有1~2题，顺序影响不大；但如果有4题，同样建议先扫一遍再动手。

5.2 以45分钟为基准的做题节拍

我给自己定了一个“45分钟一题”的节拍，分成三个15分钟阶段：

• 0~15分钟：读题、理解样例、穷举边界情况、确定算法，不写代码。这15分钟用来在草稿纸上画画输入输出的对应关系，想清楚特殊输入下的预期输出。
• 15~35分钟：写码和基础自测。按照刚才想好的结构，直接产出可编译版本，先跑题目给的样例，再补2到3个自己设计的边界用例。
• 35~45分钟：最终提交前检查，主要是复盘输入读取方式是否高效、输出格式是否和题目严格一致（比如多余空格、换行符）、数组越界风险、整数溢出风险。

这个节拍特别适合OD机试那种有明确单题限时的场景，也适合复试上机中多题并行时的自我节奏管理。不用死板执行，但如果一题写超过60分钟没AC，我的建议是果断切换下一题，不要恋战——上机考试中，把剩余时间浪费在一道顽固的题上，代价往往是后面每一道题都仓促收尾。

5.3 时间记错了的典型教训

今天我还做了个对比测试：同样是字符串过滤题，我在IDE里写第一版用了22分钟，在记事本裸写第二版居然只用了14分钟。差别很大程度上是因为裸写时我不允许自己“边写边想”，而是先想明白再一口气写完整版。这件事让我更相信一句话：写代码的时间和思考的时间是负相关的，思考越充分，写代码越快。

如果你发现自己一道题写了很久，大概率不是手速慢，而是思路里的循环依赖太多——比如边写边改数据结构、边写边决定用什么算法。我刚入门时也这样，写两行觉得用List不行，改Set，再改Map，回头再推翻重写。这种摇摆非常影响考试心态。练习时可以强迫自己：先口头或纸上说出整个流程，再动键盘。

6. 常见问题与排查技巧实录：这些坑我都替你踩过了

6.1 输入格式相关的坑

上机考试第一杀手永远是输入。我整理了一份今天实操验证过的速查表：

这些坑单独看都“不配”被当作算法题，但它们在这个考场上就是能卡你十几分钟。今天的字符串过滤题，我一共跑了5组额外用例，其中3组就是围绕输入格式设计的。练习时多给自己出几组“脏输入”，考场上就不会慌。

6.2 输出格式的细节问题

输出这块最容易被忽视。很多题要求“每条记录一行”，如果你的代码最后多打了一个空行，测评系统可能直接判WA。还有一些题要求输出NONE，但这个关键词是区分大小写的，是NONE不是None也不是none。今天我特意验证了这道题，输出NONE时如果写成None，很多黑盒评测就是错。

建议你在考试时把题目中的输出描述逐字读一遍，甚至可以把“NONE”“YES”“-1”这类关键词复制到草稿纸上，防止自己手滑。平时练习时，写完代码后养成一个习惯：把代码的println部分单独抽出来看一眼，确认和题面要求的字符串完全一致，再提交。

6.3 越界与空集合处理

这题还牵涉另一个高频陷阱：当ans集合为空时，题目要求输出NONE。但如果你直接走空循环，什么都不输出，在评测系统看来就是“输出为空”，等同于WA。这种“空时要有占位输出”的细节，在很多题里都存在，必须刻意检查。另一个越界点是关键词列表为空或记录内容为空，在代码里我增加了对idx < 0 || idx == record.length() - 1的拦截。考场上这类防御性代码不算多余，它救你于无形。

实操心得：我习惯在写完主体逻辑后，专门用一个checkEdge()注释块列出所有边界情况，逐条检查。比如“关键词为空”“内容是空串”“没有匹配记录”“输入带空格”“大小写混合”，每想到一条就补一条测试用例，虽然不保证100%全对，但能把最常见的问题扼杀在提交前。

6.4 时间超限（TLE）的排查思路

上机考试里，TLE很常见。今天我在热身题里就遇到一次——一个简单的字符串全量匹配，数据规模一大，contains套在for循环里性能立刻告急。TLE的排查思路一般有三层：

1. 看是不是I/O瓶颈：大规模数据下，Scanner+split的组合非常吃力，换成BufferedReader+ 手动切分往往立竿见影。今天的过滤题数据规模如果到10万行，Scanner大概率会超时，而我直接用的BufferedReader，稳得多。
2. 看是不是算法复杂度不达标：如果是O(n^2)且n到10的5次方，基本肯定TLE。要往O(n log n)或O(n)上优化。字符串匹配可以用KMP或Trie树，但很多时候题目数据规模没那么大，盲目上高端算法反而增加代码出错概率。
3. 看是不是输出频率问题：如果每行println一次，数据量大时也会成为瓶颈。今天我建议的方式是StringBuilder统一拼接，最后一次性输出。这也是上机考试常用的优化手段。

6.5 头脑空白时的急救方法

这个可能是我今天最有感触的一条。写第一题时我一度大脑空白，连HashMap的put和get顺序都想反了一下。我的急救策略是：先写伪代码，再翻译成真代码。比如先把思路写成中文/英文的自然语言步骤：

1. 读入所有记录 2. 对每条记录，提取冒号后面的内容 3. 把关键词逐个转小写 4. 检查内容是否包含所有关键词 5. 按原有顺序输出

写完这五行，代码结构基本就呼之欲出了。这个方法看起来蠢，但在紧张状态下真的管用。它把“我要写代码”的压力瞬间转成“我只要按清单填空”的执行任务，心理负担小得多。

7. 扩展思考：如何把D3的经验迁移到后续打卡

7.1 从“题量”到“题型覆盖率”的调整

第3天打卡的最大收获不是学会了字符串过滤题本身，而是发现了一件更重要的事：后期训练的重心应该从堆题量转向题型覆盖率。华为OD机试的题目虽然每年在变，但题型基本锁定在模拟、字符串、排序、二分、贪心、DFS/BFS、动态规划、并查集这几大块。复试上机也类似，很多学校都偏好“1个模拟+1个树/图+1个动态规划”的组合。如果你每天打卡都做一样类型的题，就算刷300道，心理上也很难有踏实感。

我打算从第4天开始，每天的3道题刻意选不同大类的题型，并且用表格记录自己每类题的正确率、平均耗时和常见丢分点。这比“今天刷了5题”这种记录方式有用得多。建议你也建一个自己的“题型账本”，每周扫一眼，哪类题正确率低于70%，下一周就重点加练。

7.2 把每道题变成三类题的训练素材

“做一道题等于做三道题”，这个习惯我从今天开始执行。还是拿今天这道字符串过滤题举例：

• 第一层：按子串匹配实现一版，练“最朴素思路”。
• 第二层：改成“关键词按单词边界匹配”，用正则或自定义判断实现一版，练“需求变化的适应能力”。
• 第三层：把“记录有序输出”改成“按命中次数排序输出”或“关键词之间按AND关系/OR关系切换”，练“业务逻辑组合能力”。

这样一道基础题可以延展出很多变体，而你每练一个变体，都是在加强上机考试最核心的能力——快速理解需求并转换成代码。很多人担心题目变化太多，其实万变不离其宗，底层就是这几类基本能力。

7.3 要不要背模板？我的个人看法

有些博主建议把常用算法模板背下来，比如线段树、并查集、Dijsktra的板子。我自己不太喜欢死背，因为一背就会僵化，遇到变体题容易往上套模板而忽略了题目本身的特殊约束。但我确实建议你准备几个“基础骨架”：快读模板、各类容器的遍历写法、二分查找的边界写法、DFS递归的五件套。这些骨架不算模板，更像是一种“肌肉记忆”，可以在考试时省去大量的低级思考时间。

今天的打卡D3，做了两题、踩了五个坑、写了数百行代码，中间一度被边界条件折腾到怀疑人生，但复盘完这些细节，我对下一次上机的把握明显又足了一点。这些东西没法速成，只能靠一次次踩坑、一次次翻车积累。好在打卡这件事的意义就在这里——不是记录自己多努力，而是记录自己每一天比前一天多搞清楚了一点东西。明天D4，我打算继续用裸写模式，把动态规划的基础题型过一遍，有机会再把备忘录和滚动数组的优化对比做一组实测。如果你也在准备上机，不妨试试今天这套流程：先扫题再动手、先想边界再写代码、先写伪代码再翻译成真代码。上手后你会发现自己比想象中稳得多。