看到“基于JSP的学生考勤管理系统任务书”这个项目标题，我的第一反应是：又是一批计算机专业同学要为课程设计头秃了。JSP + Servlet + JDBC + MySQL，这套组合几乎是中国高校Java Web课程的经典标配，也是很多人第一次接触完整Web项目时会撞上的综合大作业。
这篇博文我想从“任务书”三个字切入，把事情讲透：任务书上的那点需求描述，到底在考察哪些能力？技术选型为什么十年了还是这套？数据库该建几张表才算合理？考勤记录从签到到出报表，背后究竟跑了多少道逻辑？最后还会附上我这些年帮同学排查项目时遇到的高频问题，以及验收答辩时的经验。内容尽量照顾新手，但也会保留一些偏实战的细节。
1. 任务书拆解：从一页纸到可执行的系统架构
1.1 任务书的真实意图：不是工具，是脚手架
先说个很多人理解偏了的地方。任务书虽然只有几页纸，但它写的不是“请开发一套考勤系统”这么一句话，而是通过需求描述，逼着你把大学三年学过的知识串起来。
学生考勤管理系统天然自带完整的业务闭环：有用户概念（管理员、教师、学生）、有权限控制（不同角色看到不同页面）、有核心业务逻辑（发布考勤、签到、请假审批）、有数据统计（出勤率、旷课次数）、还有附带的数据维护（学生信息管理、课程管理）。这个业务模型的好处是：足够简单，不需要复杂的领域知识；又足够完整，能覆盖Web开发全链路要求。
从考核角度看，老师通过这个项目重点检查四项能力：数据库设计是否规范（建了几张表、主外键关系是否合理）；Java后端基本功（Servlet生命周期是否理解、JDBC操作用没用PreparedStatement）；页面与后端交互（表单提交、跳转、参数传递）；项目整体组织（分包是否清晰、代码是否讲究）。想清楚这些，再看任务书里“界面美观、功能完整、代码规范”这类套话，就知道真正要下功夫的地方在哪里了。
1.2 需求分级：把“必须做”和“可以做”分开
拿到任务书第一件事，不是铺开写代码，而是做需求分级。我建议用三层结构来拆解任务书中的功能描述：
第一层是核心功能，不做就交不了作业。包括：登录与角色权限管理（管理员、教师、学生三种身份）；学生信息管理（增删改查、导入导出属于加分项）；课程管理（课程、班级、教师的关联关系）；考勤记录（教师端录入或标记，学生端查看）；考勤统计报表（按课程维度统计出勤率）。这些功能没有商量的余地，任务书里一定会写明。
第二层是进阶功能，属于“做了加分、不做不扣分”的弹性区间。比如请假审批流、按日期范围筛选考勤记录、数据导出Excel、修改密码、头像上传。如果时间充裕，优先补这一部分，因为答辩时这是拉开差距的点。
第三层是亮点功能，属于自己给自己加戏的部分。比如二维码签到、微信消息通知、按周自动汇总邮件。这一层看个人水平，技术上有把握再碰，不要为了亮点而牺牲核心功能的稳定性。
另一个容易被忽略的指标是技术指标。任务书中的“基于B/S模式”“采用JSP+Servlet+JavaBean+JDBC技术”翻译过来就是：基于浏览器访问，前后端不分离，业务逻辑封装在Java类中，七层数据库操作，不使用框架。部分任务书会要求“不得使用前端框架”，这其实是在考察原生JavaScript和JSP标签的使用能力。合理区分核心需求与技术约束，才能避免后面返工。
2. 技术选型复盘：为什么经典JSP方案依然值得做
2.1 为什么是JSP：教学任务背后的技术逻辑
每次看到有人吐槽“都什么年代了还用JSP”，我都理解，但不太赞同放在课程设计这个语境下评判。JSP早就不适合做现代互联网项目了，这是事实。但课程设计的核心目标从来不是“用最先进的技术做一个产品级应用”，而是把Java Web里那几个核心知识点做一次系统性验证。
JSP的价值在于它把请求处理链路暴露得非常清楚。你在页面上写一个<form action="LoginServlet" method="post">，提交后Servlet如何调用doPost、如何获取参数、如何跳转，这整条链路是可视化的。换成Spring Boot + Vue之后，框架把所有细节都藏起来了，学生反而会丢失对整个流程的认知。很多我接触过的同学，框架用得很溜，但问起“JSP和Servlet什么关系”“Session存在哪里”却答不上来，其实就是缺了这层基本功。
这个项目用JSP还有一层好处：JSP + Servlet的天然缺陷会倒逼你写出更规范的代码。比如JSP页面里不宜写大量Java代码，于是你会自然想到封装JavaBean、抽公共DAO、用JSTL标签替代脚本片段。这些经验在以后迁移到Spring MVC时是直接可用的，因为Spring MVC的V层本质上是JSP思想的延续。
如果你对这个方案还有疑虑，可以从“任务书要求”角度来想：作业是交老师验收的，不是上线给真实用户用的。稳定、规范、讲得清楚，比选型新潮重要得多。
2.2 环境版本与项目目录的黄金组合
我推荐一套用了很多年的稳定性组合，虽然版本不是最新的，但恰好都能在主流教程和同学之间找到共识：
- JDK：1.8
- 容器：Apache Tomcat 8.5（Servlet 3.1规范）
- 数据库：MySQL 5.7
- 驱动：mysql-connector-java 5.1.49或8.0.x
- 开发工具：Eclipse IDE for Java EE，或者IDEA Ultimate + 手动配置Tomcat
为什么特意强调版本组合？因为JSP项目是出了名的“版本敏感”。比如Tomcat 10把包名从javax.servlet改成了jakarta.servlet，直接把大量旧项目搞到编译不通过。新手如果随手装了最新的Tomcat 11，然后照着五年前的教程写代码，光是导包就要浪费一个晚上。
项目目录结构方面，遵循MVC分层创建src下的包：
com.example.pojo：实体类（Student、Teacher、Course、Attendance）com.example.dao：JDBC操作类（接口与实现分离）com.example.service：业务逻辑层（可选，小项目可以直接由Servlet调DAO）com.example.servlet：控制层（接收请求、调服务、转发）com.example.filter：过滤器（编码处理、登录拦截）com.example.util：DBUtil、字符处理等工具类
WebContent目录下，建议按页面归属划分子目录：admin、teacher、student，再加一个公共的common目录放头部尾部公共页面。这样写的时候路径管理轻松很多，后面部署排错也可以从容定位。
3. 数据库设计与核心模块实现
3.1 六张表的设计逻辑与关系约束
学生考勤系统的表设计，不建议只建三张表（用户表、学生表、考勤表）。因为任务书里的功能需求——不同角色、不同课程、不同班级、请假记录合并考勤报表——三张表根本覆盖不了。下面这套六表方案我用了很久，覆盖面完整，又不会复杂到让新手崩溃：
- t_user（用户表）：id、username、password、role（1管理员 / 2教师 / 3学生）、status、create_time
- t_student（学生表）：student_no（学号）、user_id（外键关联用户）、name、class_id（外键关联班级）、gender、phone、email
- t_teacher（教师表）：teacher_no（工号）、user_id、name、title（职称）、phone
- t_class（班级表）：class_id、class_name（如“软件2101”）、major（专业）、grade（年级）
- t_course（课程表）：course_id、course_name、teacher_id、class_id、week_day（如“周一”）、start_time、end_time、classroom
- t_attendance（考勤表）：att_id、course_id、student_no、att_date、status（正常/迟到/缺勤/请假）、check_time
- t_leave（请假表）：leave_id、student_no、course_id、reason、start_date、end_date、leave_status（待审批/已通过/已驳回）、apply_time、approve_time
设计时几个关键决策点值得展开：
第一，用户表与教师表/学生表为什么要分离？因为登录只需要username+password+role，而教师和学生还有各自的专属属性（工号、学号、职称、班级）。如果全部挤在一张user表里，字段一半为空，既浪费又难看。用user_id关联，登录后凭用户表里的id去对应的业务表里拿详情信息，逻辑清爽。
第二，t_attendance表为什么要用course_id + student_no + att_date做唯一索引？因为这是业务上天然的约束条件：同一门课同一天同一个学生只有一条考勤记录。这个唯一键在任务书里不会写，但你没有加的话，学生重复签到就会产生多条脏数据，报表统计直接崩。
核心建表SQL（简化版）可以这样参考：
CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(64) NOT NULL, role INT NOT NULL COMMENT '1-管理员 2-教师 3-学生', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE t_class ( class_id INT PRIMARY KEY AUTO_INCREMENT, class_name VARCHAR(50) NOT NULL, major VARCHAR(50), grade VARCHAR(10) ); CREATE TABLE t_student ( student_no VARCHAR(20) PRIMARY KEY, user_id INT UNIQUE, name VARCHAR(50) NOT NULL, class_id INT, gender VARCHAR(10), phone VARCHAR(20), email VARCHAR(50), FOREIGN KEY (user_id) REFERENCES t_user(id), FOREIGN KEY (class_id) REFERENCES t_class(class_id) );第三，为什么考勤状态用字符串而非数字？因为业务上只有四种状态：正常、迟到、缺勤、请假，字符串可读性好，避免了维护数字含义映射表。数据量不大，用字符串的存储代价完全可以接受。
3.2 登录认证与角色权限的拦截思路
登录模块是整个系统的门口，绝大多数同学的课程设计都会在这附近出问题。一个标准的处理流程是：
登录表单提交到LoginServlet，Servlet从t_user表查出用户，校验密码。密码在任务书场景里一般不做MD5加密，但如果你写了MD5加密，答辩时一定是加分项。校验通过后，把用户信息（至少包括username、role、id）塞进Session，然后根据role跳转到不同首页：管理员去admin/index.jsp，教师去teacher/index.jsp，学生去student/index.jsp。
理论上流程就这么简单，但很多同学漏了权限拦截。所有人登录后都可以直接访问/admin/manageStudent.jsp，这是大忌。任务书里没写，但答辩时老师一定会问：“如果你是学生，直接在地址栏输入管理员页面路径怎么办？”
标准解法是Filter过滤器，我建议至少配两个：
字符编码过滤器，统一处理POST请求中文乱码：
@WebFilter("/*") public class EncodingFilter implements Filter { public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) { req.setCharacterEncoding("UTF-8"); resp.setCharacterEncoding("UTF-8"); chain.doFilter(req, resp); } }登录拦截过滤器，检查Session：
public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) { HttpServletRequest request = (HttpServletRequest) req; HttpServletResponse response = (HttpServletResponse) resp; HttpSession session = request.getSession(false); String path = request.getRequestURI(); if (path.endsWith("login.jsp") || path.contains("LoginServlet")) { chain.doFilter(req, resp); return; } if (session == null || session.getAttribute("currentUser") == null) { response.sendRedirect(request.getContextPath() + "/login.jsp"); return; } chain.doFilter(req, resp); }这一个过滤器就能拦截所有未登录请求。再在拦截器中加一层角色判断，就可以进一步限制不同角色访问对应目录。这项功能代码量不大，但充分体现了你对“权限控制”这个核心需求的理解水平。
4. 核心页面与关键流程的实现细节
4.1 考勤签到流程的完整链路：发布签到、学生签到、状态落库
考勤功能是系统的心脏，也是任务书里最核心的业务模块，实现时我建议切成三个动作：
教师端发布签到：教师登录后，选课程、选日期，页面上点“发起签到”。Servlet收到请求后，生成为一个4~6位随机数字签到码，把签到码跟课程、日期绑定，存到Session中，并设置有效期。为什么要存Session而不是数据库？因为正常课堂签到场景是即时的，不需要历史记录，签到有效期结束后Session自动过期，代码实现简单。
学生端签到：学生登录后看到当天的课程列表，点“签到”，输入教师公布的签到码。Servlet收到后先校验登录状态，再校验签到码是否匹配，匹配后查数据库确认该学生是否存在漏签到记录，没有就先插入一条status为“正常”的记录，并记录check_time。
状态判定：这是整个系统的关键逻辑。签到状态不能只有“正常”和“缺勤”两种，至少要有“迟到”。建议规则：课程开始时间前5分钟至开始时间后10分钟签到，记为正常；课程开始后10分钟至30分钟内签到，记为迟到；课程开始后30分钟仍未签到，记为缺勤；已通过请假审批的日期，状态为请假。
状态判定规则的常数要写在Java常量或配置类里，不要散落在JSP页面或者Servlet业务代码中，方便调整。判定逻辑放Service层，Servlet只负责接收参数和转发结果。
核心伪代码：
// 签到判定 Date now = new Date(); Date courseStart = course.getStartTime(); long diffMinutes = (now.getTime() - courseStart.getTime()) / 60000; if (diffMinutes <= 10) { status = "正常"; } else if (diffMinutes <= 30) { status = "迟到"; } else { status = "缺勤"; }延迟5分钟规则可以自己定义，但最好把规则说明写在设计文档中，答辩时能讲清楚“为什么迟到门槛是10分钟而不是15分钟”——这正是体现需求分析和业务理解的地方。
4.2 请假审批与状态回滚机制
请假流程虽然不是最核心的功能，但它在考勤系统里承担着与考勤联动的重要角色。建议流程是：学生提交请假申请（填写原因、起始日期、结束日期，选择涉及课程）→ 教师端查看到待审批列表 → 教师通过或驳回 → 如果通过，则该时间段内对应的考勤记录批量更新为请假状态。
这里最容易踩的坑是“状态回滚”的时机。很多同学实现的逻辑是：学生提交请假后就把对应考勤记录改成请假。这样做的结果非常危险，因为教师尚未审批，状态已经变了。合理的实现是：
- 提交请假：只往t_leave表插入一条status为“待审批”的记录，不动考勤表。
- 教师通过审批：事务里执行两个操作，一是更新t_leave的leave_status为“已通过”，二是把t_attendance表中该学生在该时间段对应的考勤记录更新为请假。
- 教师驳回：只更新t_leave的leave_status，不涉及考勤。
这里涉及的事务知识点很重要：更新请假审批状态和更新考勤记录必须在一个数据库事务中完成，否则可能出现请假审批通过但考勤没变的问题。JDBC中手动控制事务的代码如下：
Connection conn = DBUtil.getConnection(); try { conn.setAutoCommit(false); // 1. 更新 leave 状态 // 2. 批量更新 attendance 状态 conn.commit(); } catch (Exception e) { conn.rollback(); } finally { conn.setAutoCommit(true); }这个逻辑在答辩时很出彩，因为大部分人只会写单表增删改查。
5. 联调、验收与常见问题排查实录
5.1 三大高频报错的现场排查
每年帮同学调项目，出镜率最高的报错基本就是下面几个。提前排查，可以少走很多弯路。
第一个：中文乱码。这个问题的出现基本是三个地方没有统一编码导致的。JSP页面头部没有设置pageEncoding="UTF-8"；Servlet读取POST参数前没调用request.setCharacterEncoding("UTF-8")；数据库连接URL没写characterEncoding=UTF-8。这三处必须同时设置，缺一个都可能出现中文显示成问号的情况。排查方向是先看数据库里存进去的是不是乱码，如果数据库里正常而页面显示乱码，就是页面编码问题；如果数据库里就是乱码，就是连接参数问题。
第二个：JDBC驱动加载失败。提示ClassNotFoundException: com.mysql.jdbc.Driver。绝大多数原因是mysql-connector的jar包没有放到WEB-INF/lib目录下。注意，不是随便放，是必须放在Web应用的WEB-INF/lib里，Tomcat启动时才会自动加载。有些人把jar包放在了C:\Program Files\Java\...下，用IDEA配了Library虽然编译能过，但运行时依然报错。
第三个：访问页面404或者跳错页面。这个问题的原因通常是两类。一类是路径写错，<form action="">里的路径、sendRedirect里的路径没有加request.getContextPath()，导致路径缺少项目名。另一类是web.xml或Servlet的@WebServlet注解路径跟表单提交的路径不一致。排查办法是idea的console里看完整报错路径，对照浏览器地址栏里的URL逐字比对。
5.2 验收前的自查清单与答辩准备
任务书写得很清楚，验收时基本是“文档 + 现场演示 + 提问”三个环节。我根据这些年通过的验收经验，整理一份自查清单供参考：
文档类：
- 需求分析说明书里是否画了功能结构图，是否描述了三个角色的操作流程
- 数据库设计文档是否包含ER图、每张表的字段说明、字段类型设计理由
- 测试报告里是否有功能测试用例（覆盖登录、签到、请假、报表四个核心模块）
功能类：
- 登录能不能区分三种角色，错误密码是否提示合理
- 教师是否真的能发起签到、查看学生签到列表、导出出勤统计
- 学生是否真的能签到、查看自己的考勤记录、提交请假
- 管理员是否真的能管理班级、课程、用户，而不是只能看着假数据
演示与答辩类：
- 关闭Tomcat服务端后重新启动，之前的数据是否还在（MySQL独立存储，数据持久化）
- 断网状态是否影响操作（局域网内JSP项目一般不受影响）
- 答辩时被问到“为什么选这张表结构”时，能不能讲出设计理由
有个容易被忽视的点：答辩老师往往会对“数据从哪里来”很敏感。演示时最好准备一套真实的示例数据（至少两个班级、四门课、二十个学生），而不是空表配上一条数据。数据太假会让整个演示缺乏说服力。
6. 写给后来人的几点经验
6.1 时间分配建议：从写代码到验收的节奏把控
如果你现在距离交作业还有两周，我建议按四段分配时间：第一段（3天）完成需求分析、数据库建库、项目骨架搭建，同时在代码里把DBUtil和BaseServlet这类基础工具类写出来。第二段（3天）完成登录、用户管理、学生管理和课程管理。第三段（4天）完成考勤模块和请假模块，这是整个项目最烧脑的部分，时间多花一些值得。第四段（2天）做报表模块、导入导出、写文档、整理答辩稿。
说个真实规律：大部分同学卡在“该做的都做了，但总觉得少点什么”的状态里。这时候最有效的补救不是加功能，而是把现有功能做得更顺滑，比如：客户端的表单是否做了必填校验并给出提示、删除数据时是否有二次确认弹窗、表格数据多时是否做了分页。这些细节在验收时比功能数量更有存在感。
6.2 演示系统时的小技巧
根据我参与验收的经验，演示顺序可以这样安排：先演示登录（体现角色权限）；再演示管理员添加学生和课程（体现数据维护）；然后演示教师发起签到（体现核心业务流程）；接着切换到学生账号去签到（体现多角色协作）；最后回教师端看统计报表，导出一份Excel（体现数据输出）。整个流程走下来，评委看到的是一条完整的业务闭环，而不是零散功能的拼接。
这里分享一个小技巧，很多老师会随手刷新页面或者输入错误的登录信息来测试边界情况。演示前自己先动手把几种异常情况测一遍，比如：学生签到前还没有任何老师发起签到、教师重复对同一节课发起签到、请假日期跨周但选课只选了某一天。能扛住这些测试，比临时加一堆炫酷功能更能证明系统的真实可用性。
防SQL注入这件事我也多提一句：所有SQL操作都使用PreparedStatement预编译，不要在Java代码里用字符串拼接组装SQL。这不仅是为了安全，也是很多老师的扣分点之一。哪怕项目只是课程设计，也要养成好习惯，将来做实际项目时不需要重新学一遍。
说完这些，我给新接触这个项目的同学留一句话：任务书不会告诉你所有的答案，但它早已划定好考察范围。你做的每一张表、写的每一个Servlet、处理过的每一次乱码，都是在把“学过Java”变成“会用Java”。这套涨功力的过程，比最终分数值钱得多。
