基于Python的课堂点名系统设计与实现：Flask+SQLite+ECharts全流程

“基于Python的点名系统的设计与实现”，这个题目看上去像一本教材的目录，但在毕业设计里，它是典型的“看着简单、做起来有细节”的项目。我每年都会碰到拿到这个题目的同学，一开始都觉得不就是点个名嘛，结果真正动手才发现，最难的不是写登录页，而是怎么把点名、统计、可视化、导出整条链路串起来，让系统真的能在一个课堂场景里用起来。这篇就把这个项目的完整设计思路、数据库结构、核心代码和踩坑记录一次性讲清楚，适合正在筹备毕设的同学，也适合想用Python快速搭建一个带可视化后台的读者参考。

这类项目本质上是一个“管理信息系统”的小型样板，它没有电商系统那么庞杂，也没有算法题那么烧脑，但它覆盖了软件开发最典型的一整套流程：前端页面、后端路由、数据库建模、业务逻辑、图表分析和文件导出。这意味着它既能用来展示基本功，又能在论文和答辩里承担一个真实完整的业务场景。只要把里面几个关键细节想清楚，整套系统是可以从零跑通的。

1. 项目概述与需求分析

1.1 这个题目看起来简单，难在哪

点名的场景所有人在学校都经历过，但需求一旦落到“系统设计”层面，就必须回答几个比表面功能更深入的问题。

第一个是数据模型问题。一个学生可以上多门课，一门课有多个学生，点名记录还带着日期和状态。这种关系天然适合关系型数据库，用一张“学生表”加一张“课程表”再加一张“出勤记录表”的结构去表达，后续不管是查某个人的缺勤次数，还是算某门课某一天的整体出勤率，都只是标准SQL的事情。

第二个是业务规则问题。同一天同一门课不能重复点名，随机点名不能点到已经点过的学生，缺勤记录和出勤记录要能同时存在。这些规则看似简单，但如果只在界面上做一层判断，很难避免并发操作或重复提交带来的脏数据，所以一定要在数据库层加约束。

第三个是数据呈现问题。老师要的不是一个“谁来了谁没来”的列表，而是一眼能看到出勤率趋势、哪些课缺勤严重、某个学生最近有没有翘课。这部分决定了系统到底要不要做可视化，而不是做一个看起来像课程作业的CRUD页面。

如果前期不把这三块拆清楚，写代码的过程会非常痛苦。我早期接手类似项目时也图省事，把签到记录直接拼到一个字段里，用逗号分隔日期，结果到了要统计“某门课最近一个月出勤率”的时候，只能写一堆字符串匹配代码，最后忍无可忍推翻重来。所以这里非常建议：先画功能清单，再设计表结构，最后才动手写路由和页面。

1.2 技术选型背后的权衡

毕设环境下做技术选型，首要目标不是“最流行”，而是“最稳、最好讲”。这里我推荐一套经过实测的组合：Python + Flask + SQLite + Bootstrap + ECharts。

选Python的理由很直观：语言简单，答辩的时候能把核心代码讲清楚；生态完整，Excel处理有pandas，图表渲染有ECharts，用户认证有flask-bcrypt。如果选用其他语言也不是不行，但往往会因为框架生成的代码太多，答辩时一问“这段代码为什么这么写”就答不上来。

后端框架优先选Flask而不是Django。Django功能强大，但目录结构、ORM、中间件、Admin后台一堆东西，对于点名系统这种小规模项目来说完全是过度设计。Flask的路由简洁到一眼看穿，非常适合这种教学性质的系统。

数据库推荐SQLite。很多同学担心SQLite不够正式，但实际使用中，单文件、零配置、支持标准SQL，对毕设演示来说非常稳。如果导师要求必须用MySQL，改动成本也很低，只需要换掉数据库连接部分，核心SQL语句几乎不用动。

前端方面不建议再引入Vue、React、Node这类工程化工具链，否则会把注意力从业务逻辑转移到环境配置上。用Bootstrap搭后台框架，原生JavaScript加ECharts做交互，已经足够好用。

数据可视化方面用ECharts是因为它中文文档完善，折线图、柱状图、热力图都支持，而且通过CDN引入后不需要额外构建工具。整体技术选型可以汇总成下面这张表：

这套组合下，一个熟悉Python的人从零开始搭，两到三周就能完成一个完整可演示的版本。关键在于把精力集中在业务逻辑和演示效果上，而不是耗在环境配置里。

1.3 功能模块怎么拆分

功能拆分要兼顾“够用”和“有内容可写”，太少了显得单薄，太多了又做不完。我这里建议按下面几个模块来开发：

• 管理员登录：用户名密码登录，密码哈希存储，使用session保持登录状态
• 学生信息管理：学生信息的增删改查，支持从Excel批量导入
• 课程管理：维护课程基本信息，包括课程名称、授课教师
• 点名操作：按名单逐一点名，标记出勤或缺勤；随机点名提问，保证不重复
• 统计展示：按课程、按日期查看出勤率，按学生查看个人出勤明细
• 数据可视化：出勤趋势折线图、班级出勤率柱状图
• 数据导出：将点名记录和统计结果导出为Excel文件
• 系统初始化：首次运行自动创建数据库表结构和默认管理员账号

这个清单看起来简单，但每一个模块都可以在论文里扩展成一个章节。尤其是“不重复随机点名”和“出勤率统计”这两点，是答辩时最容易被追问的地方，务必把逻辑想透。

2. 系统架构与数据库设计

2.1 项目目录结构

一个清晰的目录结构能让开发过程少踩很多坑，也能让导师在查看代码时一眼找到关键文件。推荐的目录如下：

attendance_system/ ├── app.py # 主应用，所有路由都在这 ├── init_db.py # 数据库初始化脚本 ├── requirements.txt # 依赖清单 ├── static/ │ ├── css/ │ │ └── bootstrap.min.css │ ├── js/ │ │ ├── echarts.min.js │ │ └── jquery.min.js │ └── uploads/ # 临时Excel上传目录 ├── templates/ │ ├── base.html # 公共布局 │ ├── login.html # 登录页面 │ ├── index.html # 首页 │ ├── student_list.html │ ├── course_list.html │ ├── attendance.html # 点名页面 │ └── statistics.html # 统计可视化页面 └── data/ └── attendance.db # SQLite数据库，运行时生成

这个目录的分工很明确：templates管页面展示，static管静态资源，data存数据库文件。把数据库文件单独放在data目录里，后续做备份整个文件夹拷贝就行，不用去翻项目根目录。

实际上很多同学写毕设的时候喜欢把所有文件都扔在根目录，图一时方便，后面却会越来越乱。我比较推荐的写法是：路由集中在app.py，页面模板用模板继承的方式放在base.html中统一管理；如果后期功能膨胀了，再考虑用Flask蓝图拆分子模块，但点名系统这个体量暂时不需要。

2.2 数据库表结构设计

这是整个项目的核心基础，比页面效果重要得多。根据需求，需要设计四张表：管理员表、学生表、课程表、出勤记录表。下面是完整SQL，可以直接在init_db.py里执行。

-- 管理员表 CREATE TABLE users ( id INTEGER PRIMARY KEY AUTOINCREMENT, username TEXT NOT NULL UNIQUE, password TEXT NOT NULL, create_time TEXT DEFAULT CURRENT_TIMESTAMP ); -- 学生表 CREATE TABLE students ( id INTEGER PRIMARY KEY AUTOINCREMENT, student_no TEXT NOT NULL UNIQUE, name TEXT NOT NULL, class_name TEXT NOT NULL, phone TEXT, create_time TEXT DEFAULT CURRENT_TIMESTAMP ); -- 课程表 CREATE TABLE courses ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, teacher TEXT, create_time TEXT DEFAULT CURRENT_TIMESTAMP ); -- 出勤记录表 CREATE TABLE attendance ( id INTEGER PRIMARY KEY AUTOINCREMENT, student_id INTEGER NOT NULL, course_id INTEGER NOT NULL, date TEXT NOT NULL, status INTEGER DEFAULT 1, create_time TEXT DEFAULT CURRENT_TIMESTAMP, UNIQUE(student_id, course_id, date), FOREIGN KEY (student_id) REFERENCES students(id), FOREIGN KEY (course_id) REFERENCES courses(id) );

每张表的设计都值得解释一下。

users表用来做系统登录。username加了 UNIQUE 约束，避免出现重名账号；password字段存储的不是明文密码，而是走哈希之后的字符串，这样即使数据库文件泄露，也不会直接暴露密码。

students表的重点是student_no，也就是学号。学号是每个学生在学校体系里唯一的编号，这里加上 UNIQUE 约束后，批量导入学生Excel时如果遇到重复学号，数据库就能直接拒绝，避免脏数据进入系统。class_name字段可以单独拎出来当班级维度的统计依据。

courses表很简单，就是课程信息和任课教师姓名，它是点名操作时的业务上下文。

attendance表是整张设计的灵魂。student_id和course_id分别指向学生和课程，date存的是“YYYY-MM-DD”这种格式的文本日期，status用 1 表示出勤、0 表示缺勤。最关键的是 UNIQUE 约束，它保证了同一名学生在同一门课的同一日期只能有一条记录，这是硬性的重复点名防线。

这里很多同学会犯一个典型错误：把date存成带时分秒的完整时间戳。不要这么做，因为点名统计是按天聚合的，一旦混入时间戳，去重难度就会变大。用“YYYY-MM-DD”纯文本格式还有一个好处，就是字符串排序的结果和日期排序完全一致，SQL里的ORDER BY date可以直接使用。

2.3 实体之间是如何关联的

整张表的关联关系其实只有一条主线：students和courses是一对多的关系，一个学生可以上多门课，一门课有多个学生，这种多对多关系通过attendance表来记录每次点名的具体事实。

出勤记录表里有两组外键：student_id指向学生表，course_id指向课程表。这使得“查某门课的今天点名情况”只需要对 attendance 表做一次筛选，再连接学生表补上姓名学号班级就够了。

这种设计的好处体现在统计上。比如要查“张三这学期在《Python程序设计》课上缺了几次”，只需要一条普通的JOIN查询；要查“某门课最近10天的出勤率趋势”，也只需要对 attendance 表做一次分组聚合。反过来说，如果当初偷懒把点名状态存成学生表里的一个文本字段，这些统计都不可能用SQL直接完成。

3. 核心功能实现与代码解析

3.1 登录与权限控制

登录功能是系统的门面，也是论文中“系统安全性设计”的主要支撑点。这里要处理的核心问题有两个：一是密码不能明文存数据库，二是登录后的状态要保持。

密码处理直接用flask-bcrypt，它封装了加盐哈希，用法非常简单。不要在数据库里直接存MD5，也不要用自创的加密算法，bcrypt最大的价值是它会自动附加随机盐，相同密码在不同用户账号下产生的哈希值不同，即使数据库泄露，要逆向出原始密码的难度也大得多。

from flask import Flask, render_template, request, redirect, url_for, session from flask_bcrypt import Bcrypt import sqlite3 app = Flask(__name__) app.secret_key = "please-change-this-in-production" bcrypt = Bcrypt(app) def get_db(): conn = sqlite3.connect("data/attendance.db") conn.row_factory = sqlite3.Row return conn @app.route("/login", methods=["GET", "POST"]) def login(): if request.method == "POST": username = request.form.get("username") password = request.form.get("password") db = get_db() user = db.execute( "SELECT * FROM users WHERE username = ?", (username,) ).fetchone() db.close() if user and bcrypt.check_password_hash(user["password"], password): session["user_id"] = user["id"] session["username"] = user["username"] return redirect(url_for("index")) return render_template("login.html", error="用户名或密码错误") return render_template("login.html")

这段代码的核心点是用session保存登录状态。Flask默认的session是加密签名的cookie，只要设置好secret_key，用户就无法篡改里面的用户ID。这里额外提一句：secret_key在生产环境应该用复杂随机字符串，而不是示例里的固定值。

在具体实现时，还要加一个简单的装饰器来做登录拦截，比如@app.before_request钩子，或者在每个页面函数开头检查session.get("user_id")是否存在。这个细节不难，但很必要，否则用户直接输入index地址就能跳过登录。

3.2 学生信息导入与维护

学生信息的增删改查本身不复杂，一个标准的表单单页就能搞定。这里最值得讲的是批量导入Excel。课堂场景下老师手里普遍有一份全班名单，如果系统要求一条条手工录入，体验可以说是灾难级的。

用 pandas 读取Excel文件后，配合 SQLite 的executemany可以一次性插入全部学生。关键点在于学号唯一索引配合INSERT OR IGNORE，让重复数据自动跳过而不是报错中断。

import pandas as pd @app.route("/import_students", methods=["POST"]) def import_students(): f = request.files["file"] df = pd.read_excel(f, engine="openpyxl") db = get_db() cursor = db.executemany( """ INSERT OR IGNORE INTO students (student_no, name, class_name, phone) VALUES (?, ?, ?, ?) """, [ ( row["学号"], row["姓名"], row["班级"], row.get("手机号", ""), ) for _, row in df.iterrows() ], ) db.commit() total = len(df) ignored = total - cursor.rowcount db.close() return f"导入完成，共{total}条，其中{ignored}条因学号重复被忽略"

这里我用的列名是学号、姓名、班级，所以Excel模板里的表头要严格对应。row.get("手机号", "")的作用是，如果Excel里没有“手机号”这一列，代码也不会报错，而是默认填一个空字符串。这个小写法能避免很多Excel模板格式不一致带来的崩溃。

为什么用INSERT OR IGNORE而不是先查一遍再插入？因为后者需要逐行查询判断存在性，效率显然更低，而且代码量更大。数据库的 UNIQUE 约束本身就能保证重复不会发生，INSERT OR IGNORE只是在遇到重复时选择跳过而不是报错。这个设计理念在答辩时很有讲头：让数据库来保证数据完整性，而不是靠应用层人肉判断。

3.3 点名与签到逻辑实现

点名是系统的核心业务，分两种场景。第一种是“随机点名提问”，老师按下按钮，系统从今天还没被点到的人里随机抽一个；第二种是“名单点名”，老师按名单逐人核对，对没来的学生标记缺勤。

两种场景都绕不开一个前提：不能重复。比如《Python程序设计》这门课今天已经点名了张三，那么再点随机点名时，张三就不应该出现在候选池里。实现这个效果最干净的方式是在SQL里排除今天已有记录的学生。

@app.route("/api/absent_students/<int:course_id>") def absent_students(course_id): db = get_db() today = datetime.now().strftime("%Y-%m-%d") students = db.execute( """ SELECT s.id, s.name, s.student_no, s.class_name FROM students s WHERE s.id NOT IN ( SELECT student_id FROM attendance WHERE course_id = ? AND date = ? ) """, (course_id, today), ).fetchall() db.close() return jsonify([dict(row) for row in students])

这段SQL是整个点名功能的基石。下面解释它的逻辑：首先从学生的全量名单里取数据，然后用NOT IN子查询找出今天在这门课上已经有了点名记录的学生ID，剩下的人就是你真正还没点的学生集合。

随机点名则可以直接用 SQL 随机排序，配合上面的未点名筛选，实现一个真正“不会重复”的随机功能。

@app.route("/api/random_call/<int:course_id>") def random_call(course_id): db = get_db() today = datetime.now().strftime("%Y-%m-%d") student = db.execute( """ SELECT s.id, s.name, s.student_no, s.class_name FROM students s WHERE s.id NOT IN ( SELECT student_id FROM attendance WHERE course_id = ? AND date = ? ) ORDER BY RANDOM() LIMIT 1 """, (course_id, today), ).fetchone() db.close() if not student: return jsonify({"message": "今天已全部点完"}) return jsonify(dict(student))

这里用ORDER BY RANDOM() LIMIT 1直接让SQLite完成“随机取一行”，不需要先把几十个学生load到Python列表里再用random.choice。虽然数据量小的时候两者差别不大，但这样写更简洁，答辩时也能说清楚算法思路。

点名结果的落库操作是插入一条出勤记录。这里要处理重复点名的情况，靠数据库的 UNIQUE 约束来拦截。

from datetime import datetime @app.route("/mark", methods=["POST"]) def mark(): student_id = request.form.get("student_id", type=int) course_id = request.form.get("course_id", type=int) status = request.form.get("status", 1, type=int) today = datetime.now().strftime("%Y-%m-%d") db = get_db() try: db.execute( """ INSERT INTO attendance (student_id, course_id, date, status) VALUES (?, ?, ?, ?) """, (student_id, course_id, today, status), ) db.commit() except sqlite3.IntegrityError: db.close() return jsonify({"message": "该生今天已点名，请勿重复操作"}), 400 finally: db.close() return jsonify({"message": "ok"})

这段代码里status通过request.form.get("status", 1, type=int)获取，默认值是1，也就是出勤；如果传 0 就是缺勤。点名页面可以做成一个“点名表”，每一行是一个学生，旁边有“出勤”和“缺勤”两个按钮，点击后调用这个接口。也可以通过下方代码实现：

核心逻辑就一句话：每次点名都往 attendance 表插入一条记录，如果插入失败，说明今天已经点过这个人，直接在数据库层面拒绝，不需要应用层判断。

3.4 出勤统计与可视化

统计功能要做到两种维度：一是按课程看每天的整体出勤率趋势，二是按单个学生看个人出勤明细。第二种用一个简单的SQL查询就能实现，不需要单独讲。第一种稍微复杂一点，需要分组聚合。

后端接口返回JSON数据，前端再用ECharts画折线图。接口的关键代码：

@app.route("/api/statistics/<int:course_id>") def api_statistics(course_id): db = get_db() rows = db.execute( """ SELECT date, COUNT(*) AS total, SUM(status = 1) AS present FROM attendance WHERE course_id = ? GROUP BY date ORDER BY date """, (course_id,), ).fetchall() db.close() return jsonify({ "dates": [r["date"] for r in rows], "rates": [ round(r["present"] / r["total"] * 100) if r["total"] else 0 for r in rows ] })

这里用到SUM(status = 1)有点技巧。在SQLite里，布尔表达式的结果是0或1，SUM就是对“出勤”状态求和，这样统计出勤人数只需要一条SQL，不需要把查询结果循环一遍再到Python里累加，减少代码量也减少出错概率。

前端页面用最简单的方式来渲染，核心就是初始化ECharts实例后，把接口返回的数据填进去：

<div id="trendChart" style="width:100%;height:450px;"></div>

fetch("/api/statistics/3") .then(res => res.json()) .then(data => { const chart = echarts.init(document.getElementById("trendChart")); chart.setOption({ title: { text: "出勤率趋势" }, xAxis: { type: "category", data: data.dates }, yAxis: { type: "value", min: 0, max: 100, axisLabel: { formatter: "{value}%" } }, series: [ { name: "出勤率", type: "line", smooth: true, areaStyle: {}, data: data.rates } ] }); });

为什么选择折线图？因为出勤率趋势的本质是时间序列对比，折线图能直观展示上升和下降的走势。如果搞一堆柱状图也能看，但远不如折线图在答辩现场的效果好。

这里有个小细节：图表容器一定要有明确的高度，不能是默认的0。很多同学写完前端页面，发现ECharts不显示，打开开发者工具一看，div高度是0，给容器设置了style="height:450px"之后就一切正常。

3.5 导出点名单和统计结果

老师的另一个刚需是把点名单打印出来或者存档。系统提供数据导出功能后，录完一次课就能直接生成Excel，不用再对着屏幕手动整理。

导出功能用 pandas 构建表格，再用io.BytesIO生成内存中的Excel文件返回给前端下载。

from flask import Response import io @app.route("/export/<int:course_id>") def export(course_id): db = get_db() rows = db.execute( """ SELECT s.name, s.student_no, s.class_name, a.date, a.status FROM attendance a JOIN students s ON s.id = a.student_id WHERE a.course_id = ? ORDER BY a.date DESC """, (course_id,), ).fetchall() db.close() df = pd.DataFrame([dict(r) for r in rows]) df["status"] = df["status"].map({1: "出勤", 0: "缺勤"}) output = io.BytesIO() with pd.ExcelWriter(output, engine="openpyxl") as writer: df.to_excel(writer, index=False, sheet_name="点名记录") output.seek(0) return Response( output.read(), mimetype="application/vnd.openxmlformats-officedocument.spreadsheetml.sheet", headers={"Content-Disposition": "attachment; filename=attendance.xlsx"} )

一个关键点是必须把数据先写入io.BytesIO，再把对象交给Response。如果直接return df.to_excel(...)返回的是None，浏览器什么都不会发生。正确流程是：pandas生成Excel到内存，然后把文件的字节流返回给前端，浏览器通过Content-Disposition识别为下载文件而不是直接在页面里显示二进制乱码。

这个导出功能看似不起眼，但在评论文的“系统实用性”时非常加分，因为老师会认为你考虑了真实使用场景。

4. 部署，测试与答辩演示

4.1 环境搭建与首次运行

把系统跑起来需要准备Python环境和依赖库。建议使用虚拟环境，避免污染全局Python环境，也方便把依赖打包给别人复现。

python -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate pip install flask flask-bcrypt pandas openpyxl

依赖安装完毕后，先创建数据库。推荐单独写一个init_db.py脚本，只做建表和初始化管理员账号这件事，不要放在app.py里每次启动都执行一次。

import sqlite3 import os from flask_bcrypt import Bcrypt os.makedirs("data", exist_ok=True) db = sqlite3.connect("data/attendance.db") db.executescript(""" CREATE TABLE IF NOT EXISTS users ( id INTEGER PRIMARY KEY AUTOINCREMENT, username TEXT NOT NULL UNIQUE, password TEXT NOT NULL, create_time TEXT DEFAULT CURRENT_TIMESTAMP ); -- 其他表结构省略，参考2.2节SQL """) password = input("请输入默认管理员密码: ") hashed = Bcrypt().generate_password_hash(password).decode("utf-8") db.execute( "INSERT INTO users (username, password) VALUES (?, ?)", ("admin", hashed), ) db.commit() db.close()

注意，如果需要在脚本里使用flask_bcrypt，不要直接from app import app，因为那样会连带执行app.py里的app.run()，导致初始化还没完成就启动了服务。要么把app.run()包在if __name__ == "__main__":里面，要么像上面一样单独创建 Bcrypt 实例，和主应用解耦。

数据库初始化完成后，启动主程序：

python app.py

浏览器访问http://127.0.0.1:5000，用刚才设置的管理员账号登录就能看到系统首页。

4.2 造数据比写功能更花心思

很多同学答辩的时候打开页面，学生列表是空的，图表也没有数据，老师看到的第一眼就没有兴趣了。所以演示前一定要准备好一套看起来真实的模拟数据。

具体的做法是：先用Excel导入50个学生，手动创建两门课程，然后写一个脚本向attendance表填充过去两周的点名记录。脚本的逻辑很简单，遍历最近10个工作日，为每一天随机缺勤几个人，再判断工作日是上午还是下午，让每门课的出勤率保留在85%到100%之间浮动，这样ECharts画出来的折线图会有一条真实的起伏曲线。

为什么要让出勤率有波动？因为如果一个系统的图表是一条平直完美线，观众反而会觉得是造假的。合理的数据波动才能呈现真实课堂规律，比如有些同学周五缺勤明显，这就是一个能讲故事的洞察。

单靠手工在界面上生成几十条记录不现实，所以我推荐写一个一次性脚本直接往数据库插入。反正attendance表结构很单纯，只要保证student_id、course_id、date三者不重复并且date取的是真实日期字符串就行了。

4.3 答辩演示顺序建议

答辩演示的核心原则是“讲业务场景，而不是点按钮”。按照下面这个顺序展示，逻辑会非常顺。

第一步登录系统，强调密码是哈希加密存储的。第二步进学生名单，现场演示一次Excel批量导入，让老师看到系统不用逐条手录；导入时的重复数据会被自动忽略。第三步打开某门课的考勤页面，先展示“今天未点名名单”，然后点击随机点名，强调不会点重复的原理。第四步现场标记一两名学生缺勤，立刻切到统计页面看折线图的变化，说明数据是实时的。最后一步点击导出，把点名记录生成Excel，快速打开展示表头和数据。

整个过程控制到10分钟以内。不要每个按钮都点一遍，而是让评委跟着你的业务讲解一步一步走。演示之前记得重启服务、清掉浏览器缓存，防止上一次登录的session残留影响现场效果。

5. 常见问题与避坑记录

5.1 高频问题排查表

开发过程中会遇到的问题基本上都是固定的，我把最常见的整理成一张速查表，按表格排查效率最高。

5.2 容易被忽略的三个细节

第一个是时区问题。SQLite 里的date('now')返回的是UTC时间。如果你在点名记录里用了date('now')，在中国时区下，晚上8点之后的操作会被记录成“明天”，这会让第二天的统计全部错位。正确的做法是统一用 Python 层的datetime.now().strftime("%Y-%m-%d")生成日期字符串，而不是依赖数据库函数。

第二个是数据库目录权限。有些实验室电脑对项目根目录的写入权限有限制，SQLite 数据库文件创建失败会导致整个系统无法启动。建议在初始化脚本里加一句os.makedirs("data", exist_ok=True)，先把目录建出来，再连接数据库。

第三个是状态码处理。向/mark接口提交重复点名记录时，因为数据库的 UNIQUE 约束会触发sqlite3.IntegrityError，程序会跳到异常分支。这里一定要给出明确的错误提示，而不是直接让整个页面变成500。用户体验和系统稳定性，往往就是通过这类小细节体现的。

6. 扩展方向与总结建议

6.1 把点名系统从“能用”做到“像样”

如果想让这个毕设项目在内容深度上更进一步，有几个很自然的扩展方向。

第一个是学生微信端查询。做一个简单的微信小程序，让学生输入学号查看自己的出勤记录和缺勤次数。这个方向正好蹭上“小程序”的热点，而且不复杂：后端只需要提供一个按student_no查询的JSON接口，小程序端负责展示列表。论文里可以增加一章“移动端查询功能设计”，让系统从纯管理端变成教学互通的完整闭环。

第二个是签到方式升级。可以给每个学生生成一个专属二维码，点名前老师先展示二维码，学生扫码完成地理位置校验后自动签到。这样能解决代签问题，也能把系统的“防作弊”能力写进论文创新点。

第三个是大数据思维引入。当系统里积累了一个学期、多个班级的出勤数据后，可以分析每周几缺勤最多、哪些时间段学生状态最差、是否有“连锁缺勤”现象。不一定要用到分布式框架，但可以体现统计分析和数据挖掘思路，让毕设的“大数据”元素落到实处。

第四个是数据可视化增强。除了出勤率折线图，还可以用热力图展示“哪些班级在哪些星期几缺勤严重”。ECharts 的热力图组件效果比较漂亮，一张图就能覆盖多个维度，答辩时视觉冲击力很强。

这些扩展不需要全部实现，选一个最有把握的做深做透就够了。很多时候宁愿只做一个亮点，也不要每个功能都浅尝辄止。

6.2 给正在写毕设的一些实在话

写基于Python的点名系统的核心是“闭环”两个字。数据从录入到展示再到导出，完整走通，系统才算真正可用。老师看的不在于你有多少个页面，而在于你的系统能不能解决实际场景里的问题。

论文结构上，不要照搬模板。先写需求分析和用例图，再写数据库设计，最后写核心功能实现。把“随机点名不重复”和“出勤率统计”这两条业务逻辑讲透，代码不用贴太多，但必须把设计思路表达清楚。尤其要讲清楚为什么使用数据库约束来防止重复点名，而不是在应用层做判断。

最后分享一点经验。这类项目最怕的不是代码写不完，而是演示现场掉链子。我实操的经验是，提前把数据库文件备份一份，把依赖环境固定下来，把演示数据造好，比临时再写十个扩展功能都有用。检查一遍所有接口能不能跑通，检查一遍页面刷新后session是否正常，检查一遍导出文件能否成功下载，这些细节才真正决定了答辩最终效果。