如果你备考过 PAT 乙级，应该会和我一样在题库里撞见很多“做起来不难，但第一遍就是拿不到满分”的题目编号。我第一次刷到 1107 这个编号时，还以为是某种压轴题，结果是一道看起来平平无奇的统计模拟题。可恰恰是这类题，把“能写出代码”和“能拿到全分”之间的差距暴露得干干净净。这篇文章我就以 1107 区间最常见的题型为样本，完整拆一遍从读题、写码、提交、查错到复盘的全过程，也把那些评测系统不会明说的边界规则一次讲清楚。适合刚刷题入门、被 PAT 乙级虐过几次但对“为什么错”还摸不着头脑的人。1. 摸清 PAT 乙级的位置：1107 这类题目为什么是“筛”而不是“难”1.1 这不是算法竞赛，是规范编程的基本功测试很多人把 PAT 乙级当成算法竞赛去准备，一上来就研究最短路、动态规划，结果发现题库开头几道题根本不考这些。乙级更像是一场“规范编程”测试：它考察的是你能不能准确理解题面、能不能写出符合输入输出格式的程序、能不能把边界条件处理完整。说白了，它筛查的不是“你会不会高级算法”，而是“你写代码靠不靠谱”。这和实际工程里的 code review 有点像。面试官不会因为你背过多少算法模板就放心，但他看到你能把一个需要 EOF 读入的统计题写得滴水不漏，至少会相信你有基本的交付能力。1107 这档编号的题目，往往就是把样本点塞满边界，用“多一个空格、少一次判断、多一位小数”来淘汰粗心的人。1.2 几乎雷打不动的四类考点我把乙级里出现频率最高的考点做了归类，你可以把这当成备考地图：类别典型特征常见翻车点字符串与文本处理给一串字符，要求拆分、替换、提取忘了处理空串、大小写、换行符简单模拟按规则走完流程，输出中间或最终结果顺序写反、循环边界错位排序与结构体多条记录按某个字段排序比较函数没写稳定、排序字段搞错基础数学与哈希质数、最大公约数、数字频次统计溢出、除零、特殊值漏判1107 这一类题目，按我的经验经常落在“简单模拟 + 统计”的框里。它们不需要复杂算法，时间复杂度连优化都不用怎么考虑，但逻辑分支多、输入格式偶发变化、输出要求极其严格。题库越高频出现这种题，越说明出题人想考的其实是你的“流程控制能力”。1.3 语言选型，决定你后面五场练习的体验PAT 乙级可以用多种语言提交，但选哪种，直接影响你踩坑的频率。如果你还在犹豫，我给出比较实际的建议：C++：最稳妥。cin >> x天然处理任意空白字符，配合while循环读 EOF 非常顺手，性能也完全够。缺点是要自己注意类型和溢出。Python：写起来最快，适合快速验证思路，sys.stdin.read().split()处理整块输入很方便。缺点是如果出题人数据量大到百万级，全量切分可能吃内存。Java：能用，但代码模板长，读入要用BufferedReader手写，多数人使用体验一般。我自己主力是 C++，调试时偶尔用 Python 验证输出。如果你基础较弱，不想在语法上花太多时间，Python 作为起点问题不大；但你要有意识地把每道题都用 C++ 再写一遍，因为考场里求解环境对 C++ 的兼容性和速度都最友好。2. 以一道 1107 号统计题为样本，完整走一遍“题面到提交”2.1 模拟题面（笔者在题库中复刻的典型款式）为了避免大家只知道抽象方法、没有具体抓手，我整理了一个非常接近原题统计类型的复刻版题面。编号无所谓，重点是它的结构几乎概括了乙级“简单模拟”的所有要素：题目描述：从标准输入读入若干个整数，数字个数未知，以 EOF 结尾。请统计其中正数、负数、零的个数，并输出所有正数的平均值。若不存在正数，则平均值输出 0.0。输入格式：若干行，每行包含若干个整数，相邻整数以空格分隔。输出格式：共五行，格式如下： total: 所有数字之和 positive: 正数个数 negative: 负数个数 zero: 零的个数 average: 正数的平均值，保留一位小数这个题看着简单，但请你先别急着写，凡是能第一遍全对的人，一定在写码之前就把下面几个条件想清楚了。2.2 拆题面：把自然语言变成条件分支我拆题面时习惯画一张心理流程图，不落到纸上，但每个分支都要在脑子里过一遍：输入到底有多少行？不知道。所以不能用“先读一个 N，再循环 N 次”的思路，必须循环读取直到文件结束。一行可能有多个数字，也可能有多行，中间有空行。所以不能按行解析为单个整数，要按空格切分后逐个转 int。正数、负数、零三个分支互斥，用if/else if/else，不能写成三个独立if然后不清不楚。平均值只有正数参与计算。如果没有正数，分母就是 0，必须提前判断，否则会出现除零错误或运行时异常。输出格式里的冒号是英文冒号，冒号后面有一个空格，最后一行是保留一位小数的浮点数。这一步看起来像废话，但大多数人丢分就是丢在这里。评测系统不会因为你“逻辑对但输出格式差一点”就给同情分，差一个空格都是格式错误。2.3 第一版代码：Python 版与 C++ 版按照上面的拆解，我直接给两版能提交的代码。先说 Python 版：import sys data = sys.stdin.read().split() if not data: print("NO INPUT") exit(0) total = 0 pos = 0 neg = 0 zero = 0 pos_sum = 0 for token in data: x = int(token) total += x if x > 0: pos += 1 pos_sum += x elif x < 0: neg += 1 else: zero += 1 avg = pos_sum / pos if pos else 0.0 print("total: %d" % total) print("positive: %d" % pos) print("negative: %d" % neg) print("zero: %d" % zero) print("average: %.1f" % avg)C++ 版本如下：#include <iostream> #include <iomanip> using namespace std; int main() { long long total = 0; long long posSum = 0; long long posCnt = 0, negCnt = 0, zeroCnt = 0; long long x; while (cin >> x) { total += x; if (x > 0) { posCnt++; posSum += x; } else if (x < 0) { negCnt++; } else { zeroCnt++; } } double avg = posCnt ? (double)posSum / posCnt : 0.0; cout << "total: " << total << "\n"; cout << "positive: " << posCnt << "\n"; cout << "negative: " << negCnt << "\n"; cout << "zero: " << zeroCnt << "\n"; cout << "average: " << fixed << setprecision(1) << avg << "\n"; return 0; }两版代码的思路完全一致，都依赖“流式读入”而不是“按行读入”。cin >> x会自动跳过空格和换行，sys.stdin.read().split()则把整块输入切成 token，效果相同。这也是这类题最优雅的解法：你根本不用关心输入分了几行。2.4 本地自测样例要覆盖哪几类输入写完代码别急着提交，先建一个input.txt，把下面几组数据往里面填，每测完一组就清空重来：第一组：普通混合数据。5 -2 8 0 3预期输出：total 14，positive 3，negative 1，zero 1，average 5.3。第二组：只有非正数。-1 -2 0 0预期输出：average 必须为 0.0，不能出现除零错误。第三组：跨行且中间有空行。1 2 3 -4预期输出：total 2，positive 3，negative 1，zero 0，average 2.0。第四组：空输入文件。这一组最容易忽略。如果你用某些语言写成“先读 N”，空输入会直接崩溃；上面两版会走提前退出或直接输出统计值，至少不会异常。我习惯把这四组测试写成脚本或者手动依次运行，确定最终输出与预期完全一致后再上评测。可别小看这件事，很多“全错”的提交，复盘时发现就是本地少测了一类边界。3. 从“本地能跑”到“提交正确”，最隐蔽的边界和格式问题3.1 EOF 不是空文件，行尾也不是字符串结尾PAT 这类评测系统统一用标准输入输出交互，程序读不到数据时收到的信号是 EOF，而不是一个空字符串。这就带来两个常见写法错误：有人用while (cin.peek() != EOF)，但peek()在读到最后一个数字后可能返回\n，导致死循环或漏读。有人用for (int i = 0; i < n; i++)去读数据，但题面没说第一行给 n，自然读不满或错位。最不会出问题的写法就是刚才代码里的方式：while (cin >> x)或sys.stdin.read().split()。前者每次读取会自动跳过所有空白字符，后者则把整个文件内容统一切块。这两种方式都对“行数不确定、列数不确定”的题目免疫。3.2 数值范围和溢出：Python 不溢出，C++ 要小心统计题最容易忽略的是数值范围。题目如果没说整数上限，你就得按最坏情况估计。比如 10 万个整数，每个值都接近 1e9，总和就可能达到 1e14，这个量级超过 32 位 int 的范围，必须用long long。还有人会在平均值计算上翻车：(double)(posSum / posCnt)和(double)posSum / posCnt是两个完全不同的结果。前者的 posSum / posCnt 是先做整数除法取整，再转浮点，结果会丢掉小数部分；后者才是先转浮点再除。我把这两行并排贴出来，周围很多初学朋友都中过招。Python 的确不担心整数溢出，但如果你只依赖 Python 的大整数特性，不去思考底层类型区别，换到 C++ 时会非常疼。我建议至少要把每个变量可能的最大值写出来估算一遍，这是工程习惯，不是应试技巧。3.3 输出格式错误：比“答案错误”更难发现的坑评测结果里最讨厌的两个词，一个是“答案错误”，一个是“格式错误”。对大多数新手来说，“格式错误”是更冤的扣分。我总结下来，格式错误常见于这几种情况：多行输出的最后一行末尾多了一个空格，或者缺少换行。大多数系统对行尾空格敏感，对最后是否有换行的敏感度反而不高。冒号写成了中文全角冒号“：”，或者没有在冒号后加空格。浮点数保留小数不生效。C++ 里setprecision(1)如果不加fixed，它限制的是总有效数字位数而不是小数位数，输出可能变成2e+00这类格式，直接算错。多个输出之间用了\t而不是单个空格。我的习惯是：提交前把每行输出都放进文本编辑器，用“显示所有字符”模式检查一遍。把输出样例复制进编辑器，盯着冒号、空格、换行逐字对比。虽然听起来繁琐，但它能消灭至少一半的格式错误。4. 完整排查链路：当一道题从全错到全对，我经历了什么4.1 第一版为什么会全错：一个很常见的复盘样本有一段时间，我连续几道题都出现同一个现象：本地样例明明全过，提交后却几乎全错。仔细复盘第一版代码，根因竟然是“输入读取部分多了个无用的 N”。原题文本里写的是“第一行一个正整数 N，表示接下来有 N 组数据”，我看完第一眼就在脑子里固化成“先读 N，再循环 N 次”，结果那一次的题面其实允许数据以 EOF 结尾。当我按 N 的范围循环后，数据少读一行，累计的统计结果全部错位。这种问题不是算法不会，是读题时把“上一题的框架”硬套到下一题上。我从那次之后给自己立了一条规矩：每次读题，先把输入输出格式逐字划线，尤其注意有没有“以 EOF 结尾”“若干行”“数量不确定”这类词，命中一个就要把固定循环读法改成流式读法。这条规矩在后面的练习里救了我非常多次。4.2 从错误提示反推信息评测系统给的反馈虽然只有几个词，但信息量其实不小。以常见错误类型为例：反馈代表什么优先检查什么答案错误程序能运行，但输出不符合预期逻辑分支、边界值、特殊输入格式错误内容大致对，排版不对空格、换行、全角字符、精度编译错误代码无法编译语法、头文件、类型声明运行超时程序卡死或效率太低死循环、复杂度、输入读法段错误访问了非法内存数组越界、递归爆栈、空指针我曾被一个“运行超时”逼到崩溃，最后发现不是复杂度问题，而是代码里有个while (!cin.eof())加上cin >> x的经典组合，导致最后一次循环多读一次无效数据，在某个用例上进入错误分支死循环。换成while (cin >> x)后立刻解决。所以看到超时不要只想着换算法，先检查读入循环是不是写歪了。4.3 构造边界用例的具体步骤如果你收到的反馈是“答案错误”，而且样例测试全对，不要盲目重写整个逻辑。按下面步骤构造用例，通常很快能定位：最小输入：一个数字、一行、一个正整数，确认基本路径能跑。只有一个特殊值：只给 0、只给负数、只给最大值，检验分支和边界。混合格式：故意把数字分散到多行，中间插入空行和多个连续空格，检验读取方式。数量上限：把数据量拉到题面可能的最大规模，检验超时和内存。无数据：完全不提供输入，程序不能崩溃，输出要符合某种预期。每跑完一个用例，记录实际输出和预期输出，直接比较。大多数“样例过但提交错”的问题，都会在 1、2、5 这三类用例里露馅。4.4 建立自己的“提交快照”习惯我见过很多人在评测系统上反复提交、反复失败，最后连自己在第几版修了什么都不知道。这是非常亏的排查方式。我自己的做法是每提交一版，就在本地注释里写上版本号和改动点，比如：// v1: 初版，while(cin>>x) 统计，样例通过 // v2: 修复正数平均值为 0 时输出错误 // v3: 修复输出 average 未 fixed 导致精度问题这样一旦某个新改动把原本正确的点改坏了，我能立刻翻回上一版对照。评测系统不像本地 IDE 有完整的断点调试，能依赖的工具只有“版本对比”和“输入输出分析”。这个习惯不用花很多时间，但复盘效率能提升一大截。5. 时间分配和做题顺序：用最小成本拿最大正确率5.1 乙级题目的分数结构决定策略真实的 PAT 乙级试卷有不同题量的年份，但整体分布大致是：前面若干题偏简单，后面若干题逐渐增加状态模拟和数据结构的成分。新手最容易犯的错误，是前 20 分钟就把前面的题草草写完，然后用 80 分钟死磕一道难题，最后连检查时间都没有。正确策略永远是：先把简单题、送分题全部拿下，再回头处理难题。因为评测只看最终分数，同一道题不会因为你花 15 分钟还是 60 分钟做出而加分。乙级的通过率分布也说明，大部分人的分数差距集中在“简单题是否一次做对”上，而不是“难题能不能做出来”。5.2 我在模拟练习中使用的固定节奏我在刷完一整个阶段后，形成了一套比较稳定的节奏，供你参考：前 10 分钟：把所有题目快速扫一遍，按“题面理解难度”分成 A、B、C 三档。先做 A 档：输入输出明确、逻辑单一，尽量一次写对。这档题目不需要太多优化，但需要仔细看输出格式。再做 B 档：涉及简单的结构体排序或哈希映射，按部就班实现，不要展开想象去写复杂思路。最后处理 C 档：如果怎么看都有歧义，先写一个暴力版本拿部分分，通过样例后再思考优化。整个过程里，每道题最多给自己 20 分钟。到点还没调通，就先把当前版本提交上去，确保有基础分，再去做别的题。等把所有能拿的分都拿到，再回头补完。这个“先保底分，再冲击满分”的顺序，比全卷从头到尾顺序做要合理得多。5.3 复盘频率和易错清单刷题不复盘，等于白刷。我每个周末会做一次集中复盘，把一周错题的错误类型汇总成一个清单，统计自己最容易在哪一类问题上丢分。我的个人清单前三名常年是：格式精度问题、边界输入识别、读题时漏掉 EOF 描述。把错误频率统计出来后，你会发现自己真正的弱点往往集中在两三个点上。针对性地各找十道同类题专练，效果比盲目刷新题好得多。如果你愿意，甚至可以建一个“易错标记”表格，每次提交前逐项过一遍：检查项是否通过输入以 EOF 结尾还是给定行数数字类型是否足够装下总和空输入是否安全除零或空结果是否有默认输出输出冒号和空格是否与题目一致浮点是否固定保留位数6. 一道题之后，留下来的才是编程能力6.1 建模优先、语法其次写完 1107 这类统计题，我最大的体会是：做题最重要的不是记住一行语法，而是把题面描述翻译成数据结构和流程的能力。比如“若干个整数，以 EOF 结尾”翻译成“流式循环读入”，“正数平均数，无正数输出 0.0”翻译成“条件表达式做除零保护”。这种翻译动作，本质上和写业务需求文档是一个套路。我在实际工作中写程序，也经常遇到“需求描述得模棱两可、输入格式自己想、边界情况没人提”的情况。刷题时培养出来的那种逐字抠细节的敏感度，到工作里会直接转化成对接口文档的敬畏。你可以说这是应试训练，但它确实在锻炼一种通用的工程能力。6.2 后续可以自然扩展开的训练方向如果在 1107 这类题上已经能稳定拿全分，再往下走有几个非常自然的方向：结构体排序：把单值统计升级成多条记录按字段排序，开始接触自定义比较函数。字符串处理：把整数读入换成带大小写、空格、标点的文本处理，练习getline和子串提取。简单哈希：用数组或map统计字符频次，掌握映射思路。栈和队列模拟：模拟括号匹配、排队流程，为复杂模拟题打基础。每换一个方向，都尽量再回头用流式读入、边界用例检查、输出格式对比这套老流程过一遍。你会发现，那些一开始不起眼的习惯，换个题型依然管用。6.3 最后的实战习惯我在写完每道题后，还会额外做一件小事：把题面、我的代码、本地测试结果一起存到同一个文件夹，按日期命名。别小看这个动作，当刷题量超过一百道后，它就是你的私人错题库。你可以随时翻回某个编号，看自己当时的思路和错误，比重新搜索题解高效得多。考试终究会结束，但“把模糊需求变成精确输出”这件事，会一直伴随你的开发生涯。与其追求某一次高分，不如把每道题当成一次流程训练：读题建模、写码实现、边界检查、版本复盘。等你把这一整套动作跑顺了，PAT 乙级 1107 这样的编号也只是一道普普通通的练习题而已。
如果你备考过 PAT 乙级，应该会和我一样在题库里撞见很多“做起来不难，但第一遍就是拿不到满分”的题目编号。我第一次刷到 1107 这个编号时，还以为是某种压轴题，结果是一道看起来平平无奇的统计模拟题。可恰恰是这类题，把“能写出代码”和“能拿到全分”之间的差距暴露得干干净净。这篇文章我就以 1107 区间最常见的题型为样本，完整拆一遍从读题、写码、提交、查错到复盘的全过程，也把那些评测系统不会明说的边界规则一次讲清楚。适合刚刷题入门、被 PAT 乙级虐过几次但对“为什么错”还摸不着头脑的人。1. 摸清 PAT 乙级的位置：1107 这类题目为什么是“筛”而不是“难”1.1 这不是算法竞赛，是规范编程的基本功测试很多人把 PAT 乙级当成算法竞赛去准备，一上来就研究最短路、动态规划，结果发现题库开头几道题根本不考这些。乙级更像是一场“规范编程”测试：它考察的是你能不能准确理解题面、能不能写出符合输入输出格式的程序、能不能把边界条件处理完整。说白了，它筛查的不是“你会不会高级算法”，而是“你写代码靠不靠谱”。这和实际工程里的 code review 有点像。面试官不会因为你背过多少算法模板就放心，但他看到你能把一个需要 EOF 读入的统计题写得滴水不漏，至少会相信你有基本的交付能力。1107 这档编号的题目，往往就是把样本点塞满边界，用“多一个空格、少一次判断、多一位小数”来淘汰粗心的人。1.2 几乎雷打不动的四类考点我把乙级里出现频率最高的考点做了归类，你可以把这当成备考地图：类别典型特征常见翻车点字符串与文本处理给一串字符，要求拆分、替换、提取忘了处理空串、大小写、换行符简单模拟按规则走完流程，输出中间或最终结果顺序写反、循环边界错位排序与结构体多条记录按某个字段排序比较函数没写稳定、排序字段搞错基础数学与哈希质数、最大公约数、数字频次统计溢出、除零、特殊值漏判1107 这一类题目，按我的经验经常落在“简单模拟 + 统计”的框里。它们不需要复杂算法，时间复杂度连优化都不用怎么考虑，但逻辑分支多、输入格式偶发变化、输出要求极其严格。题库越高频出现这种题，越说明出题人想考的其实是你的“流程控制能力”。1.3 语言选型，决定你后面五场练习的体验PAT 乙级可以用多种语言提交，但选哪种，直接影响你踩坑的频率。如果你还在犹豫，我给出比较实际的建议：C++：最稳妥。cin >> x天然处理任意空白字符，配合while循环读 EOF 非常顺手，性能也完全够。缺点是要自己注意类型和溢出。Python：写起来最快，适合快速验证思路，sys.stdin.read().split()处理整块输入很方便。缺点是如果出题人数据量大到百万级，全量切分可能吃内存。Java：能用，但代码模板长，读入要用BufferedReader手写，多数人使用体验一般。我自己主力是 C++，调试时偶尔用 Python 验证输出。如果你基础较弱，不想在语法上花太多时间，Python 作为起点问题不大；但你要有意识地把每道题都用 C++ 再写一遍，因为考场里求解环境对 C++ 的兼容性和速度都最友好。2. 以一道 1107 号统计题为样本，完整走一遍“题面到提交”2.1 模拟题面（笔者在题库中复刻的典型款式）为了避免大家只知道抽象方法、没有具体抓手，我整理了一个非常接近原题统计类型的复刻版题面。编号无所谓，重点是它的结构几乎概括了乙级“简单模拟”的所有要素：题目描述：从标准输入读入若干个整数，数字个数未知，以 EOF 结尾。请统计其中正数、负数、零的个数，并输出所有正数的平均值。若不存在正数，则平均值输出 0.0。输入格式：若干行，每行包含若干个整数，相邻整数以空格分隔。输出格式：共五行，格式如下： total: 所有数字之和 positive: 正数个数 negative: 负数个数 zero: 零的个数 average: 正数的平均值，保留一位小数这个题看着简单，但请你先别急着写，凡是能第一遍全对的人，一定在写码之前就把下面几个条件想清楚了。2.2 拆题面：把自然语言变成条件分支我拆题面时习惯画一张心理流程图，不落到纸上，但每个分支都要在脑子里过一遍：输入到底有多少行？不知道。所以不能用“先读一个 N，再循环 N 次”的思路，必须循环读取直到文件结束。一行可能有多个数字，也可能有多行，中间有空行。所以不能按行解析为单个整数，要按空格切分后逐个转 int。正数、负数、零三个分支互斥，用if/else if/else，不能写成三个独立if然后不清不楚。平均值只有正数参与计算。如果没有正数，分母就是 0，必须提前判断，否则会出现除零错误或运行时异常。输出格式里的冒号是英文冒号，冒号后面有一个空格，最后一行是保留一位小数的浮点数。这一步看起来像废话，但大多数人丢分就是丢在这里。评测系统不会因为你“逻辑对但输出格式差一点”就给同情分，差一个空格都是格式错误。2.3 第一版代码：Python 版与 C++ 版按照上面的拆解，我直接给两版能提交的代码。先说 Python 版：import sys data = sys.stdin.read().split() if not data: print("NO INPUT") exit(0) total = 0 pos = 0 neg = 0 zero = 0 pos_sum = 0 for token in data: x = int(token) total += x if x > 0: pos += 1 pos_sum += x elif x < 0: neg += 1 else: zero += 1 avg = pos_sum / pos if pos else 0.0 print("total: %d" % total) print("positive: %d" % pos) print("negative: %d" % neg) print("zero: %d" % zero) print("average: %.1f" % avg)C++ 版本如下：#include <iostream> #include <iomanip> using namespace std; int main() { long long total = 0; long long posSum = 0; long long posCnt = 0, negCnt = 0, zeroCnt = 0; long long x; while (cin >> x) { total += x; if (x > 0) { posCnt++; posSum += x; } else if (x < 0) { negCnt++; } else { zeroCnt++; } } double avg = posCnt ? (double)posSum / posCnt : 0.0; cout << "total: " << total << "\n"; cout << "positive: " << posCnt << "\n"; cout << "negative: " << negCnt << "\n"; cout << "zero: " << zeroCnt << "\n"; cout << "average: " << fixed << setprecision(1) << avg << "\n"; return 0; }两版代码的思路完全一致，都依赖“流式读入”而不是“按行读入”。cin >> x会自动跳过空格和换行，sys.stdin.read().split()则把整块输入切成 token，效果相同。这也是这类题最优雅的解法：你根本不用关心输入分了几行。2.4 本地自测样例要覆盖哪几类输入写完代码别急着提交，先建一个input.txt，把下面几组数据往里面填，每测完一组就清空重来：第一组：普通混合数据。5 -2 8 0 3预期输出：total 14，positive 3，negative 1，zero 1，average 5.3。第二组：只有非正数。-1 -2 0 0预期输出：average 必须为 0.0，不能出现除零错误。第三组：跨行且中间有空行。1 2 3 -4预期输出：total 2，positive 3，negative 1，zero 0，average 2.0。第四组：空输入文件。这一组最容易忽略。如果你用某些语言写成“先读 N”，空输入会直接崩溃；上面两版会走提前退出或直接输出统计值，至少不会异常。我习惯把这四组测试写成脚本或者手动依次运行，确定最终输出与预期完全一致后再上评测。可别小看这件事，很多“全错”的提交，复盘时发现就是本地少测了一类边界。3. 从“本地能跑”到“提交正确”，最隐蔽的边界和格式问题3.1 EOF 不是空文件，行尾也不是字符串结尾PAT 这类评测系统统一用标准输入输出交互，程序读不到数据时收到的信号是 EOF，而不是一个空字符串。这就带来两个常见写法错误：有人用while (cin.peek() != EOF)，但peek()在读到最后一个数字后可能返回\n，导致死循环或漏读。有人用for (int i = 0; i < n; i++)去读数据，但题面没说第一行给 n，自然读不满或错位。最不会出问题的写法就是刚才代码里的方式：while (cin >> x)或sys.stdin.read().split()。前者每次读取会自动跳过所有空白字符，后者则把整个文件内容统一切块。这两种方式都对“行数不确定、列数不确定”的题目免疫。3.2 数值范围和溢出：Python 不溢出，C++ 要小心统计题最容易忽略的是数值范围。题目如果没说整数上限，你就得按最坏情况估计。比如 10 万个整数，每个值都接近 1e9，总和就可能达到 1e14，这个量级超过 32 位 int 的范围，必须用long long。还有人会在平均值计算上翻车：(double)(posSum / posCnt)和(double)posSum / posCnt是两个完全不同的结果。前者的 posSum / posCnt 是先做整数除法取整，再转浮点，结果会丢掉小数部分；后者才是先转浮点再除。我把这两行并排贴出来，周围很多初学朋友都中过招。Python 的确不担心整数溢出，但如果你只依赖 Python 的大整数特性，不去思考底层类型区别，换到 C++ 时会非常疼。我建议至少要把每个变量可能的最大值写出来估算一遍，这是工程习惯，不是应试技巧。3.3 输出格式错误：比“答案错误”更难发现的坑评测结果里最讨厌的两个词，一个是“答案错误”，一个是“格式错误”。对大多数新手来说，“格式错误”是更冤的扣分。我总结下来，格式错误常见于这几种情况：多行输出的最后一行末尾多了一个空格，或者缺少换行。大多数系统对行尾空格敏感，对最后是否有换行的敏感度反而不高。冒号写成了中文全角冒号“：”，或者没有在冒号后加空格。浮点数保留小数不生效。C++ 里setprecision(1)如果不加fixed，它限制的是总有效数字位数而不是小数位数，输出可能变成2e+00这类格式，直接算错。多个输出之间用了\t而不是单个空格。我的习惯是：提交前把每行输出都放进文本编辑器，用“显示所有字符”模式检查一遍。把输出样例复制进编辑器，盯着冒号、空格、换行逐字对比。虽然听起来繁琐，但它能消灭至少一半的格式错误。4. 完整排查链路：当一道题从全错到全对，我经历了什么4.1 第一版为什么会全错：一个很常见的复盘样本有一段时间，我连续几道题都出现同一个现象：本地样例明明全过，提交后却几乎全错。仔细复盘第一版代码，根因竟然是“输入读取部分多了个无用的 N”。原题文本里写的是“第一行一个正整数 N，表示接下来有 N 组数据”，我看完第一眼就在脑子里固化成“先读 N，再循环 N 次”，结果那一次的题面其实允许数据以 EOF 结尾。当我按 N 的范围循环后，数据少读一行，累计的统计结果全部错位。这种问题不是算法不会，是读题时把“上一题的框架”硬套到下一题上。我从那次之后给自己立了一条规矩：每次读题，先把输入输出格式逐字划线，尤其注意有没有“以 EOF 结尾”“若干行”“数量不确定”这类词，命中一个就要把固定循环读法改成流式读法。这条规矩在后面的练习里救了我非常多次。4.2 从错误提示反推信息评测系统给的反馈虽然只有几个词，但信息量其实不小。以常见错误类型为例：反馈代表什么优先检查什么答案错误程序能运行，但输出不符合预期逻辑分支、边界值、特殊输入格式错误内容大致对，排版不对空格、换行、全角字符、精度编译错误代码无法编译语法、头文件、类型声明运行超时程序卡死或效率太低死循环、复杂度、输入读法段错误访问了非法内存数组越界、递归爆栈、空指针我曾被一个“运行超时”逼到崩溃，最后发现不是复杂度问题，而是代码里有个while (!cin.eof())加上cin >> x的经典组合，导致最后一次循环多读一次无效数据，在某个用例上进入错误分支死循环。换成while (cin >> x)后立刻解决。所以看到超时不要只想着换算法，先检查读入循环是不是写歪了。4.3 构造边界用例的具体步骤如果你收到的反馈是“答案错误”，而且样例测试全对，不要盲目重写整个逻辑。按下面步骤构造用例，通常很快能定位：最小输入：一个数字、一行、一个正整数，确认基本路径能跑。只有一个特殊值：只给 0、只给负数、只给最大值，检验分支和边界。混合格式：故意把数字分散到多行，中间插入空行和多个连续空格，检验读取方式。数量上限：把数据量拉到题面可能的最大规模，检验超时和内存。无数据：完全不提供输入，程序不能崩溃，输出要符合某种预期。每跑完一个用例，记录实际输出和预期输出，直接比较。大多数“样例过但提交错”的问题，都会在 1、2、5 这三类用例里露馅。4.4 建立自己的“提交快照”习惯我见过很多人在评测系统上反复提交、反复失败，最后连自己在第几版修了什么都不知道。这是非常亏的排查方式。我自己的做法是每提交一版，就在本地注释里写上版本号和改动点，比如：// v1: 初版，while(cin>>x) 统计，样例通过 // v2: 修复正数平均值为 0 时输出错误 // v3: 修复输出 average 未 fixed 导致精度问题这样一旦某个新改动把原本正确的点改坏了，我能立刻翻回上一版对照。评测系统不像本地 IDE 有完整的断点调试，能依赖的工具只有“版本对比”和“输入输出分析”。这个习惯不用花很多时间，但复盘效率能提升一大截。5. 时间分配和做题顺序：用最小成本拿最大正确率5.1 乙级题目的分数结构决定策略真实的 PAT 乙级试卷有不同题量的年份，但整体分布大致是：前面若干题偏简单，后面若干题逐渐增加状态模拟和数据结构的成分。新手最容易犯的错误，是前 20 分钟就把前面的题草草写完，然后用 80 分钟死磕一道难题，最后连检查时间都没有。正确策略永远是：先把简单题、送分题全部拿下，再回头处理难题。因为评测只看最终分数，同一道题不会因为你花 15 分钟还是 60 分钟做出而加分。乙级的通过率分布也说明，大部分人的分数差距集中在“简单题是否一次做对”上，而不是“难题能不能做出来”。5.2 我在模拟练习中使用的固定节奏我在刷完一整个阶段后，形成了一套比较稳定的节奏，供你参考：前 10 分钟：把所有题目快速扫一遍，按“题面理解难度”分成 A、B、C 三档。先做 A 档：输入输出明确、逻辑单一，尽量一次写对。这档题目不需要太多优化，但需要仔细看输出格式。再做 B 档：涉及简单的结构体排序或哈希映射，按部就班实现，不要展开想象去写复杂思路。最后处理 C 档：如果怎么看都有歧义，先写一个暴力版本拿部分分，通过样例后再思考优化。整个过程里，每道题最多给自己 20 分钟。到点还没调通，就先把当前版本提交上去，确保有基础分，再去做别的题。等把所有能拿的分都拿到，再回头补完。这个“先保底分，再冲击满分”的顺序，比全卷从头到尾顺序做要合理得多。5.3 复盘频率和易错清单刷题不复盘，等于白刷。我每个周末会做一次集中复盘，把一周错题的错误类型汇总成一个清单，统计自己最容易在哪一类问题上丢分。我的个人清单前三名常年是：格式精度问题、边界输入识别、读题时漏掉 EOF 描述。把错误频率统计出来后，你会发现自己真正的弱点往往集中在两三个点上。针对性地各找十道同类题专练，效果比盲目刷新题好得多。如果你愿意，甚至可以建一个“易错标记”表格，每次提交前逐项过一遍：检查项是否通过输入以 EOF 结尾还是给定行数数字类型是否足够装下总和空输入是否安全除零或空结果是否有默认输出输出冒号和空格是否与题目一致浮点是否固定保留位数6. 一道题之后，留下来的才是编程能力6.1 建模优先、语法其次写完 1107 这类统计题，我最大的体会是：做题最重要的不是记住一行语法，而是把题面描述翻译成数据结构和流程的能力。比如“若干个整数，以 EOF 结尾”翻译成“流式循环读入”，“正数平均数，无正数输出 0.0”翻译成“条件表达式做除零保护”。这种翻译动作，本质上和写业务需求文档是一个套路。我在实际工作中写程序，也经常遇到“需求描述得模棱两可、输入格式自己想、边界情况没人提”的情况。刷题时培养出来的那种逐字抠细节的敏感度，到工作里会直接转化成对接口文档的敬畏。你可以说这是应试训练，但它确实在锻炼一种通用的工程能力。6.2 后续可以自然扩展开的训练方向如果在 1107 这类题上已经能稳定拿全分，再往下走有几个非常自然的方向：结构体排序：把单值统计升级成多条记录按字段排序，开始接触自定义比较函数。字符串处理：把整数读入换成带大小写、空格、标点的文本处理，练习getline和子串提取。简单哈希：用数组或map统计字符频次，掌握映射思路。栈和队列模拟：模拟括号匹配、排队流程，为复杂模拟题打基础。每换一个方向，都尽量再回头用流式读入、边界用例检查、输出格式对比这套老流程过一遍。你会发现，那些一开始不起眼的习惯，换个题型依然管用。6.3 最后的实战习惯我在写完每道题后，还会额外做一件小事：把题面、我的代码、本地测试结果一起存到同一个文件夹，按日期命名。别小看这个动作，当刷题量超过一百道后，它就是你的私人错题库。你可以随时翻回某个编号，看自己当时的思路和错误，比重新搜索题解高效得多。考试终究会结束，但“把模糊需求变成精确输出”这件事，会一直伴随你的开发生涯。与其追求某一次高分，不如把每道题当成一次流程训练：读题建模、写码实现、边界检查、版本复盘。等你把这一整套动作跑顺了，PAT 乙级 1107 这样的编号也只是一道普普通通的练习题而已。