刷完整整一门慕课的Python编程题需要多长时间？我的答案是：如果每天抽出一到两小时认真写、认真调试，大概一个月出头。这里说的慕课，是某理工高校在开放学习平台开设的《Python语言程序设计》课程。课程的视频和配套自测题不算多，真正撑起学习密度的是那几十道编程题：从第一条“输出Hello World”开始，到最后的文件读取、中文词频统计和词云绘制，几乎把Python的基础语法、常用数据结构、函数、面向对象和第三方库全用了一遍。很多人问刷这些题到底值不值，我的判断是：如果只想拿个课程证书，做做选择题就够了；但如果你想让Python真正成为自己能用的工具，编程题才是这门课最值得花时间的地方。这篇记录不打算复述课件，也不提供官方题解，只讲我提交、翻车、再提交之后沉淀下来的实战经验。
1. 编程题单长什么样：先把对手摸清楚
1.1 题量与难度曲线并不是均匀分布
我第一次打开编程题列表时，下意识数了一遍：加起来有八十多道题，分布在七个主要章节里。第一反应是“这得写到什么时候”，但按章节往下推之后，发现题量和难度并不是均匀的。基础语法部分的题基本是送分题，比如华氏转摄氏、用turtle画一个五角星；从循环这一章开始，需要自己组织逻辑；到了函数和递归那一章，难度直接往上跳了一截；文件处理和第三方库的综合题则是另一道坎，题目代码量不大，但涉及的知识点很杂。
我把一个典型章节的题量和我的主观感受整理成了下面的表，方便还没开刷的同学有个预期：
| 章节主题 | 典型编程题数量 | 难度感觉 |
|---|---|---|
| Python基本语法与turtle | 8 | 送分题，主要是熟悉环境 |
| 数值计算 | 12 | 入门，但要注意格式 |
| 循环与列表 | 18 | 开始需要设计逻辑 |
| 函数与递归 | 12 | 难度突然升高 |
| 字典与集合 | 10 | 中等偏上 |
| 文件与异常处理 | 8 | 综合性强 |
| 第三方库与综合应用 | 6 | 考验查文档能力 |
八十多道题看起来不多，但每一道都值得认真对待。特别是递归部分，很多同学在这里卡了一两周，原因不是不会写语法，而是没有形成“把大问题拆成小问题”的思维。这类题适合慢慢磨，磨过之后对函数理解的提升非常明显。
1.2 编程题和选择题、判断题本质上不是一类题目
选择题和判断题考的是“识别正确的外表”：给你一段代码，问你输出是什么，或者判断哪句话正确。这种题刷多了，容易产生一种“我好像都懂了”的错觉。编程题完全不一样，它考的是“构造正确的行为”：从输入开始，经过你自己的逻辑处理，最终输出符合要求的结果。自动判题系统不会看你的代码风格，也不看注释写得多漂亮，只看运行结果和期望输出是否一致。也就是说，写得再丑的代码，只要输出正确就能拿分；写得再优雅的代码，输出错一个空格也是零分。
这一条规则决定了刷编程题的方法：不要停留在“看懂题解”的程度，必须亲自动手把代码敲出来、跑通、提交。很多选择题得满分的同学，到了编程题第一次提交就挂，原因就在这。
1.3 提交前先搞清OJ平台的三条基础规则
在这些在线判题平台上提交代码，通常会告诉你几个固定信息：判题环境是Python 3.x，运行时间有限制，内存有限制，输入从标准输入读取，输出打印到标准输出。有几条规则是新手最容易忽略的。
第一，平台允许多次提交，但成绩计算方式不一样。有的平台取最高分，有的取最后一次提交的分数，如果一门课的成绩由编程题累加，这个区别就很关键。建议开刷之前先看看课程公告里怎么写的。
第二，隐藏测试用例是真实存在的。课程样例只是“示例”，老师会额外准备一批你没有见过的输入数据，用来检查边界和特殊情况。很多题本地跑样例全对，交上去却只拿部分分，就是因为隐藏用例没有覆盖到。
第三，代码里不能有读文件之外的多余交互。有的同学为了调试方便，在代码里写了input("请输入")之类的提示语，提交时忘了删，结果输出和期望格式不匹配。判题系统是逐字符比对的，多了一个汉字都算错。
2. 自动判题系统的脾气：格式、边界与隐藏用例
2.1 输出格式是一等公民，提示字符串是毒药
我第一次在这门课翻车，是一道特别简单的求和题。本地跑得非常友好，输入两个数，程序还会温柔地提示一句“请输入x:”。交到OJ上，直接Wrong Answer。原因不复杂：判题系统只认纯输出，多的提示字符串全部被视为多余内容。
这种事情在课程讨论区反复出现，所以值得单独拿出来说：标准输出里只能有题目要求的内容。想要提示语，留在本地调试版本里，提交前删掉。判断输出格式是否正确的标准不是“看不看得懂”，而是“是否和期望输出逐字符一致”。空格、换行、大小写、小数点后几位，全都在比对范围之内。
# 错误示范：提示语会污染输出 a = int(input("请输入x: ")) result = a * 2 print("结果是：", result) # 正确写法 a = int(input()) print(a * 2)2.2 浮点数输出：round和format的差别比你想象的大
数值计算题里，保留小数位是最高频的输出要求。很多初学者喜欢用round()，因为看起来直接。但我在刷题时发现，round()在做输出时有两个问题：一是不会自动补零，比如round(3.0, 3)的结果是3.0，打印出来是“3.0”，而题目期望的往往是“3.000”；二是二进制浮点数的舍入规则和日常十进制四舍五入并不完全一致，在边界情况下会出现出乎意料的结果。
更稳妥的写法是用f-string或者format固定小数位数。它输出的位数是确定的，该补零就补零，不会自己省略。
import math x = float(input()) print(f"{math.sqrt(x):.3f}")这条规则同样适用于百分数、千分位分隔符等格式变化。题目的输出格式描述看起来是“人类语言”，但判题实现往往是“字符串比对”，所以格式上的每个细节都值得较真。
2.3 多组输入、EOF与“超时”的真相
有的题输入不只有一组数据，题目会写“输入包含多组测试用例，处理到文件结束为止”。第一次看到这种描述时，我有点懵：程序怎么知道输入结束在哪里？正确的方法是一直读，直到读不到内容为止。
import sys for line in sys.stdin: line = line.strip() if not line: continue a, b = map(int, line.split()) print(a + b)用sys.stdin逐行读取是最稳妥的做法。如果写成一次input()，程序读完第一组就结束，OJ会认为你只处理了部分用例，通常判Wrong Answer。还有一种更隐蔽的错误：写了一个while True循环，里面直接调input()，没有捕获EOFError，当系统读到输入末尾时，程序抛异常直接Runtime Error。
不要一看到Time Limit Exceeded就以为算法复杂度太高。很多TLE其实是程序在等待输入：读不到数据但不退出，系统一直挂着你，直到超时。解决办法就是按上面这种写法处理EOF。
3. 高频题型的解题套路与代码骨架
3.1 数值计算类：暴力可以，但要会优化
数值计算题是MOOC编程题里最友好的一类，因为思路通常不绕。水仙花数、完数、素数判断、蒙特卡洛法求圆周率，这些题目只要掌握了基本语法，都能写出来，但写法优劣直接影响分数和正确性。
水仙花数题要求输出所有三位水仙花数，用Python列表推导一行就能解决：
result = [n for n in range(100, 1000) if sum(int(d) ** 3 for d in str(n)) == n] print(" ".join(map(str, result)))这里真正的考点其实是输出格式：要求数字之间用空格分隔，行尾无多余空格。直接把列表print出来会得到带中括号和逗号的字符串，必然出错。
完数题则涉及一点点算法优化。判断n是否为完数，如果从1一路试到n，n大一点提交就超时。实际上试到n的平方根就够了，因子总是成对出现，找到一个小因子，同时就能得到大因子。
def is_perfect(n): if n < 2: return False s = 1 for i in range(2, int(n ** 0.5) + 1): if n % i == 0: s += i if i != n // i: s += n // i return s == n蒙特卡洛法求圆周率在很多课程里都有，核心是随机数落在单位圆内的比例。要注意设置随机种子，否则每次运行结果不同；同时题目一般会说明允许误差范围，实际输出不需要和某个固定值完全一致。这类题反而宽松一些，重点是理解随机采样的思想。
3.2 字符串与词频统计：正则加Counter是黄金组合
字符串处理在MOOC里占比不低，尤其是词频统计类题目，几乎每门Python课都会出现。这类题表面是统计单词，实际在考察三件事：文本清洗、大小写归一化、排序规则。
我刷题时固定的套路是：先把整段文字统一成小写，然后用正则找出所有连续英文字母，再用collections.Counter统计。
import re from collections import Counter text = input().lower() words = re.findall(r"[a-z]+", text) for word, cnt in Counter(words).most_common(): print(f"{word}: {cnt}")一个容易忽略的点是“单词”的定义。题目要求忽略所有标点数字，还是只忽略标点？如果题意是只保留英文字母，那正则里的r"[a-z]+"就是正确的；如果允许数字作为单词的一部分，写法要改成r"[a-z0-9]+"。不要凭感觉猜，题目里通常会描述，只是描述得比较隐蔽。
还有一类题要求统计中文词频，会用到jieba分词库。此时默认的精确模式就够用了，但注意要过滤掉空格和换行，很多同学统计出来一堆“空白词”才发现问题。
3.3 turtle绘图题：坐标、方向和动画
turtle绘图题通常出现在课程前几个章节，目的是让你对循环、函数和坐标有直观感受。这类题在判题服务器上一般是看不见图形的，判题系统只看你的程序能不能顺利运行结束。但也正因为如此，很多细节反而容易踩坑。
第一个坑是程序结束时没有进入事件循环。画完图直接结束，窗口可能一闪而过，在某些环境里程序会直接退出，OJ端可能认为非正常结束。正确做法是在末尾调用turtle.done()或turtle.exitonclick()。
第二个坑是画笔方向。turtle初始朝向是正东方向，坐标系原点在画布中心，x向右为正，y向上为正。画五角星时，很多人把角度算反。画一条边之后，要右转的角度是180度减去内角，五角星的内角是36度，所以转144度而不是72度。这个数字我记错了好几次，最后干脆在草稿纸上画了个图才理解。
第三个坑是动画速度。画几百条线时，如果speed(1)慢慢画，本地没有问题，但服务器上可能因为执行时间太长而超时。建议在提交时加上turtle.speed(0)或turtle.tracer(0, 0)，画完一次性刷新。
3.4 文件处理与第三方库：路径、编码与依赖
课程后半段的编程题开始出现文件读写，这时候踩坑的方式又换了一波。最常见的是本地绝对路径。很多人在自己电脑上写：
with open("C:/Users/某路径/data.txt", "r") as f: ...交到OJ上，这个路径根本不存在，程序直接FileNotFoundError。正确做法是看清题目给的相对路径，或者干脆不创建文件，把所有输入都通过标准输入读进来。
文件编码也要注意。如果题目要求读取的文件里包含中文，且没有明确说明编码，我一般先用UTF-8试一遍。判题环境基本都是Linux，默认UTF-8，和本地系统的默认编码可能不一致。写成这样比较稳妥：
with open("data.txt", "r", encoding="utf-8") as f: content = f.read()第三方库方面，jieba分词和wordcloud是综合题的常客。提交前必须确认题目允许使用哪些库，以及判题环境是否安装。wordcloud生成中文词云时还需要中文字体文件，如果题目要求输出图片，但判题环境没有对应字体，图片上会出现一堆方框。遇到这种题，我一般先去课程公告看有没有额外说明，没有说明的情况下，尽量选择在代码里显式指定一个常见的字体路径。
4. 本地跑得好好的，交上去就错：三个翻车现场复盘
4.1 翻车一：本地Python版本比判题环境新，用了新特性
有一道题要求计算一个整数列表里所有元素的乘积。放到现在，我大概率会老老实实写个循环，但当时我本地用的Python版本比较新，脑子里第一个想到的就是标准库里的现成函数，于是顺手写了一句：
import math print(math.prod(data_list))本地跑，通过。提交后，报错信息是AttributeError: module 'math' has no attribute 'prod'。看到这一行，我第一反应是“怎么可能没有prod”，后来才意识到判题环境是Python 3.7，math.prod是从3.8才引入的。
排查链路是这样的：先看报错类型，是运行时属性错误，说明不是逻辑问题，而是环境差异；然后查Python各版本标准库变化；最后把实现改成循环累乘，提交通过。
这件事给我最直接的教训是：提交之前先看课程公告里写的解释器版本。如果课程环境比你本地版本老，就尽量避免使用较新的语法和标准库函数。类似地，f-string里的调试语法f"{x=}"是3.8才有的，在3.7下连语法都过不了，会直接给你一个SyntaxError，比运行时错误更难看懂。
4.2 翻车二：round补零问题，输出永远比期望少几个零
另一道题要求输入一个正整数，输出它的平方根，保留小数点后三位。我的第一版代码：
import math n = int(input()) print(round(math.sqrt(n), 3))样例输入2，输出1.414，和样例一致。但提交之后，有一组输入9，期望输出3.000，我的程序输出3.0。问题就出在round()返回的是浮点数，浮点数的print不会保留尾部的零。判题系统把“3.0”和“3.000”当作完全不同的字符串，自然判错。
改成格式化输出之后，一切正常：
print(f"{math.sqrt(n):.3f}")这类问题在浮点数相关题目里特别容易复发。记住一个原则：只要题目说了“保留N位小数”，一律用格式化字符串输出，不要用round。round可以在计算过程中使用，但不要直接拿它的结果去print。
4.3 翻车三：词频相同的时候，排序规则不是你想的那样
词频统计题里有这样一道：统计一篇文章中出现次数最多的前10个单词，如果两个单词出现次数相同，按字母顺序从小到大输出。我用的Counter.most_common(10)，样例输出完美，但提交后有一半用例是错的。
后来仔细读文档才发现，Counter.most_common在频次相同时，返回顺序取决于元素第一次被统计到的先后顺序，而不是字典序。隐藏用例里一旦出现并列频次，判题期望的是字典序，我的输出顺序就错了。
正确写法是按照二元组排序：
sorted(cnt.items(), key=lambda x: (-x[1], x[0]))[:10]这个坑的经验其实可以推广：凡是题目里写了“如果相同则按某某规则再排序”，就不能依赖库函数的默认顺序，必须显式指定排序键。同类场景还有“按总分降序，总分相同按学号升序”，在Python里用sorted加多级key解决。
4.4 从报错信息到根因：我常用的排查链路
经历了这些翻车之后，我整理了一套固定排查顺序，之后每次提交失败都按这个来，效率提高很多：
- 第一步，分清错误类型。Wrong Answer是输出和期望不一致；Runtime Error是运行中抛异常；Time Limit Exceeded是超时；Compile Error是语法错误。类型不同，排查方向完全不同。
- 第二步，看报错信息最后几行。traceback会明确指出是哪个文件的哪一行出了问题，不要只看红色的Error单词就慌。
- 第三步，如果本地无法复现，优先怀疑环境差异：Python版本、操作系统、文件路径、第三方库安装情况。
- 第四步，对于Wrong Answer，用repr()打印自己的输出，检查空格和换行。肉眼看不到的差异，repr能让你一目了然：
print(repr(result))- 第五步，再去看课程讨论区。不是让你抄答案，而是确认有没有人提到过隐藏用例的特殊情况。
这个顺序看起来简单，但真的很管用。我见过不少同学一看到Wrong Answer就在讨论区发帖求助“我的代码为什么不对”，其实只要自己按这个流程走一遍，大部分问题都能定位。
5. 刷完编程题后，我更确定这几件事
5.1 编程题倒逼出来的两个习惯
第一个习惯是写代码之前先想边界。不是动键盘就敲，而是先问自己：输入为空怎么办？只有一个元素怎么办？浮点数相等能直接用==吗？这些边界意识在选择题里永远学不到，只有被OJ的隐藏用例教育过才知道。
第二个习惯是小步快跑，持续验证。我不再一次性写二三十行再运行，而是写几行就打印一次中间结果，确认这一步逻辑对了再继续。虽然看起来慢，但最后定位错误的时间大大缩短。
5.2 建立自己的代码片段库
刷到后半段，我发现自己总是在重复处理几类问题：读取多行输入、按多级key排序、格式化输出、用正则清洗文本。于是我把课程里的题按功能模块做了分类，把每个模板存成一个小文件，之后遇到类似题直接改参数。
比如多输入解析模板：
import sys for line in sys.stdin: line = line.strip() if not line: continue parts = line.split() ...再比如多条件排序模板：
items.sort(key=lambda x: (-x[1], x[0]))这个习惯的价值在于，它把“刷题”从背书变成了搭积木。MOOC编程题虽然花样多，但核心考点就那么几类，有了片段库之后，新题到手很快就能判断出该用哪块积木。
5.3 给正在刷题的同学一个节奏建议
我的建议是每天两到三道，按课程章节顺序来，不要一次性肝几十题。编程题的难度曲线不是线性上升的，递归和文件处理这种坎，连续死磕容易把心态搞崩。卡住超过半小时就先放一放，去把课件里对应的例子重看一遍，或者做点别的事，第二天回头再看往往有突破。
还有一个提交小技巧：不要只拿样例验证就算完。每次提交前，自己构造一两个和样例不同的用例，专门用来试探边界。比如题目说输入范围1到10的9次方，就试一次最大值；题目说输入可能包含空白行，就故意加一个空行。很多错误不是因为主流程错，而是因为这些边角没有处理。
最后再分享一个个人习惯：每次拿到Wrong Answer，我会把输出结果的repr贴到编辑器里，逐字符检查空格和换行，这个动作帮我解决了不少看起来完全没问题的错误。希望这份实战记录能让你在刷MOOC编程题时少一点抓狂，多一点确定。
