如果你备考过 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 这样的编号也只是一道普普通通的练习题而已。
