1. 作业内容与题目拆解
1.1 这道题到底在考什么
第三次Python作业，在很多入门课程里是一道分水岭。前两次作业大家还在和print、变量、if/else较劲，到了第三次，就突然要求你"组织代码"了——函数、列表、字典、字符串处理，再叠加文件读写，几乎全部上场。我这次拿到的题目非常典型，要求做一个学生成绩管理小程序：录入学生姓名、学号和三门课成绩；计算每个人的平均分；按平均分排序输出；支持按学号查找学生；最后把结果保存到文本文件。
这个题目看着简单，实际上把Python入门阶段最重要的几个知识点全串起来了。你在写的时候会明显感觉到，前两次作业那种"从上到下流水账"的写法已经撑不住了，必须开始考虑函数怎么封装、数据用什么结构存。这也是为什么很多老师喜欢在第三次作业安排类似的题目——它逼着你从"会写语法"过渡到"会写程序"，这一步跨过去，后面学类和对象的时候会轻松很多。
1.2 拿到题目后先别急着敲代码
这里我想先吐槽一个很多人都会犯的毛病，包括我自己第一次做的时候也是这样：看完题目立刻打开编辑器开始写，写到一半发现数据不知道怎么组织，又回头重构，浪费了大量时间。合理的做法是先花十分钟把需求拆一下，搞清楚每个功能模块长什么样、谁调用谁。
拿这个题目来说，需求可以拆成六个独立的小功能：录入学生、计算平均分、排序、按学号查找、保存文件、主流程控制。前五个都是单一职责的函数，最后一个main负责把它们串起来。这个拆分思路，就是很多人挂在嘴边的"高内聚、低耦合"在入门作业里的第一次实践。我把每个功能写成独立函数之后，代码量看起来没少，但调试体验完全不一样——出错了只需要看对应的那个函数，而不是把整个文件从头翻到尾，这个习惯越早养成越好。
2. 核心知识点拆解与方案选型
2.1 数据用什么结构存
这是整个作业里最关键的决策点。学生信息包含姓名、学号、三个成绩，平均分是算出来的，所以核心问题就是：用列表套字典，还是用列表套列表，还是用面向对象的类？
我最终选了列表套字典的方案。每个学生是一个字典，里面有name、sid、scores、avg四个键，所有学生再装进一个列表。这样做的理由是：字典可以用键名访问，代码可读性最好，student["name"]一看就知道在取姓名。如果用嵌套列表，就得靠下标记忆，第0个是姓名、第1个是学号，碰到稍微复杂的数据很容易把自己绕晕。
至于为什么不直接用类，原因也很实在：第三次作业的考察范围大概率还没到面向对象，贸然用类反而显得过度设计。更重要的是，入门阶段应该先把"数据组织"这件事练扎实，等你清楚地知道字典和列表怎么配合了，后面学类的封装、继承时才不会觉得抽象。这个作业如果硬套类，代码反而会多出一堆样板，对理解核心知识点没有帮助。
2.2 函数怎么拆才合理
函数拆分的核心原则是"一个函数只做一件事"。录入、计算、排序、查找、保存，彼此之间没有交叉，这就是最自然的边界。
这里有一个初学者容易纠结的点：求平均分到底要不要单独写一个函数？我的建议是写。虽然求平均只需要sum(scores) / len(scores)一行代码，但如果录入时算一次、打印时再算一次，逻辑就散落各处了。把它封装成calc_avg(student)之后，以后想改成去掉一个最高分再算平均，只需要改这一个函数，其他地方跟着生效。这就是函数复用的价值，哪怕现在的代码只调用了两三次。
排序这块我用了sorted配合lambda匿名函数，这是我当时琢磨最久的地方。sorted(students, key=lambda s: s["avg"], reverse=True)这行代码，把"按哪个字段排序"和"升序还是降序"两个问题用参数化解决了，比手写冒泡排序优雅得多，而且内置排序是C语言实现的，性能上完胜。但我也建议手写一遍冒泡排序，不是为了交作业，而是为了理解排序背后发生了什么——这点在面试和后续算法课里会反复用到。
2.3 环境准备与运行方式
写完代码总得跑起来，环境这块顺便说一下。我用的是PyCharm，社区版就够用了，新建项目时解释器选系统里的Python 3.8以上版本即可。如果你用的是VSCode，记得装Python扩展插件，然后在左下角选择解释器，否则会出现"明明装了Python却提示找不到解释器"的问题。Windows下装完Python之后，我强烈建议手动检查一下环境变量，在命令行输入python --version能正常输出版本号才算配好，上课时经常看到同学卡在这一步。
运行方式上，我建议直接在IDE里点运行按钮，不要用交互式命令行逐行调试，因为你作业里有input()输入，在交互模式下很容易混乱。还有一个小细节，代码文件命名别用test.py这种，因为Python标准库里有个模块叫test，会出现命名冲突，我当时被这个坑过一次，排查了很久才发现是文件名的问题。
3. 实操过程与代码实现
3.1 主框架和公共代码先搭起来
我习惯先把主函数和程序入口写好，再逐个填功能函数，这样心里有个大概的地图，不至于写着写着跑偏。主流程大概是：录入 → 排序 → 打印排名 → 查找 → 保存文件，每一步调用一个函数，顺序非常清晰。
def main(): students = input_students() if not students: print("没有录入任何学生，程序退出") return students = sort_students(students) print("\n===== 成绩排名 =====") for i, s in enumerate(students, 1): print(f"{i}. {s['name']}（{s['sid']}）平均分：{s['avg']:.2f}") sid = input("\n请输入要查找的学号：") stu = search_student(students, sid) if stu: print(f"找到学生：{stu['name']}，平均分：{stu['avg']:.2f}") else: print("未找到该学号对应的学生") save_to_file(students) print("成绩已保存到 result.txt") if __name__ == "__main__": main()if __name__ == "__main__":这一行，很多刚入门的同学不知道什么意思，其实它表达的是"只有直接运行这个文件时才执行main()"，如果这个文件被别的脚本当作模块导入，main()就不会自动执行。这在写可复用代码时是非常重要的习惯，虽然当前作业里只有一个文件，但是养成这个写法，后面做项目时会省掉很多莫名其妙的bug。
3.2 各功能函数逐一实现
录入函数是整个程序的入口，难点在于循环的退出条件和输入校验。我的做法是用姓名输入q作为退出信号，成绩用float()转换，如果输入非数字会直接抛异常，这个先不管，等作业里的进阶要求再加异常处理。
def input_students(): students = [] print("请输入学生信息，输入 q 结束录入") while True: name = input("姓名：") if name.lower() == "q": break sid = input("学号：") scores = [] for i in range(3): score = float(input(f"第{i+1}门课成绩：")) scores.append(score) students.append({ "name": name, "sid": sid, "scores": scores, "avg": calc_avg(scores) }) return students注意这里我把calc_avg接收的参数设计成了成绩列表而不是整个学生字典，这样函数更纯粹，也方便复用。如果以后要算某个已经存在的学生的平均分，直接把scores传进去就行。
计算平均分和排序、查找这三个函数放在一起看：
def calc_avg(scores): return sum(scores) / len(scores) def sort_students(students): return sorted(students, key=lambda s: s["avg"], reverse=True) def search_student(students, sid): for s in students: if s["sid"] == sid: return s return Nonesorted返回的是一个新列表，不会改动原来的列表，这个特性在后续代码里很有用。查找函数用的线性查找，因为学生数量很少，没必要上二分查找，如果提前按学号排好序才能用二分，但那个复杂度对这个作业来说属于画蛇添足。
最后是保存文件。这里有个新手重灾区：直接写入中文，打开文件看到乱码。我一开始就踩了这个坑，后来查了资料才知道是编码问题，必须显式指定encoding="utf-8"。
def save_to_file(students, filename="result.txt"): with open(filename, "w", encoding="utf-8") as f: f.write("姓名,学号,平均分\n") for s in students: f.write(f"{s['name']},{s['sid']},{s['avg']:.2f}\n")with open(...) as f这种写法叫上下文管理器，它能保证文件用完后自动关闭，不用手动写f.close()。别小看这一点，如果忘记关闭文件，数据可能没有真正写入磁盘，尤其在程序异常退出的时候，这个教训我是在后来做爬虫写数据时深刻体会到的。
3.3 测试用例怎么设计
交作业之前一定要跑测试，不要只拿一组正常数据跑通就完事。我当时设计了四组用例：第一组是正常的三名学生数据，验证排序是否正确；第二组只录一个学生，验证边界情况；第三组直接输入q不录任何学生，验证空列表会不会报错；第四组查找一个不存在的学号，验证"未找到"分支。
这四组全跑通之后，我又顺手试了一次输入成绩时打字母的情况，比如输入abc，程序直接抛ValueError崩掉了。虽然题目没要求处理异常，但这让我意识到程序的健壮性是另一个层面的问题。后来我给成绩输入加了个简单的try...except，提示用户重新输入，代码看起来就专业很多。测试用例的价值不在于证明程序"能用"，而在于找到程序"什么时候不能用"，这个认知越早建立越好。
4. 常见问题与排查技巧实录
4.1 作业里最容易踩的坑
第一个坑是中文编码问题。写入文件的时候不指定编码，Windows下默认会使用GBK，如果你在PyCharm里用UTF-8打开就会看到乱码，反过来也一样。解决方式就是在open()时显式传encoding="utf-8"。同理，读文件时也要保持编码一致，这是所有Python文件操作逃不开的细节。
第二个坑是列表和字典的引用传递。我在做排序时一开始直接在原列表上调students.sort(...)，结果后面的查找和保存都基于排序后的列表，看起来没问题。但有一次我写了一个复制列表的操作，用了new_list = students，然后修改new_list里的学生信息，发现原列表也变了。这是因为赋值只是拷贝了引用，两个变量指向的是同一个列表对象。要真正复制得用copy.deepcopy()，这个知识点在作业里未必会用到，但理解了它能帮你避开一大类隐蔽的bug。
第三个坑是输入输出的类型问题。input()返回的一律是字符串，如果直接拿去做数值比较，比如if score > 60，会直接报错。很多人第一次写成绩判定程序都会栽在这，解决办法就是float()或int()转换。还有一个容易忽略的是，float转字符串时默认会输出很多小数位，比如80.0、83.33333333333333，打印排名时非常丑，所以我在格式化字符串里用:.2f控制精度，这个细节能让输出好看很多。
4.2 问题速查表
| 现象 | 原因 | 解决方案 |
|---|---|---|
| 打开result.txt是乱码 | 写入时未指定UTF-8编码 | open(filename, "w", encoding="utf-8") |
提示ValueError: could not convert string to float | 输入的字符串无法转成浮点数 | 加try...except捕获，或者循环直到合法输入 |
| 两个变量修改互相影响 | 列表/字典是引用类型，赋值只拷贝了引用 | 用copy.deepcopy()复制，或明确知道是原地修改 |
| 程序运行后中文显示成方框 | 控制台编码问题 | Windows下在PyCharm中设置Console编码为UTF-8 |
NameError: name 'xx' is not defined | 函数里用了未定义的变量 | 检查变量是否传参，函数内外命名空间要分清 |
打印平均分出现83.33333333333333 | float默认精度输出 | 格式化时用f"{value:.2f}" |
找不到main函数入口 | 没有写if __name__ == "__main__": | 按规范补上程序入口 |
4.3 排查思路比答案更重要
如果程序报错，先别急着问别人，学会看报错信息是Python学习中最值得投入的一项技能。Python的Traceback会明确指出错误发生在第几行、是哪一种错误类型，你只需要从最后一行往上找，基本就能定位问题。我遇到最多的是TypeError和AttributeError，前者通常是类型不匹配，后者通常是调用了不存在的方法，比如把字典当列表用、或者变量名拼错。
实在排查不出来的时候，我推荐在关键位置加print()调试，这也是最朴素有效的手段，比用断点工具还快。比如不确定sorted之后列表顺序对不对，就把排序前后的列表都打印出来对比。等作业做完，再把这些print删掉就行。很多同学觉得print调试很low，但实际上即使工作多年的工程师也经常用它快速验证想法，别在这件事上有心理包袱。
5. 交完作业之后的扩展与延伸
5.1 把作业升级成带界面的小工具
这个成绩管理系统的基础功能做完之后，我给它加了一些扩展，收获比原作业本身还要大。比如我把数据存储从文本文件换成了CSV，这样可以直接用Excel打开，还顺手把全班成绩按分数段统计了一遍，画了一张柱状图。画图用的是matplotlib，这个库在数据分析领域几乎是标配，通过这个小项目提前接触一下，后面学数据分析与可视化时就不会觉得陌生。
如果想让这个小程序更方便使用，还可以把它改用命令行参数交互，或者打包成exe文件发给别人——用pyinstaller一条命令就能搞定，但要注意打包后运行时会多出一个dist文件夹，而且文件路径的处理方式和源码运行时不太一样。我打包过一次，发给室友用，他双击就能跑，那一刻还是有点成就感的。
5.2 从作业里带走的三个习惯
做完这次作业，我给自己总结了三条用在后面所有编程学习中的规则。第一条是在动手之前先用伪代码把流程写在纸上，哪怕只是三五句话，也能避免一半以上的返工；第二条是勤用函数和注释做分割，让代码像文章一样有段落，而不是一整块"文字墙"；第三条是主动给自己找边界情况测试，比如空列表、非法输入、极端分数，这些东西恰恰是老师批改作业时会重点验证的地方。
后来我陆陆续续帮好几个同学看过他们交上来的代码，发现大家的问题高度一致：不是不会写，而是想到哪写到哪，缺少结构意识。如果这份作业能让你开始有意识地拆函数、选数据结构、想边界条件，那么它作为"分水岭"的意义就真正达成了。编程能力不是靠看教程堆出来的，是靠一道道题、一次次重构磨出来的，第三次作业就是这条路上一个不大不小的里程碑。
最后再分享一个小技巧：交作业前，把整个程序从头到尾重新读一遍，看到任何一行代码需要想一下才能明白用途，就说明那行注释写得不清楚。我在那次作业的注释上花的时间，比我写代码的时间还多，但正是这种"回头看"的习惯，让我在后续课程里少踩了很多坑。
