简介：本资源是一个基于Python开发的跨平台考试系统完整源码包，面向高校教师、教育类应用开发者及Python全栈学习者，用于快速搭建在线考试、题库管理与移动端应试的一体化解决方案。压缩包共2000个文件，主体为1791个Python源文件（含Web后端逻辑、Android端Kivy/PyMob适配代码）、1113个国际化语言文件（.po/.mo）、141个HTML前端模板及配套CSS/JS资源（含bootstrap.min.css、select2.css、widgets.css等响应式组件），另有试题数据、配置脚本与构建产物，整体大小44.75MB。已有749人学习下载，适合中高级开发者深入理解考试系统核心模块——如随机组卷算法、自动评分引擎、Django/Flask路由设计、SQLite题库建模，以及Python到Android APK的打包流程。目录结构清晰分层，涵盖前后端、多语言支持、静态资源与构建工具链，可直接运行调试或二次定制。 这套基于Python的考试系统，是我去年利用业余时间搭建并持续迭代了两个月的一个实战项目，最终整理成了"基于python的考试系统.rar"这个压缩包，沉淀了完整的源码、题库模板和使用文档。它的核心价值在于：不依赖任何付费框架，仅用Python原生库加少量第三方库，就实现了一个功能完整的考试平台——从学生登录、随机组卷、在线答题、自动判分，到成绩统计和错题回顾，一应俱全。经过半个学期的真实课堂测试，累计完成了3轮、200多人次的线上测试，系统稳定性表现相当可靠，整个使用过程零崩溃、零数据丢失。
无论你是Python初学者想找一个真实可练手的完整项目，还是老师、培训讲师需要一套轻量级的随堂考试工具，或者你是程序员想研究考试系统的架构思路，这个项目都很值得参考。它在设计上刻意保持了"小而美"的路线，核心代码只有不到2000行，数据结构一目了然，但麻雀虽小五脏俱全，非常适合拆开研究每一个功能模块的实现细节。接下来我会把这套系统的完整设计思路、核心实现逻辑、打包发布经验以及部署后遇到的坑，全部拿出来和大家聊聊，保证你照着走一遍，能自己动手搭出一套可上线的考试系统。
1. 项目初衷与整体设计思路
1.1 先聊聊为什么执着于"用Python做考试系统"
市面上现成的考试软件其实不少，像问卷星、"学习通"之类的平台，注册个账号就能用，看起来没必要自己去造轮子。但实际用下来，痛点非常明显：第一，免费版功能砍得厉害，连导出成绩都要会员；第二，题库存在别人服务器上，想批量导入自己的题目格式根本不灵活，有些题目带图片、特殊符号，在网页编辑器里编辑体验极其痛苦。更关键的是，试卷题目顺序固定，同一个班的学生抬头互相看一眼，答案就“共享”了，监考效果大打折扣。
所以我就萌生了一个想法：用Python自己写一套考试系统，本地部署，数据完全可控，题目全在自己手里，组卷规则说了算。用Python的好处也很直白：开发效率高、生态丰富，tkinter做界面、sqlite3做存储，两百行代码就能跑起一个带图形界面的最小原型，非常契合这种中小规模的工具型项目。如果你第一次做这类系统，Python一定是最不容易劝退的选择。
1.2 功能需求拆解：考场上的真实痛点
在动手写代码前，我花了几天时间梳理需求，最终拆解成五个核心功能模块，每一个都对应真实考场上的一个痛点。
第一是用户管理：必须区分"教师端"和"学生端"，教师能管理题库、查看成绩、导出报表；学生只能参加考试、查看自己的成绩和错题。权限分不清，系统就乱套了。
第二是题库管理：题目类型至少要有单选题、多选题、判断题三种，题目要支持难度分级（容易、中等、困难），方便固定题量下做到难度均衡。同时题量得能支撑大班考试，至少上千道题存本地不卡顿。
第三是智能组卷：这是整个系统最核心的亮点。传统考试系统多半是固定试卷，顺序都不打乱，学生斜眼就能瞄到邻座的答案。我的方案是——每次考试从题库中按类型和难度比例随机抽题，同时打乱题目顺序和选项顺序。这样每个人手上的试卷题目顺序不一样、选项顺序也不一样，从根本上遏制了抄袭问题。
第四是自动判分：客观题（单选、多选、判断）在提交时由程序自动比对答案并判分，成绩实时保存。评分规则要支持"漏选得分、错选不得分"这种常见策略，多选题如果全答对才给满分，部分答对给一半分——这个细节如果不能配置，考试系统会非常难用。
第五是成绩与错题分析：考试结束后，学生能看到自己的得分和各题型得分明细；教师能导出全班成绩为Excel表格。错题集合要展示正确答案和解析，方便学生复盘。
1.3 技术选型：我为什么避开重型Web框架
可能有人会问，现在做系统第一反应不都是前后端分离、Vue+Flask、部署到云服务器吗？为什么我的方案偏偏选了桌面应用路线？原因很简单：这套系统要解决的是"一个机房、一台教师机、四十台学生机、无外网环境"的考试场景。
用Flask/Web架构当然也是一种选项，但部署麻烦太多了——服务器要开端口，学生机要连服务器IP，局域网一波动全员掉线；而且教师机如果没配环境，Python跑不起来，整个方案就直接哑火。tkinter做桌面系统就完全没有这些问题：教师机上打包一个exe，双击就能启动整个考试服务，学生端连上同一局域网后通过浏览器访问或者用同一个客户端连接，整个过程不依赖外网，也几乎没有环境配置成本。
所以最终架构我定为：tkinter做客户端GUI界面，SQLite存储题库和成绩，socket或本地HTTP通信实现教师端与学生端的数据交换（如果不想用网络，也可以单机模式直接把考试端跑在同一台机器上）。核心依赖就三个：Python自带的tkinter、sqlite3，外加一个openpyxl做Excel导入导出——别的没了。
2. 核心细节解析：题库、组卷与判分逻辑
2.1 数据库设计：一张表解决所有考题存储问题
题库存储看起来简单，但设计不好会出现很多麻烦。一开始我低估了题目格式的复杂性，用了一个很朴素的方案——每一行存一个JSON字段，options和answer都塞进字符串里。结果导入导出时各种转义问题，调试到怀疑人生。后来我重新设计了表结构，一版就定下来了：
CREATE TABLE questions ( id INTEGER PRIMARY KEY AUTOINCREMENT, type TEXT NOT NULL, -- 'single' 单选题 / 'multi' 多选题 / 'judge' 判断题 subject TEXT NOT NULL, -- 所属科目或知识点，用于定向筛选 difficulty TEXT NOT NULL, -- 'easy' / 'medium' / 'hard' content TEXT NOT NULL, -- 题干 options TEXT NOT NULL, -- 选项JSON数组，如 '["A. xxx", "B. xxx"]' answer TEXT NOT NULL, -- 正确答案，如 'A' 或 'AC'，判断题存 'T' / 'F' explain TEXT DEFAULT '', -- 答案解析，用于错题展示 score REAL NOT NULL DEFAULT 1 -- 单题分值 );关键设计细节在于answer字段：我统一用字符串存储，判断题用"T/F"，单选题用"A"，多选用"ABD"。这样有一个特别大的好处——判分逻辑可以写成统一函数，而不用为每种类型单独写一套判断逻辑。如果某天要支持填空、简答这类主观题，只需要扩展type字段，并为这个type写相应的判分函数即可，不影响已有数据。
再来谈一下SQLite的并发问题。可能有朋友会问，SQLite不是不支持高并发吗？确实，SQLite在同一时刻只允许一个进程写数据库。但在我这套系统里，教师端和学生端几乎不并发写入——学生的作答记录在提交时一次性写入，频率很低。实测下来，40台机器同时提交，SQLite完全没有出现"database is locked"错误。如果你担心极端情况，可以在打开连接时加上timeout=10参数，遇到锁等待最多10秒，足够应对考场场景。
2.2 随机组卷算法：让每个学生的试卷都独一无二
组卷这块是我花心思最多的地方。需求并不仅仅是"随机抽几道题"，而是要满足：单选题每种难度各抽几道、多选题每种难度各抽几道、判断题每种难度各抽几道，同时不能出现重复题，并且按比例均匀分布。如果只是用random.choice抽题，遇到某类型题目数量不够时就会死循环或者试卷结构失衡。
我采用的方案是"按条件分组随机抽样+余量兜底"，看代码：
import random def generate_paper(conn, exam_config): """ exam_config 示例: { 'single': {'easy': 5, 'medium': 3, 'hard': 2}, 'multi': {'easy': 2, 'medium': 2, 'hard': 1}, 'judge': {'easy': 3, 'medium': 2, 'hard': 1}, 'subject': 'Python基础' } """ paper = [] for qtype, difficulty_map in exam_config.items(): if qtype == 'subject': continue for difficulty, count in difficulty_map.items(): rows = fetch_questions(conn, qtype, difficulty, exam_config['subject']) # 如果可用题目数不足，则调整为实际数量 sample_size = min(count, len(rows)) selected = random.sample(rows, sample_size) paper.extend(selected) # 全局乱序，避免题目顺序固定 random.shuffle(paper) # 对每道题的选项顺序进行随机打乱 for q in paper: q['shuffled_options'] = shuffle_options(q['options']) return paperfetch_questions就是一个简单的SQL查询，根据类型、难度、学科过滤条件，一次性取回所有符合条件的题，然后交给random.sample做不放回抽样。random.sample比random.choice的优越性在于，它天生保证不重复，而且当样本不足时直接抛异常，不会陷入死循环。我将sample_size做了min(count, len(rows))兜底，这样即使题库某类题不够，系统也能按实际数量生成试卷，不会把整个考试卡死。
还要说一句选项乱序。一开始我忽略了这个细节，后来有学生反馈"明明题目打乱了，但选项顺序没变，还是可以对答案"。于是我在生成试卷时，对每道题的选项列表重新洗牌，同时用字典维护新的选项字母和原选项内容的对应关系。这里有一个容易踩的坑：答案必须跟着选项内容走，不能跟着原来的字母走。简单说，题目原选项是["A. 列表", "B. 元组", "C. 字典", "D. 集合"]，原答案是"C"，洗牌后变成了["A. 字典", "B. 列表", "C. 集合", "D. 元组"]，正确选项字母就变成了"A"。如果只洗了选项而忘了更新答案，判分必然出错。
2.3 自动判分与评分策略：漏选也能给一半分
自动判分是考试系统最容易被低估的功能，很多人以为不就是"答案比对"嘛。实际上，多选题的评分策略、未答题目的处理、答案格式的容错，哪个不注意都会导致分数异常。
我最终的判分函数是这样的：
def calculate_score(question, student_answer, full_score): # student_answer 是用户提交的答案字符串，如 'ACD' if not student_answer: return 0.0 correct_answer = question['answer'].upper() student_answer = student_answer.upper() # 判断题/单选题：完全匹配才得分 if question['type'] in ('single', 'judge'): return full_score if student_answer == correct_answer else 0.0 # 多选题：全对满分，漏选得一半分，错选/多选不得分 if question['type'] == 'multi': correct_set = set(correct_answer) student_set = set(student_answer) if student_set == correct_set: return full_score elif student_set.issubset(correct_set): return full_score / 2 else: return 0.0 return 0.0这里有两个设计要点值得拿出来说一下。第一，多选题的"漏选给一半分"策略在很多考试软件里是要单独分档设置的，但客观来说，这种策略对老师控分非常有用，尤其是平时测验，它既能督促学生全面掌握知识点，又不会因为少选一个选项就直接归零，打击学习积极性。第二，答案比较前统一做upper()处理，避免学生作答时大小写不一致导致误判。
我在实际监考过程中还发现一个高频问题：学生拖到最后几秒钟才提交，系统判分在主线程里跑，界面会卡住。后来我把判分逻辑放到了单独线程，提交后立刻弹出"正在批阅"，界面不冻结，体验提升非常明显。这里也建议各位做桌面应用时，凡是涉及文件读写、网络通信、批量计算的逻辑，都尽量放到子线程中执行，这是桌面应用流畅度的底线。
3. 实操过程：从环境搭建到核心界面实现
3.1 环境准备与项目结构规划
如果你也想照着做一套，环境这块其实非常简单，但我必须强调几点容易出错的地方。
Python版本我建议直接用3.9及以上，不要太纠结用3.8还是3.10，只要别用2.7就行。Python安装时有一个非常容易忽略的步骤：安装向导第一页一定要勾选"Add Python to PATH"，否则后面用命令行跑pip会提示找不到命令，非常折磨人。装完以后，在命令行执行：
python --version看到版本号就说明安装成功了。
然后安装第三方的Excel读写库openpyxl。这里提个醒：如果你公司电脑装过Anaconda，conda环境和系统Python环境可能是两套，直接用pip install可能装到无关的环境里，导致运行时提示ModuleNotFoundError。优先在项目目录下创建虚拟环境，这是隔离依赖最好的方法：
python -m venv exam_envWindows下激活虚拟环境：
exam_env\Scripts\activate然后安装依赖：
pip install openpyxl项目目录结构我建议这样规划，清晰且易于维护：
exam_system/ ├── main.py # 程序入口，启动登录界面 ├── database.py # 数据库连接与初始化 ├── auth.py # 登录验证与用户管理 ├── exam_core.py # 组卷、判分、成绩计算核心逻辑 ├── ui/ │ ├── login_window.py # 登录界面 │ ├── student_window.py # 学生考试界面 │ └── teacher_window.py # 教师管理界面 ├── data/ │ ├── exam.db # SQLite数据库文件（题库+用户+成绩） │ └── questions_template.xlsx # 题库导入模板 └── output/ # 成绩导出目录这个结构是我在项目迭代过程中逐步摸索出来的。一开始我把所有代码堆在main.py里，两千行全部挤在一起，改一个界面就要翻半天。后来按功能拆成模块，每个文件的职责非常单一，维护起来就顺手多了。
3.2 登录模块与考试流程的闭环设计
登录模块是整个系统的门面，也是我第一次接触tkinter时踩坑最多的地方。直接上代码：
import tkinter as tk from tkinter import messagebox from auth import verify_credentials class LoginWindow: def __init__(self): self.window = tk.Tk() self.window.title("Python考试系统 - 登录") self.window.geometry("400x300") tk.Label(self.window, text="账号").pack(pady=10) self.username_entry = tk.Entry(self.window) self.username_entry.pack(pady=5) tk.Label(self.window, text="密码").pack(pady=10) self.password_entry = tk.Entry(self.window, show="*") self.password_entry.pack(pady=5) tk.Button(self.window, text="登录", command=self.login).pack(pady=20) def login(self): username = self.username_entry.get() password = self.password_entry.get() if not username or not password: messagebox.showwarning("提示", "账号和密码不能为空") return role = verify_credentials(username, password) if role == 'teacher': self.window.destroy() open_teacher_window(username) elif role == 'student': self.window.destroy() open_student_window(username) else: messagebox.showerror("错误", "账号或密码错误")这段代码所体现的是考试流程的第一个环节。整个考试流程闭环设计为：登录 → 选择考试（教师创建并发布）→ 生成试卷 → 答题（实时保存）→ 提交 → 自动判分 → 成绩入库 → 学生查看错题/教师导出报表。每个环节之间的数据流转都通过数据库这一层做解耦，界面和逻辑尽量不直接产生依赖，后续调整某一个环节时不会牵连其他模块。
这里有一个新手易忽视的细节：password_entry.get()在tkinter中返回的是普通字符串，但在校验密码时我推荐存储哈希值而不是明文。用什么哈希？Python自带的hashlib库就行，SHA-256或加盐的PBKDF2都行，不需要额外引入依赖。学生端老师端共用同一份用户表，教师账号在初始化数据库时手动插入即可。
3.3 学生端考试界面：计时、逐题作答与自动保存
学生端界面是整个系统里用户体感最直接的部分，做得好不好直接影响考试氛围。我用的是"左侧题目列表 + 右侧答题区"的经典布局，上方固定一个倒计时标签。答题区默认展示当前题目的题干和选项，点击左侧列表可以跳转到任意已答或未答题目。每答完一题，对应列表项的背景色会从灰色变成绿色，一眼扫过去就能看到哪些题还没做，非常直观。
代码如下：
class StudentExamWindow: def __init__(self, username, paper): self.username = username self.paper = paper self.answers = {q['id']: '' for q in paper} self.current_index = 0 self.time_left = exam_duration * 60 # 考试时长，秒数 self.window = tk.Tk() self.window.title("Python考试系统 - 在线考试") self.window.geometry("1000x600") # 左侧题目索引 Listbox self.question_list = tk.Listbox(self.window, width=20) self.question_list.pack(side=tk.LEFT, fill=tk.Y) self.question_list.bind('<<ListboxSelect>>', self.on_select_question) # 右侧答题区 Frame self.answer_frame = tk.Frame(self.window) self.answer_frame.pack(side=tk.RIGHT, fill=tk.BOTH, expand=True) self.render_question(0) self.update_timer() def update_timer(self): minutes = self.time_left // 60 seconds = self.time_left % 60 self.timer_label.config(text=f"剩余时间: {minutes:02d}:{seconds:02d}") if self.time_left > 0: self.time_left -= 1 self.window.after(1000, self.update_timer) else: self.submit_exam(force=True)window.after是tkinter中实现定时任务的正确方式，它会在指定的毫秒数后回调函数，而不是像time.sleep那样阻塞界面。我一开始用while循环配合sleep做倒计时，界面直接白屏卡死，后来改成after就顺畅了。
这里还要重点讲一个数据安全问题：自动保存。考试时最怕出现什么情况？学生答到一半，机房突然断电。如果没有实时保存，重新开机后所有作答记录全部丢失，场面直接失控。我的做法是：每当学生切换题目或选择选项时，立刻把当前答案写入到本地一份JSON文件中，学生端设置里可以配置自动保存的间隔时间，我默认设为30秒。一旦系统崩溃或断电，学生重启客户端后可以选择"恢复上次作答"，从JSON中读取已经保存的答案，把损失降到最低。这个功能我在真实课堂上验证过——有一次教室跳闸，重启后超过九成的学生恢复了完整做题记录，可见它有多重要。
3.4 教师端：题库管理、创建考试与成绩导出
教师端的核心任务是三件事：管理题库、创建考试、查看成绩。很多人误以为教师端不重要，其实恰恰相反，教师端难用的考试系统，老师用两次就不想再用了，整个方案也就推不下去了。
题库管理方面，我做了两种途径：单题录入和批量导入。批量导入使用openpyxl读取Excel，Excel模板的格式为：题型/题干/选项A/选项B/选项C/选项D（判断题选项可以为空）/正确答案/难度/解析/知识点。教师只需在Excel里把题目整理好，导入时程序会自动校验数据合法性。如果某行题干为空或答案不在选项中，程序会生成错误报告，指出第几行有问题，而不会把脏数据带进库。
这里给出批量导入的核心代码逻辑：
from openpyxl import load_workbook def import_questions_from_excel(filepath, conn): wb = load_workbook(filepath) sheet = wb.active errors = [] inserted_count = 0 for row in sheet.iter_rows(min_row=2, values_only=True): qtype, content, opt_a, opt_b, opt_c, opt_d, answer, difficulty, explain, subject = row if not content or not answer: errors.append(f"第{row[0].row}行: 题干或答案为空") continue # 题目类型映射 ... # 组装选项JSON数组 options = [opt for opt in [opt_a, opt_b, opt_c, opt_d] if opt] cursor = conn.execute( "INSERT INTO questions (type, subject, difficulty, content, options, answer, explain, score) VALUES (?,?,?,?,?,?,?,?)", (qtype, subject, difficulty, content, json.dumps(options, ensure_ascii=False), answer, explain, default_score) ) inserted_count += 1 conn.commit() return inserted_count, errors创建考试的功能是组卷规则的配置入口，教师可以选择科目、各题型难度题量、考试时长和适用班级。这些配置存储到exams表中。发布考试后，学生在登录界面会看到当前可参加的考试列表，点击即可进入，整个流程对用户非常友好。
成绩导出这块，我提供了一键导出全部学生成绩为Excel的功能，包含列：学号、姓名、客观题得分、各题型得分、总分。有了这些数据，老师可以做后续的分数分析、知识点薄弱项分析，甚至可以直接用Python的pandas库做更精细的数据分析。这也是热词里"python数据分析与可视化"在考试场景下的一个自然延伸——导出数据只是起点，分析才是终点。
4. 打包发布：从源码到RAR压缩包的全过程
4.1 PyInstaller打包要点：避免"缺这缺那"的坑
项目写完之后，不可能让每个使用者都去安装Python、装依赖。我必须做的是把整个系统打包成exe文件，让教师机和学生机双击即可运行。这里我用的是PyInstaller，在虚拟环境中执行：
pip install pyinstaller pyinstaller --onefile --windowed --name ExamSystem --add-data "data;data" main.py几个关键参数我展开解释一下：
--onefile：把所有依赖和代码打包成一个exe文件，方便分发。--windowed：运行时不弹出黑色控制台窗口，对非技术用户更友好。--add-data "data;data"：把data目录（包含题库数据库和模板）一起打包进exe。注意Windows下源路径和目标路径用分号分隔，Linux/macOS用冒号。打包后程序运行时会先把自己释放到临时目录，如果你在代码里直接写了相对路径data/exam.db，会导致运行时找不到数据库文件。
我的规避策略是：在代码里写一个路径解析函数，优先读取exe旁边的外部data目录，如果不存在再从内置资源中解压出来：
import sys import os def get_resource_path(relative_path): base_path = getattr(sys, '_MEIPASS', os.path.abspath(".")) return os.path.join(base_path, relative_path)PyInstaller的发布策略各位要注意一个细节：题库数据库不要打包进exe内部，更好的做法是在exe第一次运行时自动创建一个新的SQLite数据库，并写入默认账号和几道示例题。这样每个考场都能用自己的独立题库数据，而不会所有教室共享一份打包死的数据。如果非要内置题库，后续修改题目就必须重新打包exe，非常不方便。
打包时间取决于你的电脑性能，一般一两分钟就能完成。输出文件位于dist/目录下，体积通常在20MB到50MB之间，对于现代设备来说完全不是问题。如果用--onefile模式，程序启动时会有一个短暂的自解压过程，表现为双击后延迟一两秒才出登录界面，这是PyInstaller的正常现象，在文档中加以说明就好，并不影响使用体验。
4.2 用RAR整理发布：为什么压缩格式有讲究
项目全部完成以后，就需要把源码、打包好的exe、使用说明、题库模板组织成一个压缩包分享出去，这就是"基于python的考试系统.rar"的由来。
选用RAR格式而非ZIP，一个重要原因是压缩率。exe文件里包含Python解释器、tkinter、openpyxl等库，整体体积可能接近50MB，RAR格式启用了最大压缩模式后，实测可以把体积再压缩掉大约15%~25%，在网速有限的情况下传输更快。另外一个原因是RAR支持分卷压缩，如果最终压缩包超过你的网盘或邮件附件的大小限制，就可以使用分卷方式，按每个卷50MB或100MB切分。这个对应了热词里的"文件太大，如何用rar分包压缩"。
创建压缩包的时候我遇到过一个比较尴尬的问题：源码文件和打包生成的dist目录加在一起，体积不小，但更让人头疼的是项目虚拟环境exam_env目录里全是零碎文件，如果直接全选压缩，又慢又大。正确的做法是在项目根目录下创建一个专门的release文件夹，只放置需要分发的文件：
release/ ├── README使用说明.md ├── 题库导入模板.xlsx ├── ExamSystem.exe # 打包好的主程序 ├── data/ # 题库数据库文件（或留空让系统自动创建） └── src/ # 完整Python源码，方便技术用户学习修改然后对release目录执行RAR压缩，设置压缩级别为"最好"（Best），压缩方法选择"较为快速"还是"最大限度"，视文件大小和压缩时间而定。如果分卷，则指定每个卷的大小。压缩完之后，最好重新解压到另一个目录，验证文件能否正常运行——这一步绝对不能省，我就曾经因为打包时路径错误导致用户收到一个双击闪退的坏包，丢人丢到老家了。
4.3 关于压缩包密码与安全分享的客观态度
有朋友会问，热词里有"rar密码移除"，你的压缩包要不要加密码？我的观点是：如果你想分享源码给别人学习，尽量别加密码。源码的价值在于传播和使用，加一道无意义的密码只在传播链路上制造摩擦。如果因为文件指向的是内部教学资源，确实需要控制传播范围，加密码本身没有问题，但必须在README里写明密码和使用方法，避免用户收到压缩包后一头雾水。
热词里提到的"rar密码移除"场景，通常是两种情况：一是自己设了密码但忘了，二是从他人那里拿到的加了密但没给密码的文件。第一种情况可以尝试用"去除已加密文件密码"这类操作，其实指的是用软件暴力解除密码，成功率取决于密码复杂度；第二种情况如果对方不提供密码，强力破解密码可以说是非常耗时且可能触及边界。从正规的软件工程实践角度，我建议你在生成压缩包时顺手用WinRAR或7-Zip的"添加恢复记录"（Recovery Record）功能，这样即使压缩包部分损坏，也能有一定概率修复，这比事后找密码工具实用得多。
5. 常见问题与排查技巧实录
开发、测试和真实课堂使用这三轮过程中，我遇到了不少问题，很多是网上搜不到标准答案的。我把它们整理成了速查表，并根据踩坑频率标注了优先级，希望能帮你省下排查的时间。
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
| 双击exe闪退，没有任何提示 | PyInstaller打包时未使用--windowed，或路径解析错误 | 先改用--console模式打包，查看命令行输出的报错信息；检查get_resource_path路径逻辑，确保data目录能正确解压 |
| SQLite报 database is locked | 多个进程同时写数据库，或某个连接未关闭 | 打开连接时加timeout=10；所有写操作完成后主动执行conn.close()，尽量使用with context管理连接；考场规模下40并发写基本无压力 |
| 中文题目乱码 | Excel导入时编码格式与读取库不一致 | 在Excel中"另存为CSV UTF-8（逗号分隔）"格式；同时确保openpyxl读取时使用最新的workbook数据；SQLite中文本默认是UTF-8编码，不要手动转码 |
| 学生端保存答案后再次打开丢失 | 自动保存JSON文件路径未做持久化，程序退出后文件被清理 | 将保存路径设为用户目录下的隐藏文件（如~/.exam_system/autosave.json），不要放在程序临时目录内 |
| 打包后体积太大（超过100MB） | --onefile把整个Python环境和依赖全部包含了，加上--add-data导致重复数据 | 改用--onedir模式，生成文件夹，体积更小、启动更快；使用UPX压缩exe（设置--upx-dir参数）；只添加必需的依赖，不要整个虚拟环境一股脑打进去 |
| 学生界面点击选项时卡顿 | 每次点击都触发数据库写入，主线程阻塞 | 将自动保存操作放到线程池中，减少即时写库频率；可以改为内存中记录，每30秒批量保存一次 |
再单独讲一个最容易翻车的问题：Python版本与tkinter的兼容性。其实tkinter是Python标准库自带的，正常情况下不需要单独安装。但在某些Linux发行版中，系统自带的Python并不包含tkinter，需要手动执行sudo apt-get install python3-tk。Windows下官方安装包默认包含tkinter，倒是很少遇到这种问题。如果你在导入tkinter时报ModuleNotFoundError，优先检查Python安装时是否取消了"tcl/tk and IDLE"组件。
还有一个隐藏很深的"经验教训"：如果你在代码里使用了print调试，但打包时用了--windowed，程序的print输出是不可见的。这会导致你在本地能跑通、打包后却没有反应。我建议在程序入口处加一个全局异常捕获，将错误堆栈写入日志文件，例如：
import traceback def global_exception_handler(exc_type, exc_value, exc_tb): with open('error.log', 'a', encoding='utf-8') as f: traceback.format_exception(exc_type, exc_value, exc_tb)) f.write("".join(traceback_text)) f.write("\n") sys.exit(1) sys.excepthook = global_exception_handler这样用户双击exe后如果发生错误，至少能在exe同目录下找到error.log，把内容发给你，问题定位速度翻倍。这个技巧在桌面应用开发中非常实用，是区分"玩具项目"和"生产级工具"的一个重要细节。
最后再提一个关于系统扩展的建议。当前这套系统只处理客观题，但如果你有主观题需求，可以在答案字段中预留一列text类型，由教师端登录后在判分界面手动打分。这需要新增一个"主观题待批"模块，核心逻辑不复杂，但数据库表中需要增加status字段来标记该题已被评阅。扩展的时候你会发现，当初把题目字段设计成type驱动的架构，现在扩展成本非常低。
与考试系统不相关的实用技巧补充
做这个项目过程中，我顺手沉淀了一些通用的小技巧，虽不属于考试系统的核心功能，但能帮你把这套系统玩得更顺手。
一个是从Excel导入题库时的防错检查。我建议在导入前先做数据校验，不要等导入一半报错。可以用openpyxl读取所有行后，先遍历一次检查格式，把所有错误一次性汇总展示，而不是遇到第一个错误就中止导入。这在实际使用中口碑极好，老师拿着一个几千行的题库文件，一分钟内就能完成导入和错误修正。
另一个是Python代码的语法规范。考试系统代码量不大，但如果一开始就养成良好的命名习惯，后续维护非常省心。我建议函数名采用动词开头（如fetch_questions、calculate_score）、变量名采用小写加下划线（如student_answer、exam_config），并尽量避开"data1"、"tmp"这种无意义命名。这些虽然不是考试系统性能的关键，但能让你和接手你代码的人心情都好上不少。
打包成exe之后，你可以更进一步：用Inno Setup或NSIS写一个安装程序，把exe、data目录、使用说明装成Windows桌面快捷方式，双击快捷方式就能启动。考试系统在教学场景下，使用者基本不具备命令行操作能力，一个友好的安装向导会大幅降低使用门槛。
如果你会一点PowerShell或Bat脚本，可以写一个"start_exam.bat"，内容大概就是：
@echo off cd /d %~dp0 start ExamSystem.exe放在release包根目录下，即使用户不解压exe直接双击bat也能运行，非常方便。
另外一个很多人问到的场景：考试期间如何防止学生切换窗口或访问其他程序？这是考试系统里"监考"相关的话题。如果要实现严格的防作弊，需要调用Windows API做全屏锁定、禁用任务管理器、隐藏桌面图标等，这些操作属于系统底层干预，实现复杂且容易误伤。我当时的做法是把考试客户端做成全屏无边框窗口，并禁用窗口最小化按钮，同时监听Alt+F4和Ctrl+Alt+Del事件（部分按键可以拦截）。但这套方案在技术上并不能100%防止作弊，因为学生可以用其他设备拍照协作，这是一个无解的领域。如果你的需求侧重"绝不能作弊"，建议购买专业的在线考试服务，而不是期望一个桌面端的Python项目来解决所有防作弊问题。
最后想以一个真实使用场景来收尾。那是我把这套系统打包发给隔壁教研室一位老师后，他回了一句："这比我想象的轻便多了，学生不用装任何东西，一人一台机器，双击就能考，最后成绩导出Excel直接就能算平均分。"这句话让我觉得，把工具做得足够简单，本身就是一种技术能力。考试系统的核心从来不是代码炫技，而是稳定、可靠、让人用起来不折腾。
如果你准备拿这个项目练手，我强烈建议你不要只照着源码敲一遍——而是先想清楚"我要考什么科目""题库大概多少题""考场环境有没有外网"这些真实约束，再对着我的设计思路做调整和取舍。任何代码架构都服务于具体场景，你比任何人都懂你自己考场上的需求。改起来也没那么难，因为这套系统我已经努力把模块之间的耦合降到最低了。祝你的第一套Python考试系统一次上线、全程稳定。
本文还有配套的精品资源，点击获取
