企业官网建设流程全解析

1. 这道题到底在练什么：从第二周编程题看C语言入门的核心门槛

哈工大2020年C语言程序设计精髓这门课，在MOOC平台上一直口碑不错，第二周的编程题算是真正把新手从“能看懂语法”拽到“能写出程序”的分水岭。很多人第一周还觉得挺轻松，printf、scanf照着敲一敲就过了，到了第二周开始出现计算类、分支类、简单循环类的题目，立刻就有人卡住。我当年带过几个刚入门的朋友刷这套题，发现一个规律：卡住的人几乎都不是因为语法不会，而是因为没搞清楚“程序到底在干什么”。

第二周的编程题通常围绕几个核心点展开：变量的定义与类型选择、格式化输入输出的细节、算术运算与类型转换、if-else分支逻辑、以及最基础的while或for循环。题目本身不难，但每道题都埋了坑，比如整数除法和浮点除法的区别、scanf里格式串的写法、边界条件的判断顺序。这些东西在课堂上听一遍觉得懂了，真到OJ上提交，编译错误、答案错误、格式错误轮番上阵。

这篇文章适合两类人看：一类是正在刷这套题、被某个测试点卡住想找思路的；另一类是想系统梳理C语言入门阶段那些“老师没细讲但做题必须会”的实操细节的。我不会直接甩一份答案给你，而是把每类题背后的设计逻辑、常见错误、排查方法拆开讲清楚，让你下次遇到同类问题能自己搞定。

2. 第二周题目的整体设计逻辑与常见题型拆解

2.1 为什么第二周是道坎：从“照着抄”到“自己想”

第一周的题目基本是“输入两个数，输出它们的和”这种直给型，你只要记住scanf和printf的格式就能过。第二周开始变了，题目会给你一个实际场景，比如“计算圆柱体的体积”“判断某一年是不是闰年”“根据成绩输出等级”，你需要自己决定用几个变量、用什么类型、走什么分支。这个转变的本质是从“翻译”变成了“建模”。

我观察过很多初学者的做题过程，他们最大的问题是拿到题目直接开始敲代码，边敲边想，结果写到一半发现变量不够用或者逻辑走不通，又回头改，改来改去把自己绕晕。正确的做法是先花两分钟在纸上或者注释里把思路写清楚：输入是什么、输出是什么、中间需要哪些计算、有没有条件判断、需不需要循环。这个习惯看起来慢，实际上能帮你省下大量调试时间。

第二周的题目还有一个特点：测试用例往往包含边界值。比如求最大值，它会测两个数相等的情况；判断闰年，它会测整百年份。这些边界条件在题目描述里可能只提了一句，甚至没提，但你如果不处理，提交就是答案错误。这不是题目刁难你，而是在训练你写程序时必须考虑的完备性。

2.2 第二周高频题型分类与对应知识点

把第二周的编程题拆开看，基本逃不出下面这几类。我按出现频率和难度排了个序，你可以对照自己的情况看看哪类还不熟。

这四类里面，数值计算和分支判断是第二周的重头戏，循环类有些课程会放到第三周，但哈工大这套课在第二周就会涉及最简单的循环。不管你遇到的是哪一类，底层的思维方式是一样的：先明确数据流，再确定控制流。

2.3 从题目描述到代码的翻译方法论

很多初学者觉得“我看得懂题目，但不知道怎么写成代码”。这个问题本质上是缺少一套翻译规则。我总结了一个三步法，你可以直接套用。

第一步，把题目里的名词变成变量。题目说“输入圆的半径”，你就定义一个变量叫radius；题目说“计算面积”，你就定义一个变量叫area。变量名尽量用英文，别用a、b、c，不然后面自己都忘了哪个是哪个。

第二步，把题目里的动词变成语句。题目说“计算”，对应赋值语句或表达式；题目说“判断”，对应if语句；题目说“重复”，对应循环语句。这一步的关键是不要跳步，题目说“先判断再输出”，你就老老实实先写if再写printf。

第三步，把题目里的条件变成表达式。题目说“如果年份能被4整除但不能被100整除，或者能被400整除”，你就翻译成(year % 4 == 0 && year % 100 != 0) || (year % 400 == 0)。这里要注意运算符优先级，不确定就加括号，括号不嫌多。

这套方法看起来简单，但能帮你避免大部分逻辑错误。我带过的人里面，凡是老老实实按这个流程走的，调试时间至少缩短一半。

3. 核心细节解析：那些老师不讲但做题必踩的坑

3.1 变量类型选择：int还是double，一念之差结果全错

第二周的数值计算题里，最常见的错误就是整数除法。比如题目让你计算“半径为5的圆面积”，有人写int area = 3.14 * 5 * 5;，结果输出78而不是78.5。原因很简单，3.14是浮点数，5是整数，乘出来是浮点数，但你把它赋给int变量，小数部分直接被截断了。

更隐蔽的是两个整数相除。比如计算平均分，你写int avg = sum / count;，如果sum是85，count是2，结果是42而不是42.5。因为C语言里两个int相除，结果还是int，小数部分直接丢掉，不是四舍五入，是直接砍掉。

记住一条铁律：只要涉及除法，先问自己“我需要小数吗”。需要，就把参与运算的至少一个数变成浮点类型，或者把结果变量定义成double。

那什么时候用int，什么时候用double？我的经验是：计数、编号、索引这类“数个数”的场景用int；测量、金额、比例这类“量大小”的场景用double。不确定的时候用double，因为double能表示整数，但int表示不了小数。代价是double占8个字节，int占4个，但在第二周的题目里这点内存差异完全可以忽略。

还有一个坑是float和double的选择。有些题目要求输出保留两位小数，你用float可能因为精度问题在最后一位上出现偏差。比如float f = 1.0 / 3.0;输出可能是0.333333，而double是0.333333333。第二周的题目用double基本不会错，float能不用就不用。

3.2 scanf和printf的格式串：一个字符不对就全盘皆输

scanf的格式串是初学者最容易翻车的地方。最常见的错误是在scanf里写了不该写的东西。比如scanf("%d\n", &n);，这个\n会让程序卡住等你多输入一个非空白字符才继续。很多人调试半天以为是逻辑问题，其实是格式串里多了个换行。

另一个高频错误是忘记取地址符&。scanf("%d", n);编译可能不报错，但运行直接崩溃。因为n的值被当成地址用了，程序试图往一个非法内存位置写数据。这个错误在第二周出现频率极高，因为题目开始要求输入多个变量，写着写着就漏了。

printf这边的问题主要是格式控制符和变量类型不匹配。用%d输出double，结果会是一个莫名其妙的整数；用%f输出int，结果更离谱。第二周题目经常要求“保留两位小数”，正确写法是printf("%.2f", area);，注意是%.2f不是%2f，少了那个点，输出宽度变了但精度没控制。

每次写完scanf，养成习惯检查两件事：格式串里有没有多余的字符，变量前面有没有&。这两条能帮你排除80%的输入问题。

3.3 分支逻辑的顺序陷阱：条件写对了，顺序错了照样错

if-else if-else这种结构，条件的顺序至关重要。最典型的例子是成绩等级判断。如果你这样写：

if (score >= 60) { printf("及格"); } else if (score >= 80) { printf("良好"); } else if (score >= 90) { printf("优秀"); }

一个95分的学生会被判定为“及格”，因为第一个条件就满足了，后面的else if根本不会执行。正确的顺序是从高到低或者从低到高，确保每个分数段只被一个条件捕获。

闰年判断也有类似的顺序问题。题目说“能被4整除但不能被100整除，或者能被400整除”，有人写成：

if (year % 4 == 0) { if (year % 100 != 0) { printf("是闰年"); } } else if (year % 400 == 0) { printf("是闰年"); }

这个逻辑对1900年判断正确（不是闰年），但对2000年就错了。因为2000 % 4 == 0进入第一个分支，然后2000 % 100 != 0为假，直接跳出，永远不会走到else if。正确的写法是把两个条件用逻辑运算符连起来，或者调整嵌套结构。

我个人的习惯是，遇到多条件判断，先在纸上画出所有可能的情况，然后确保每个情况有且只有一个分支能覆盖到。这个步骤花不了两分钟，但能避免大量返工。

3.4 循环的边界控制：差一错误和死循环的根源

第二周涉及的循环通常很简单，比如“求1到100的和”。但就是这种简单循环，也有两个经典坑。

第一个是差一错误。for (int i = 1; i < 100; i++)求的是1到99的和，不是1到100。for (int i = 1; i <= 100; i++)才是对的。这个错误在累加、计数场景里特别常见，因为人脑习惯“小于”而不是“小于等于”。

第二个是循环变量忘记更新。用while写循环时，如果忘了写i++;，程序就死循环了。OJ上死循环的表现是超时，不是答案错误，所以看到超时提示，第一反应就是检查循环有没有退出条件。

// 错误示范：死循环 int i = 1; while (i <= 100) { sum += i; // 忘了 i++ } // 正确示范 int i = 1; while (i <= 100) { sum += i; i++; }

写循环的时候，我习惯在循环体最后一行先写更新语句，再写其他逻辑。这样就不会忘。另外，循环变量尽量在for里面定义，作用域清晰，不容易和外面的变量冲突。

4. 完整实操流程：从读题到提交的标准化动作

4.1 读题阶段：把自然语言翻译成数据流

拿到一道题，先别急着打开编辑器。我通常做三件事：圈出输入、圈出输出、标出条件。比如题目说“输入一个整数n，输出1到n之间所有偶数的和”，我就在纸上写：输入是n（int），输出是sum（int），条件是“偶数”即i % 2 == 0，范围是1到n。

这个阶段最重要的是确认数据类型。n会不会很大？如果n是100000，sum会不会溢出int？第二周的题目一般不会涉及大数，但养成这个意识没坏处。另外，输出格式有没有特殊要求？是每个结果一行，还是用空格隔开？这些细节读题时就要确认，不要等提交错了再回头看。

4.2 编码阶段：先搭骨架再填肉

我写代码的习惯是先写框架，再填细节。以“判断闰年”为例，骨架是这样的：

#include <stdio.h> int main() { int year; scanf("%d", &year); // 判断逻辑 return 0; }

然后往“判断逻辑”那里填if-else。这样做的好处是输入输出部分不会出错，你只需要专注在核心逻辑上。很多人一上来就从头写到尾，写到一半发现变量没定义，又回头加，加完又发现格式串写错了，来回折腾。

变量命名也有讲究。第二周题目里常见的变量无非就是n、m、a、b、sum、count、max、min这些。我建议用有意义的英文单词，比如radius、area、year、score，这样代码读起来像句子，调试的时候一眼就能看出哪个变量是干什么的。

4.3 测试阶段：自己造用例比等OJ反馈快得多

提交之前，至少自己测三组数据：一组正常值，一组边界值，一组特殊值。比如求最大值，正常值测(3, 5)，边界值测(5, 5)，特殊值测(-1, -5)。如果这三组都过了，再提交，通过率会高很多。

自己测试的时候，可以用printf把中间变量打出来。比如算面积之前先打印radius的值，确认输入读对了；算完面积再打印area的值，确认计算没错。这个技巧叫“插桩”，是调试的基本功。等程序正确了，再把多余的printf删掉。

我见过太多人提交一次错一次，然后反复提交同一份代码，指望OJ突然开恩。正确的做法是本地测，用printf看中间结果，定位到具体哪一步不对，改完再提交。这样效率高十倍。

4.4 提交与反馈解读：编译错误、答案错误、格式错误分别意味着什么

OJ的反馈信息其实很有用，但很多人不看。编译错误说明语法有问题，通常是少了分号、括号不匹配、变量没定义。答案错误说明逻辑有问题，输出和预期不符。格式错误说明输出格式不对，比如多打了空格、少了换行。超时说明循环有问题，可能是死循环或者算法太慢。

第二周最常见的反馈是答案错误和格式错误。答案错误优先检查边界条件和整数除法；格式错误优先检查printf里的换行和空格。把反馈信息当线索，而不是当判决，排查起来会快很多。

5. 常见问题与排查技巧实录

5.1 编译错误速查表

编译错误是最好解决的，因为编译器直接告诉你哪一行有问题。但要注意，编译器报的行号有时候是下一行，因为错误可能在这一行末尾才被发现。比如少了分号，编译器会在下一行报错。

5.2 答案错误排查思路

答案错误没有提示，只能自己找。我的排查顺序是：先检查输入读对了没有，再检查计算逻辑，最后检查输出格式。输入问题用printf打印读到的值；计算问题用printf打印中间结果；输出问题对照题目要求一个字符一个字符地比。

第二周答案错误的高频原因就三个：整数除法、边界条件、条件顺序。遇到答案错误，先往这三个方向想，基本能命中。

5.3 格式错误的自查清单

格式错误通常是因为输出多了或少了一个空格、换行。我整理了一个自查清单，提交前过一遍：

• 题目要求每个结果一行，我有没有漏掉\n？
• 题目要求用空格分隔，我有没有多打空格？
• 题目要求保留两位小数，我有没有写%.2f？
• 题目要求输出“Yes”还是“YES”？大小写对不对？

这些细节看起来琐碎，但OJ的判题是精确匹配，差一个字符都不行。养成提交前对照题目要求检查输出格式的习惯，能省下很多次重提交。

5.4 超时问题的定位与解决

第二周的超时基本都是死循环。定位方法很简单：在循环体里加一句printf，看看是不是一直在打印。如果是，检查循环变量有没有更新，或者退出条件是不是永远为真。

还有一种超时是循环次数太多。比如题目要求计算1到1000000的和，你用循环一次一次加，虽然能出结果，但可能超时。第二周一般不会遇到这种，但如果你发现循环次数很大，可以考虑用数学公式代替循环。比如1到n的和就是n*(n+1)/2，不需要循环。

我个人的经验是，第二周的题目如果超时，99%是死循环，1%是循环次数过大。先查死循环，再考虑优化。

6. 从第二周题目延伸出的编程习惯

6.1 注释不是写给老师看的，是写给三天后的自己看的

第二周的代码通常很短，很多人觉得没必要写注释。但我建议至少写三行：输入是什么、输出是什么、核心逻辑是什么。比如：

// 输入：年份year // 输出：是否为闰年 // 逻辑：能被4整除且不能被100整除，或能被400整除

三天后你回头看这段代码，如果没有注释，你可能要重新读一遍才能想起来当时怎么想的。注释是给自己省时间的，不是给老师看的。

6.2 变量初始化：不初始化就是在赌运气

C语言里局部变量不会自动初始化，它的值是内存里的垃圾数据。如果你定义了一个变量没赋值就直接用，结果完全不可预测。第二周常见的错误是累加变量sum没初始化为0，导致结果乱七八糟。

int sum = 0; // 必须初始化 int max = 0; // 如果输入可能为负，max应该初始化为第一个输入值

我的习惯是定义变量的同时就初始化，int初始化为0，double初始化为0.0。这样即使后面逻辑有遗漏，至少不会出现随机值。

6.3 代码风格：缩进和空格不是小事

第二周的代码虽然短，但缩进混乱会让逻辑看起来一团糟。if里面嵌套if，如果不缩进，你根本看不出哪个else对应哪个if。我建议用4个空格缩进，大括号独占一行或者跟在语句后面都行，但全篇要统一。

// 缩进清晰的写法 if (year % 4 == 0) { if (year % 100 != 0) { printf("是闰年"); } else if (year % 400 == 0) { printf("是闰年"); } else { printf("不是闰年"); } } else { printf("不是闰年"); }

这段代码逻辑上可以简化，但缩进清楚地展示了嵌套关系。初学者先把逻辑写对，再考虑简化。

6.4 从提交结果反推测试用例的设计思路

OJ的测试用例不是随便造的，它通常覆盖了题目描述里的所有情况，再加上边界值。你提交错误之后，可以根据错误类型反推它测了什么。比如答案错误，可能是某个边界没处理；格式错误，可能是输出格式和题目要求有出入。

我有个习惯，做完一道题之后，自己想想“如果我是出题人，我会测哪些情况”。这个思考过程能帮你建立测试意识，以后写代码会自动考虑边界和异常。

7. 第二周之后的路怎么走

第二周把这些基础打牢了，第三周的循环和数组会轻松很多。我见过太多人第二周糊弄过去，第三周遇到嵌套循环直接崩溃。编程这件事，前面的坑不填，后面会以更大的形式还回来。

如果你现在还在第二周挣扎，我的建议是别急着赶进度。把每道题的类型、坑点、排查方法整理成自己的笔记，下次遇到同类问题直接翻笔记。这个整理的过程比多做十道题都有用。

最后分享一个我自己的小技巧：每道题提交通过之后，别急着下一道，花一分钟想想“这道题我学到了什么”。是学会了某种格式串写法，还是搞懂了某种条件顺序，还是记住了某个边界值。把这些记下来，一个月后你回头看，会发现自己的进步是看得见的。