最近被问得最多的一个问题就是：Python作业到底该怎么写。说难听点，很多人写作业就像照着网上教程敲了一遍代码，能跑起来就万事大吉，结果一提交就被打回重做，原因千奇百怪：输入格式对不上、某个边界条件没处理、甚至只是print里多了一个空格。真正的Python作业，本质上是让你用代码解决一个定义明确的问题，评判标准不是你“看懂了多少语法”，而是你的程序在各种输入下都能稳定输出正确结果。这篇文章我会用一份典型的学生成绩统计作业作为例子，完整走一遍“读题拆解——语法准备——逐步编码——调试测试——格式自检”的全过程，分享我在实际辅导中积累下来的经验和踩过的坑，给正在写Python作业的同学一个能直接照着操作的指南。
1. 拿到Python作业后先别敲代码，先做需求拆解
1.1 反复读题，把“输入”和“输出”抠出来
很多同学的第一个错误，就是题目还没读完就打开编辑器开始写。作业题往往会有明确的功能描述、输入约定、输出格式要求，这些信息决定了你代码的边界。比如某次课程作业是这样的：编写一个程序，先接收一个整数n，然后接收n个学生的成绩（0到100之间的整数），最后输出最高分、最低分、平均分（保留一位小数）和不及格人数。看似简单，但我见过有人在实现时默认n一定大于0，没人考虑n为0的情况；有人输出平均分时直接打印了完整的浮点数，没有保留一位小数；还有人把“不及格人数”理解成“及格人数”。这些都不是语法问题，而是没有严格把需求里每个条件变成代码里的一个判断。
拿到作业后，我建议用一张纸或一个文档做三件事：第一，用一句话概括这个程序要干什么；第二，列出所有输入项的格式和范围；第三，列出所有输出项的格式和顺序。以成绩统计作业为例，一句话是“统计一组学生成绩的分布和极值”，输入项是“整数n，后面跟着n个整数成绩，成绩在0到100之间”，输出项是“最高分、最低分、平均分（保留一位小数）、不及格人数，每项单独一行”。把这个表格列完，你已经完成了80%的思考，剩下的只是把表格翻译成代码。
1.2 用伪代码把流程讲清楚，而不是直接想语法
拆完需求后，下一步是写伪代码。伪代码不需要讲究语法正确，只需要把你的思路按顺序写下来。成绩统计作业的伪代码可能是这样：第一步，读入n；第二步，初始化最大值、最小值、总分、不及格人数；第三步，循环n次，每次读入一个成绩，更新最大值和最小值，累加总分，判断是否小于60并计数；第四步，计算平均分；第五步，按格式输出。你会发现，这里已经完全是在描述逻辑，而不是在写Python。
为什么要写伪代码？因为初学者最容易犯的毛病是“边写边改逻辑”，写着写着发现自己少处理了一个分支，然后又在某个函数里加了一堆补丁，最后代码变得又长又难读。伪代码相当于施工图纸，图纸定了，代码只是按图浇筑而已。如果你写伪代码时已经发现某些步骤有歧义，说明题目还没读懂，回去继续看题。
1.3 按功能拆模块，别把一切塞进main里
很多初学者的代码是几十行全部堆在ifname== "main"下面，或者干脆全写在顶层，没有函数。对于不超过二十行的作业，问题不大；但对于稍微复杂的题目，这样的代码很难调试。更合理的做法是拆成几个职责单一的函数：录入数据函数、统计计算函数、输出函数、主函数。每一段数据录入只负责获取原始输入，统计函数只接收数据并返回统计结果，输出函数只负责格式化打印。这样当错误出现时，你只需要定位到对应函数，而不是从第一行看到最后一行。
拆模块还有一个额外的好处：便于重用和手动测试。比如统计函数写好后，你可以直接在交互环境里用几行测试数据调用它，看返回结果是否正确，不需要每次都用input凭空输入一堆数字。对于作业里的核心算法，这种“先测函数、再拼整体”的流程非常高效。
2. 成绩统计作业里隐藏的5个核心语法点
2.1 input读入的永远是字符串，必须做类型转换且要防输入异常
Python的input函数有一个非常容易踩的坑：无论用户输入什么，它读进来的都是字符串。如果你直接拿读进来的值去做和运算或大小比较，一定会出问题。成绩统计作业里，n是整数，每个成绩也是整数，所以都要用int()进行转换。一个很自然的陷阱是用户输入了非数字内容，比如不小心敲了个字母，程序会在转换时抛出ValueError然后崩溃。
针对这个问题，我建议养成习惯：关键输入数据全部做类型转换，并且对可能出现的非法输入做try/except处理。例如录入成绩时，可以写成下面这种形式：
def read_score(index): while True: try: score = int(input("请输入第{}个成绩: ".format(index))) if 0 <= score <= 100: return score else: print("成绩必须在0到100之间，请重新输入。") except ValueError: print("请输入合法整数。")可能有人会觉得作业不会测非法输入，但很多评测系统的隐藏用例恰恰就爱测试这些边界情况。如果题目明确说了输入数据保证合法，那你不用写得这么复杂；但如果没保证，加上异常处理永远是更稳妥的选择。
2.2 单分支和双分支别混用，循环里的条件更新位置要敏感
成绩统计里有一句“每读入一个成绩就更新最大值和最小值”。这个逻辑看起来简单，但对初学者来说有个经典错误：初始化最大值时设为了0，最小值设为了100。如果所有成绩都在0到100之间，这个初始化还能碰巧工作；但如果题目允许成绩为0，那最大值永远是0了，因为0比任何成绩都小吗？不对，最大值的初始值如果设成0，那么所有正数成绩都比0大，会更新，但如果某个成绩也是0，最大值为0也算正确。可如果你初始化最大值为0，最小值为0，那么遍历时最小值永远不会更新，导致最小值为0。所以必须仔细设计初始值：最大值初始化为负无穷或极小值，最小值初始化为正无穷或极大值。
在Python里可以这样写：
max_score = -1 min_score = 101 total = 0 fail_count = 0然后每读入一个成绩，依次判断：如果score大于max_score则更新max_score；如果score小于min_score则更新min_score；total累加；如果score小于60，fail_count加1。这里需要注意判断顺序不能乱，也不要画蛇添足地写成elif，因为更新最大值和更新最小值之间是独立的，不互斥。用elif就会漏更新一种情况。
2.3 for循环的次数控制，边界问题最容易出错
统计n个成绩时，最直接的方式是for i in range(n)。这里要理解range(n)生成的是0到n-1这n个数字，循环体会执行n次。新手经常搞错的是：如果题目里输入的第一行是n，然后紧接着第二行才是n个成绩，你可能需要用split一次读入所有。但如果题目要求“每次输入一个成绩”，那就在循环体里调用input。
还有一个很隐蔽的边界问题：如果n=5，但用户在循环里输入了6个成绩，多余的那个输入不会被读取，程序会直接进入下一段逻辑；如果n=5，用户只输入了4个成绩，程序会在等待第5个输入时一直阻塞。评测系统会因此判定超时或WA。所以不要试图在循环里偷懒，老老实实按n控制循环次数。
当第二行一次性给了所有成绩时，更合理的写法是这样：
scores_input = input().split() scores = [int(x) for x in scores_input]此时len(scores)就是实际成绩个数，不需要依赖第一行的n。有些评测系统干脆会省略n，只给一行成绩，这时候一上来就用for i in range(len(scores))遍历即可。写代码之前先确认题目给的输入格式是“先n后n行”还是“一行n个数”还是“先n后一行n个数”，不同格式对应的读取代码完全不同。
2.4 列表和字典是统计数据的好帮手，但注意不要边遍历边修改
成绩统计可以完全不用列表，三个变量一路更新就行。但如果作业要求“显示成绩中位数”或者“按降序输出所有成绩”，那就必须先把成绩存进列表。Python里用列表存成绩很简单：
scores = [int(x) for x in input().split()]注意这个列表推导式的执行过程：input().split()得到一个字符串列表，int(x)把每个元素转为整数，最后整个表达式得到整数列表。写成列表推导之后，后续统计就方便了：max(scores)、min(scores)、sum(scores)、len(scores)全都有现成函数。
但列表有一个高频坑：有些同学想删除不合格成绩，却写了for score in scores: if score < 60: scores.remove(score)。这么做会在遍历过程中改变列表长度，导致跳过部分元素。安全的做法是生成一个新列表：scores_pass = [s for s in scores if s >= 60]。如果需要原地删除，也必须用倒序遍历或拷贝列表。所以我的建议是：除非作业明确要求修改原数据，否则一律用生成新列表的方式，避免一堆奇怪的迭代错误。
2.5 函数封装和程序入口，决定了你代码的扩展空间
不管作业多简单，我都建议写成函数加入口的结构。入口的固定写法是：
def main(): n = int(input()) scores = [] for _ in range(n): scores.append(int(input())) max_score, min_score, avg_score, fail_count = calculate_stats(scores) print(...) if __name__ == "__main__": main()ifname== "main":这一行在作业里不是必须，但在某些评测系统里，系统会把你的代码作为模块导入，如果没有这层保护，只要被导入就会自动执行所有顶层代码，造成输出混乱甚至报错。所以我一向建议所有作业都保留这个入口结构。
把统计逻辑拆成函数，还有一个好处：你可以把输入、计算、输出分开测试。每次调试时不需要反复输入大量测试数据，直接在函数调用里传入一个写死的列表即可。这种可测试性，在复杂作业里能救你一命。
3. 完整实操：从空文件到跑通的每一步
3.1 先搭出主流程骨架，保证程序“能跑”
很多同学的第一版代码想一口气把功能全写完，结果几十行代码一出错就不知道错在哪。我的做法是先写一个只处理一条数据的简化版本，跑通后再扩展。比如成绩统计作业，我先写主流程加统计函数：
def calculate_stats(scores): max_score = max(scores) min_score = min(scores) avg_score = sum(scores) / len(scores) fail_count = sum(1 for s in scores if s < 60) return max_score, min_score, avg_score, fail_count def main(): n = int(input()) scores = [] for _ in range(n): scores.append(int(input())) max_score, min_score, avg_score, fail_count = calculate_stats(scores) print(max_score) print(min_score) print(f"{avg_score:.1f}") print(fail_count) if __name__ == "__main__": main()注意我用了f"{avg_score:.1f}"来保留一位小数。这是格式化输出的关键点。如果不格式化，avg_score可能是67.6666667，而题目要求保留一位小数时输出就是67.7。在评测环境里，多打印出来几位小数会被判为格式错误。
3.2 逐步处理边界条件，填充防御代码
上面这个版本只能处理正常情况。下一步是处理异常和边界。比如n为0时，len(scores)为0，sum和max都会报错。如果题目要求n为正整数，那可以不处理；但很多题没写清楚，稳妥起见，过滤掉空列表的情况，或者限定成绩范围。再比如，万一用户输入的成绩带有空格字符，比如"85 90"，直接int("85 90")会报错，所以有时候需要读整行再分割。这些判断逻辑看似很细，但往往是作业能不能拿满分的关键。
我一般建议在写完每个函数之后，马上做边界测试。比如成绩统计：第一个测试是n=1，只有一个成绩，此时最大值、最小值、平均分都必须是这个成绩；第二个测试是n=2，成绩为0和100，平均值50.0，不及格人数为1；第三个测试是n=5，成绩全部相等；第四个测试是n=0，如果不允许，请在代码里给出友好提示。如果这些测试全部通过，再追求完整功能。
3.3 手动测试和自动测试结合，别只测一次
有人写完之后只在交互界面手动输入了一组数据，看到输出符合预期就提交，结果被评测系统狠狠教训了。原因很简单：人工测试覆盖不了所有流程，特别是边界和随机顺序。我分享一个笨但有效的方法：把测试数据写进一个文本文件，然后在命令行里用重定向运行程序。比如test1.txt里保存了“3 85 90 78”，然后运行python main.py < test1.txt，对比输出。平时练习可以多准备几个文本文件，分别命名为normal.txt、zero.txt、all_same.txt、missing_score.txt，每次改动代码后都跑一遍。这样能极大减少评测系统才发现的错误。
在调试统计函数时，还可以先在Python交互环境里直接导入代码模块，写几行测试：
from main import calculate_stats print(calculate_stats([85, 90, 78])) print(calculate_stats([]))如果第二个测试报错，说明你的函数没考虑空列表，那就该补上对应的逻辑。能对函数做单测，比手工反复输入数据方便得多。
4. 代码规范与提交自检：保住那些容易白丢的分
4.1 缩进、空行、命名，这些东西真的会被扣分
评测系统通常只看输出对不对，但老师和人工检查作业时会看代码质量。我见过手工批改的作业，因为缩进混乱，硬生生被扣了过程分。缩进是Python的语法骨架，千万不能混用Tab和空格，建议在编辑器里统一设置成四个空格。函数之间保留两个空行，逻辑块之间保留一个空行，这些是PEP 8规范的约定。说白了，你写代码不是给自己看，是给一年后的自己和审你作业的人看。
命名方面，变量名要能表达含义。scores、max_score、fail_count都比a、b、c好得多。函数名用动词加名词，比如read_scores、calculate_stats。注释也不用多，只需要在复杂逻辑的关键位置写一两行说明，比如“更新最高分和最低分”这种。别小看这些细节，很多企业里代码审查的态度远比课程严格，从作业开始养成习惯是最好的时间点。
4.2 输出格式是最大的隐形炸弹
写作业时最可惜的情况就是：逻辑全对，输出格式不对，评测系统判零分。格式问题常见有几类：第一类是多打印了提示语，比如print("成绩是：85")，而题目期望只输出85；第二类是缺少换行或多了换行，特别在循环输出时容易多打一个空行；第三类是使用了全角中文逗号、分号，或被肉眼忽略的不可见字符；第四类是保留小数位数不对，比如输出成了0.666而不是0.7。
建议在提交前做一次严格的输出检查：把样例输入复制进去，把输出结果和题目给出的样例输出逐字符对比，包括空格位置和逗号。你甚至可以先把输出写入文本文件再用diff命令对比，省得肉眼一不留神漏掉一个空格。在终端里，cat output.txt和diff standard.txt output.txt是最好用的工具。
4.3 提交前的自检清单
每次提交作业前，我会提醒自己过一遍这份清单：第一，程序能否在无编辑器环境下用命令行运行；第二，能否正确处理样例输入；第三，能否正确处理极端输入（0、负数、超长字符串、空输入）；第四，代码是否包含ifname== "main"入口；第五，文件命名是否满足要求（如main.py、作业.py）；第六，是否删除了测试代码和中间打印内容。第六点尤其重要，很多同学调试时留下的print会直接干扰评测系统的输出，导致判负。
另外，如果作业需要上传压缩包，记得确认压缩格式，不要传rar而系统只认zip。上传后重新下载一遍检查文件是否完整，这个动作虽然麻烦，但能避免交了白卷的尴尬。
5. 高频报错与排查技巧实录
5.1 五个最常见的运行时报错速查表
| 报错信息 | 出现原因 | 解决方法 |
|---|---|---|
| IndentationError: unexpected indent | 不该缩进的地方多了缩进，或混合使用了Tab与空格 | 检查代码缩进，全部改成四个空格 |
| NameError: name 'xx' is not defined | 变量名拼写错误，或在函数外使用了函数内部定义的局部变量 | 检查变量名，确认变量是否存在生命周期 |
| IndexError: list index out of range | 访问了不存在的列表索引，常见于scores[0]但列表为空 | 先判断长度，或改用遍历 |
| ValueError: invalid literal for int() | 对非数字字符调用了int() | 先检查输入合法性，或用try/except捕获 |
| TypeError: cannot concatenate str and int | 用加号拼接字符串和整数 | 把两边都转成str，或使用格式化输出 |
这张表值得贴在电脑旁边。很多报错一看就懂，但新手容易慌，其实只要认真读最后一行提示，就能定位问题所在。Python的报错信息已经非常友好，它告诉你哪一行出错、是什么类型、具体对象是什么。遇到报错不要急着乱改，先读信息，再想原因。
5.2 排查逻辑问题的“小样本复现法”
语法报错很容易解决，但逻辑错误很难发现。比如你来测试成绩统计，输入n=3，成绩为85 90 78，输出却是85、78、84.3，哪里出错了？这种错误不会让你崩溃，但会悄悄吃掉你的分数。我的经验是：构造一个能让数据“失控”的小样本，用笔算一遍，再看程序输出。比如用成绩0、50、100，程序应当输出100、0、50.0、1。如果结果不是这个，你就自己手动逐行走一遍代码。
逐行走代码时，最经典的工具是print大法，不过记得调试完删掉所有临时print。在关键变量更新后加一句print("max_score =", max_score)，看看它是怎么变化的。比如你会发现某个循环里max_score总是更新不成，那就知道是判断条件写反了。对于更复杂的项目，可以使用Python自带的pdb，但作业场景里Print大法完全够用。
5.3 一个容易被忽略的经典场景：空列表与全同分数
作业题目常常暗含一种边界情况：所有输入值完全一样。比如五个学生的成绩全是78，此时最大值和最小值都是78，平均分是78.0，不及格人数是0。也许你的代码会在这时输出正确结果，但如果内部用elif处理了更新最大值和最小值，就可能漏掉其中一种更新。所以建议在测试时专门准备一个全同的数据集。另一种情况是空输入，比如题目说输入n为0时输出什么？如果不允许，你可以打印一个提示，然后退出；如果允许，那么所有统计值要么定义为0，要么做特判。处理边界条件的态度决定了你在评测系统里的最终排名。
除了上面这些，我最后再分享一个个人经验：批改过不少同学作业之后，真的非常建议大家写代码时保留一个“开发笔记”文件，记录自己拆题、设计、遇到的坑、想通的逻辑。很多同学觉得作业做完就结束了，其实不是。作业里的每一个边界条件都是从实际需求里提炼出来的，你遇到的每一个报错都可能在下一次项目里再次出现。把踩坑过程记下来，比反复背语法点管用得多。
如果在提交之前你还有时间，我会建议你再做一次从零开始的“口头复现”：不看自己的代码，把题目目标、输入格式、输出格式、核心算法用文字重新描绘一遍，然后对照代码确认没有遗漏。这样能逼你发现自己其实并没有完全理解的地方。很多看似“粗心”的扣分，本质上都是理解不到位。这份复盘的习惯，就是个隐形的加分项，长期来看比任何一次作业本身的分数都更值钱。
