初赛交卷那一刻，我没有急着关电脑，而是把四道题的代码从头到尾又拖了一遍，脑子里反复回放着几个没把握的边界条件。这届初赛的题量和难度，比我在备赛时预估的要实在得多，尤其是数据库实操那一题，差点在最后关头翻车。这篇总结，想把我从报名、备赛、到实际参赛的完整经历做个复盘，把题型分布、解题思路、踩过的坑和排错经验都整理出来，给准备参加这类IT技能大赛的同学做一个真实参考。
我在备赛前对这类比赛的想象是“学校期末考试那样，考考定义和简单填空”，但真到上手才发现完全不是一回事。它考察的不是死记硬背的理论，而是真正上手编码、操作数据库、在有限时间内完成实际功能的能力。初赛全程在线，限时提交代码，每道题都有明确的输入输出要求和判分标准。如果你正在学编程，想用一场真实的比赛检验自己的代码能力和临场抗压能力，这篇复盘应该能帮你少走不少弯路。
1. 赛前准备：从报名到上考场的完整复盘
1.1 这次初赛到底考什么：赛制与命题方向解读
报名完我才开始认真研究赛制，发现这类IT技能大赛的初赛和常见的算法竞赛还不太一样。算法竞赛往往只拼数据结构和算法，题目清一色是“给你一个数组，求出某某最值”，而这次初赛的命题明显更偏向实际开发场景：有字符串处理、数组计算、数据库查询，还有一道控制台应用的综合题。整体看下来，命题组想验证的是一个学生能不能把编程基础知识用到“接近真实工作”的小任务里。
赛制是限时在线做题，给一个统一入口，登录进去之后能看到所有题目，每道题写好代码后保存提交，在线判题系统会运行你的程序，用预设的输入数据跑一遍，再比对输出结果。判分基本就是黑盒测试：输入什么、程序输出什么、和标准答案是否一致。这一点很关键，意味着你本地写得多漂亮都没用，最终看的是程序在判题机上的运行结果。
我还翻了一下上一届比赛的题目回忆版，发现一个规律：基础题喜欢在字符串、数组、条件分支上做文章，中等题会加一层“时间/空间复杂度”的要求，综合题则喜欢模拟一个迷你业务系统。备赛方向也就很明确了，不需要去啃那种偏竞赛的高级算法，但必须把常用库函数、基本数据结构和SQL写得滚瓜烂熟。
1.2 我的备赛计划与知识清单
我给自己留了四周备赛时间。前两周用来查漏补缺，后两周集中做模拟训练。这里直接列一下我当时的知识清单，基本覆盖了初赛高频考点：
| 考察方向 | 具体知识点 | 掌握程度 |
|---|---|---|
| 编程语言基础 | 变量与类型、循环、分支、数组/集合 | 闭着眼睛能写 |
| 字符串处理 | 遍历、分割、拼接、字符判断 | 熟练使用相关库函数 |
| 输入输出 | 标准输入流、格式化输出、文件EOF判断 | 烂熟于心 |
| 基本算法 | 排序、前缀和、最大子段和 | 能讲清原理并独立实现 |
| 数据库 | 单表查询、聚合、分组、多表JOIN | 能写出正确SQL |
| 综合应用 | 数据读取、逻辑处理、结果输出 | 结构化写代码 |
这里我想强调一个经验：我当时花了一天时间把输入输出的各种写法重新过了一遍。很多人不重视这一点，觉得“无非就是scanf/print”，但比赛里最冤的事就是程序逻辑全对，结果因为读取行末空白符、没有处理空行、输出多了空格而丢分。
备赛期间我每天固定刷三到五道编程题，题目难度不用太高，牛客和力扣的简单/中等题就够用。每周做一次完整的限时模拟，定好2小时闹钟，按真实比赛的流程走一遍，提前适应时间压力。模拟训练最大的好处是让你发现自己的“节奏黑洞”——比如我一开始总在第二题上死磕，导致后面没时间读其他题，这个毛病就是在模拟中暴露出来的。
2. 初赛实战过程全记录
2.1 四道题的分布与整体时间分配
比赛当天是周六下午，登录在线判题系统之后，我先把四道题全部点开扫了一遍，心里大概有了底：第一题是最常规的字符串统计，第二题是数组算法，第三题是数据库查询，第四题是控制台成绩统计工具。整体分值和难度呈梯度上升，前两题属于稳住手感的题，后面两题才拉开差距。
我给自己定的时间策略是这样的：
| 题目 | 类型 | 目标用时 | 说明 |
|---|---|---|---|
| 第1题 | 字符串统计 | 20分钟 | 必须一次写对 |
| 第2题 | 最大子段和 | 30分钟 | 争取满分 |
| 第3题 | SQL查询 | 25分钟 | 写完检查细节 |
| 第4题 | 成绩统计工具 | 35分钟 | 核心得分项 |
| 检查 | 全局复查 | 10分钟 | 边界、格式 |
先做第1题还有一个心态上的原因：刚开场的十分钟脑子最清楚，也最紧张，用一道熟悉的基础题进入状态，比直接啃难题要稳得多。我认识的A同学当时就是先冲第四题，结果前20分钟卡在解析输入格式上，后面反而把容易拿的分丢了，非常可惜。
2.2 逐题实战：从第一题到第四题
第一题是字符串统计：给定一行字符串，分别统计其中的英文字母、数字、空格和其他字符的个数。这题本身没有难度，但如果用字符编码判断，很容易漏掉“大写字母”和“小写字母”都算字母这件事。我用的是遍历加按字符范围判断的方式，几个if分支就能搞定，关键是输出顺序要和题目要求完全一致。
第二题是数组里的经典问题：给出一组整数，求连续子数组的最大和。我在备赛时刚好系统练过这类题目，所以看到题目心里就有数了。这题说白了就是用动态规划里的Kadane思路，遍历一遍数组，边遍历边维护当前累计和，一旦累计和变成负数就直接丢弃重新开始，因为负数前缀只会拖累后续结果。实现很快，但我故意在草稿纸上多算了两个用例，尤其是全负数的情况，确保边界没问题再提交。
第三题是数据库查询，给了学生表student（id、name、class_id）和成绩表score（stu_id、course_name、score），要求查询每个班级每门课程的平均分，并按班级和平均分降序排列。这题需要用到JOIN和GROUP BY，难点不在写SQL，而在于想清楚分组维度。一开始我在草稿上写的是按student_id分组，后来读题发现要的是班级加课程，赶紧改成了双字段分组。
第四题是综合应用：编写一个控制台程序，从标准输入读取多行数据，每行包含一个学生姓名和三门课的成绩，最后输出总分排名前三的学生信息。这道题本质上是在考验代码组织能力：读数据、数据结构设计、排序、格式化输出。我用了面向对象的方式，写了一个Student类，存姓名和总分，再用Collections.sort配合lambda表达式按总分降序排列。这一题我写得最慢，但也是整体得分最扎实的一道题。
3. 核心解题思路与关键代码细节
3.1 算法题的核心思路与边界处理
第二题的最大子段和，值得单独展开讲讲。题目描述通常长这样：给定一个整数数组nums，找到具有最大和的连续子数组，返回其最大和。暴力解法是两重循环枚举所有起点和终点，复杂度O(n²)，对于中等规模的数据也能跑，但拿不到满分。
我当时用的解法是Kadane算法的常见写法，代码贴在下面：
public int maxSubArray(int[] nums) { int cur = 0; int max = nums[0]; for (int x : nums) { cur = Math.max(x, cur + x); max = Math.max(max, cur); } return max; }核心逻辑就一句话：走到当前元素x时，要么把x接到之前的子数组后面，要么从x重新开始一个新子数组。选两者中较大的那个作为“当前子数组和cur”，同时用max记录历史最大值。这个做法的精妙之处在于，它不需要回头寻找起点，一次遍历就能得到答案，时间复杂度O(n)。
真正容易错的地方是边界条件。如果数组里全是负数，比如[-3, -5, -2]，按照“初始化max=0”的写法会返回0，但这明显不对，最大连续子数组应该是-2。所以max的初始值一定要设置成nums[0]而不是0。这个细节我在备赛时踩过坑，比赛时自然就避开了。大家在写这类经典题时，一定要多问自己一句：我的初始值会不会在极端输入下失效？
3.2 数据库题的查询拆解与常见错误
第三题这种“每个班级每门课程的平均分”查询，拆分思路其实很简单，三步走：先连接两张表，再按维度分组，最后在分组基础上做聚合计算。但如果表结构和字段不熟，很容易写出逻辑偏差的SQL。
我当时的写法是：
SELECT stu.class_id, sc.course_name, AVG(sc.score) AS avg_score FROM score sc JOIN student stu ON sc.stu_id = stu.id GROUP BY stu.class_id, sc.course_name ORDER BY stu.class_id ASC, avg_score DESC;这里有两个容易翻车的点。第一是漏掉JOIN，直接把两张表的名字写在FROM后面做隐式连接，虽然结果可能碰巧对，但可读性差，数据量大了还容易产生重复记录。第二是GROUP BY字段和SELECT字段不匹配，比如只按course_name分组，但SELECT里又带上class_id，这种SQL在很多主流数据库上会直接报错，在另一些数据库里则会产生预期外的结果。比赛时判分系统可能不会提示语法错，只会说你输出不对，遇到这种情况第一反应该去检查分组字段。
还有个小细节，题目一般要求输出列名是什么，就用什么列名。比如要求输出avg_score，你在SELECT里写一个AVG(sc.score) AS avg_score，判分系统才认。有些同学本地跑得好好的，但列名和题目要求对不上，最后被扣分，这属于“能跑但没按规格交付”，在真实工作中同样是大忌。
3.3 综合题的代码组织思路
第四题的完整代码我不全贴了，但核心结构值得说说。这类读数据、处理、输出的控制台程序，最常见的错误是“一把梭”：全部逻辑塞在main方法里，变量命名混乱，最后一两行逻辑错了得从头排查。
我写了一个Student类，字段只有name和total，构造方法里直接传入姓名和总分数组，在内部完成累加。
static class Student { String name; int total; Student(String name, int... scores) { this.name = name; for (int s : scores) this.total += s; } }读取部分用BufferedReader逐行读，按多个空格分割后解析姓名和成绩；排序部分直接用现成的排序方法，按total降序排列；输出部分用printf保证格式对齐。整体写下来行数不多，但每个模块各司其职，排查问题时能一眼定位。
这里要提醒一句：综合题最忌讳的是一开始就追求优雅设计。比赛时间有限，先把功能跑通，再回头看代码结构。如果一开始就纠结用什么设计模式、要不要搞个工厂类，大概率会把简单问题复杂化，反而拿不到分。
4. 初赛常见问题与排错经验速查
4.1 在线判题环境里最容易翻车的几件事
和本地编译器不同，在线判题系统有它自己的脾气，很多问题其实和算法无关，纯粹是“环境适配”没做好。我总结了这次比赛前后遇到和听说的高频问题：
- 提交的类名和文件名不匹配。Java要求public类名必须和文件名一致，但判题系统一般只认你提交代码里那个public类名，如果复制粘贴时改了类名，直接编译失败。
- 输入读取没吃到全部数据。有些题目的输入有多行，最后一行的末尾可能没有换行符，用hasNextLine可以避免漏读，但hasNext则需要小心。
- 输出多了空格或者少了对齐。判题系统比对的是完整输出，不是“人眼看上去差不多”，所以每个空格、换行都得和标准输出一致。
- 递归栈溢出。如果题目数据范围较大，且你用了递归写法，在线判题可能因为栈限制直接爆栈，建议大范围题目优先用循环替代递归。
我当时在本地用IDE跑得无比顺畅，结果第一次提交提示“输出格式错误”，找了一圈才发现是最后一行的换行输出被我在本地“习惯性”忽略了。这属于典型的本地环境与判题环境不一致，解决方式是备赛时就用命令行方式编译运行，别总依赖IDE的友好处理。
4.2 代码层面最容易被扣分的隐性错误
有些错误在本地小数据量测试下根本不会暴露，但判题系统的测试用例一多，问题就全出来了。我把这类隐性错误整理成了速查表：
| 错误类型 | 典型场景 | 预防方法 |
|---|---|---|
| 数组越界 | 循环条件写成i <= nums.length | 统一用i < nums.length |
| 整数溢出 | 求和、累乘数据超过int范围 | 使用long，必要时用BigInteger |
| 边界输入为空 | 输入第一行就是空串 | 读取后先trim再判空 |
| 排序稳定性 | 总分相同要求按姓名排序但没写次要条件 | 仔细读题，明确优先级 |
| 死循环 | while循环里忘记更新计数器 | 写完检查循环推进变量 |
| 变量污染 | 循环外用了一个临时变量未重置 | 尽量缩小变量作用域 |
我记得最清楚的一次是整数溢出。第2题本身数据范围小不会溢出，但备赛模拟中的一道求和题，我没注意用例数值上限，用int累加直接错了三条用例。从那以后，凡是看到“10的9次方”这样的描述，我默认用long。比赛时这个习惯救了我一回，虽然不一定是本题的考点，但写代码时内心里稳了一截。
4.3 排查与应急节奏：卡住之后的正确动作
比赛里最怕的不是不会写，而是卡在一道题上出不来。我的体会是：一旦一道题连续思考超过20分钟仍无进展，立刻跳到下一题。后面题目通常有更宽松的得分点，而且做完了再回来看这道题，大脑已经跳过那个死胡同，很容易发现之前忽略的条件。
我还习惯在草稿纸上维护一个“剩余时间检查表”：写每道题之前看一次预计用时，提交之前对一下实际用时，偏差超过50%就重新评估策略。这个方法看起来简单，但能有效防止在时间黑洞里越陷越深。说白了，比赛拼的从来不只是会不会，还有在有限时间内拿到最多分数的取舍能力。
5. 赛后复盘：这场初赛最值得记住的三件事
5.1 基础能力才是真正的决定因素
赛后我想明白一件事：这类比赛真正拉分的，往往不是谁掌握了什么高深算法，而是谁的基础更扎实。字符串处理、数组遍历、SQL分组、格式化输出，这些听起来平平无奇的知识点，组合起来就是初赛的全部。很多人总想挑战难题，觉得简单题“没意思”，但考场上的实际情况是，简单题稳拿满分比难题做出部分结果要划算得多。
举个数据，四道题里前两题如果满分拿完，已经占据了基础分值的一半。第三题只要SQL的JOIN和GROUP BY写对，又能拿下一大块。真正让大家拉开差距的，其实是那些“本来能做对但因为粗心被扣分”的细节。
5.2 时间分配是一种竞赛能力
我在备赛第一次模拟时吃了大亏：当时前两道题完美通过，然后卡在第三题上消磨了40分钟，最后第四题草草写了个半成品。那次模拟之后我才意识到，竞赛里的时间分配不是简单的“每道题平均分配”，而是持续动态调整的过程。
这次初赛我换了一种策略：每做完一道题就快速核对一次预期时间和实际时间，并在心里重新估算剩余题目的难度。第三题写完SQL后，我多留了五分钟来反复对比题目要求的输出列名和排序规则，确认无误后提前进入第四题，最终才不至于到交卷前还在赶代码。时间分配这个能力，确实是在一次次模拟里练出来的。
5.3 给下一届选手的实用建议
如果有人明年准备参加这场初赛，我会给出这样一份建议清单：
- 至少做三轮完整限时模拟，不要只刷零散题目；
- 背熟常用函数的签名，包括字符串处理、集合排序、格式化输出；
- 练一套自己的输入读取模板，尤其是高冲突场景下BufferedReader比Scanner稳定得多；
- 数据库题一定要动手在本地数据库跑一遍，光看SQL语法书是记不住的；
- 遇到不理解的题目描述，先看输入输出样例，样例往往比题目文字更直白；
- 赛前准备好记事本和代码片段，不是为了抄，而是为了减少紧张的搜索记忆。
比赛结束后我在回宿舍路上翻了翻手机上存的知识点笔记，发现真正常用的还是那几页最基础的内容。这大概就是这类IT技能大赛有意思的地方：它不负责考倒你，它负责检验你有没有真正把学过的知识变成自己手中的工具。
我个人这段备赛和参赛的经历，最大的收获不是成绩本身，而是逼着自己建立了一套“输入样例先行—边界条件自测—提交前复查”的做题习惯。这个习惯在校招笔试、日常开发里同样管用。如果你也打算报名下一届，别再犹豫了，把基础知识过一遍，找一套模拟题掐着时间做一遍，赛场上的你就已经赢了一半。
