基于JSP与Servlet的学生信息管理系统：分层架构与请求链路实战

简介这是一份面向Java Web初学者与课程实践者的学生信息管理系统完整项目源码以JSP与Servlet为核心技术栈配合MVC分层思路实现学生与班级信息的增删改查、登录验证等功能适合用于课程设计、毕业设计参考或Java Web入门练手。压缩包共576个文件约2.75MB包含156个html、132个css、105个png、79个js等前端页面与静态资源20个java源文件及对应class文件承载Servlet与DAO业务逻辑另有jsp页面、sql初始化脚本、jar依赖与项目配置文件结构完整可直接导入容器运行。已有999人学习下载。项目覆盖JSP动态页面、Servlet请求处理、JDBC数据库操作、HTTP请求响应流程、会话管理与Tomcat部署等知识点并附数据库建表脚本便于读者对照源码理解MVC各层职责、梳理请求流转路径是快速上手Java Web开发流程的实践案例。1. 从一份“能跑但不敢交”的课设说起每年到了课程设计交付季总有一批学生信息管理系统的项目卡在同一个地方功能列表写得满满当当增删改查都能点但一问到“请求是怎么从浏览器走到数据库的”“会话是怎么保住的”“并发改同一条记录会不会互相覆盖”就答不上来。这套基于 JSP 与 Servlet 的学生信息管理系统解决的正是这个问题——它不追求花哨的前端框架而是把 Java Web 最核心的请求响应链路、会话管理、分层结构和数据库访问讲透让读者交得出一份结构完整、经得起追问的方案。适合正在做 Java Web 课程设计、毕业设计选题偏管理系统方向的学生也适合需要一份可参考的 Servlet 分层落地模板的初级开发者。下面按需求、设计、实现、避坑、验收的顺序展开。2. 需求与选型为什么这套系统坚持用 JSP Servlet 打底2.1 先把角色和用例钉死再谈技术学生信息管理系统的需求看起来简单真正落到设计上第一件要做的事是把角色和用例钉死而不是急着建表。通常的做法是划分三类角色管理员、教师、学生。管理员负责账号与班级的基础数据维护教师负责成绩录入与查询学生只能查看自己的信息与成绩。用例层面核心是学生档案的增删改查、班级与院系的关联维护、成绩的录入与统计、登录鉴权与权限隔离。这里有个容易被忽略的点很多课设把“权限”做成登录后所有页面都能访问只是菜单不同。这在答辩时是硬伤。合格的负责人会把权限校验下沉到 Servlet 层每个受保护的请求都过一次会话与角色判断而不是靠前端隐藏按钮。需求阶段就要明确哪些 URL 属于哪个角色可访问形成一张权限矩阵后面写过滤器时直接照着矩阵实现。需求文档里还要写清非功能约束单机部署、MySQL 存储、支持几十人并发访问、页面响应在两秒内。这些约束决定了后面的技术选型不能太重也不需要引入分布式组件。2.2 技术选型Servlet 做控制JSP 做视图JDBC 做持久选型上控制层用 Servlet视图层用 JSP 配合 JSTL 标签持久层用原生 JDBC 加手写 DAO数据库用 MySQL。这套组合的理由很实在Servlet 是 Java Web 的规范底座请求映射、生命周期、会话管理都是标准能力答辩时能讲清楚service方法里发生了什么JSP 虽然老但配合 JSTL 的c:forEach、c:if能把列表渲染讲明白且不需要额外构建工具JDBC 手写 SQL 让读者真正理解连接、语句、结果集三件套而不是被 ORM 屏蔽掉细节。如果换成 Spring Boot 加 MyBatis功能一样能实现但课设的考察点往往在“你是否理解请求链路”框架会把这条链路藏起来。用 Servlet 打底等于把黑匣子拆开给你看。当然代价是要自己处理连接释放、字符编码、SQL 注入防护这些琐事这恰恰是后面避坑章节要重点讲的。2.3 工程结构按层分包别按页面分包工程目录按层划分而不是按页面划分。常见的错误是建一堆student_add.jsp、student_list.jsp平铺在根目录Servlet 也堆在一个包里。正确的做法是按职责分包src/ com.school.sims controller/ StudentServlet, ScoreServlet, LoginServlet service/ StudentService, ScoreService dao/ StudentDao, ScoreDao, BaseDao entity/ Student, Score, User filter/ EncodingFilter, AuthFilter util/ DBUtil, PageUtil WebContent/ WEB-INF/ views/ student_list.jsp, student_edit.jsp web.xml static/ css, jsWEB-INF/views下的 JSP 不能被浏览器直接访问必须经 Servlet 转发这样视图层就被保护起来了。BaseDao放公共的连接获取与关闭逻辑子类 DAO 只写各自的 SQL。这个结构在答辩时一眼就能看出分层意识也是后面所有实现的地基。3. 总体设计四层结构与请求链路的职责划分3.1 分层职责与一次请求的完整走向系统分四层视图层、控制层、业务层、持久层。一次“查询学生列表”的请求走向是这样的浏览器发起GET /student?actionlistEncodingFilter先统一设置请求与响应编码AuthFilter校验会话中是否有登录用户且角色允许通过后进入StudentServlet的doGet根据action参数分发到list方法方法调用StudentService.queryByPageService 做参数校验与分页计算后调用StudentDao.findPageDAO 拼 SQL、取连接、执行、封装成ListStudent返回Servlet 把结果放进request属性forward到student_list.jspJSP 用 JSTL 遍历渲染成表格。这条链路里每一层只做自己的事Servlet 不写 SQLDAO 不碰HttpServletRequestService 不关心页面长什么样。职责一旦串味后面改一个字段要动三四个文件维护成本立刻上来。我一般会在设计文档里画一张分层职责表把每层的输入、输出、禁止事项写清楚评审时对着表逐条过。层输入输出禁止事项视图层 JSPrequest/session 属性HTML写 Java 业务逻辑、连数据库控制层 ServletHTTP 请求参数转发或重定向拼 SQL、做复杂计算业务层 Service实体或参数实体或结果集直接操作 request持久层 DAO查询条件实体列表处理页面跳转3.2 数据库设计三张主表加两张关联表数据库设计围绕学生、班级、成绩、用户、课程展开。学生表存学号、姓名、性别、班级外键等班级表存班级名与院系成绩表存学生外键、课程外键、分数用户表存登录名、密码哈希、角色。学生与班级是多对一学生与课程通过成绩表形成多对多。建表时主键用自增整型学号加唯一索引外键加索引避免联表查询全表扫描。CREATE TABLE student ( id INT PRIMARY KEY AUTO_INCREMENT, sno VARCHAR(20) NOT NULL UNIQUE COMMENT 学号, name VARCHAR(50) NOT NULL, gender TINYINT DEFAULT 0, class_id INT, INDEX idx_class (class_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE score ( id INT PRIMARY KEY AUTO_INCREMENT, student_id INT NOT NULL, course_id INT NOT NULL, score DECIMAL(5,2), UNIQUE KEY uk_stu_course (student_id, course_id), INDEX idx_student (student_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;uk_stu_course这个唯一键很关键它从数据库层面防止同一学生同一课程被录入两条成绩比在代码里查一遍再插入可靠得多。字符集统一用utf8mb4避免姓名里出现生僻字或特殊符号时乱码。分数用DECIMAL而不是FLOAT避免浮点误差导致统计对不上。3.3 会话与权限模型过滤器兜底矩阵驱动登录成功后把用户对象放进HttpSession键名统一为loginUser。权限校验不写在每个 Servlet 里而是由AuthFilter统一拦截。过滤器里维护一张“URL 前缀到允许角色”的映射比如/student允许管理员和教师/score允许教师和管理员/profile允许学生。请求进来先取会话没有登录用户就重定向到登录页有用户但角色不匹配就返回 403 页面。会话超时在web.xml里配置通常设 30 分钟。这里有个细节过滤器放行静态资源和登录页否则登录页自己都被拦掉形成死循环。权限矩阵要写进设计文档答辩时能直接指着矩阵说“这条规则对应过滤器里哪一行”比空谈“做了权限控制”有说服力得多。4. 核心模块实现从登录鉴权到分页查询的落地代码4.1 登录鉴权密码哈希与会话写入登录模块的 Servlet 接收用户名密码调用 Service 校验校验通过后把用户写入会话并重定向到首页。密码不能明文存库注册或初始化时用 SHA-256 加盐哈希。校验时对输入密码做同样处理再比对。// LoginServlet.doPost String username request.getParameter(username); String password request.getParameter(password); User user userService.login(username, password); if (user null) { request.setAttribute(error, 用户名或密码错误); request.getRequestDispatcher(/WEB-INF/views/login.jsp).forward(request, response); return; } request.getSession().setAttribute(loginUser, user); response.sendRedirect(request.getContextPath() /student?actionlist);userService.login内部先按用户名查用户查不到直接返回 null查到后对输入密码加盐哈希再与库中值比对。注意这里不要分别提示“用户不存在”和“密码错误”统一提示能减少账号枚举风险。会话写入用setAttribute重定向用sendRedirect而不是转发避免刷新页面重复提交登录表单。这套写法在课设里足够答辩时能讲清“为什么用重定向”就是加分项。4.2 学生信息 CRUDServlet 分发与 DAO 参数化学生模块用一个 Servlet 处理多个动作通过action参数分发。新增和修改共用一个表单页靠是否有id区分。DAO 层全部使用PreparedStatement参数化杜绝字符串拼接 SQL。// StudentDao.findPage public ListStudent findPage(String keyword, int offset, int limit) throws SQLException { String sql SELECT s.*, c.class_name FROM student s LEFT JOIN clazz c ON s.class_id c.id WHERE s.name LIKE ? OR s.sno LIKE ? ORDER BY s.id DESC LIMIT ?, ?; try (Connection conn DBUtil.getConnection(); PreparedStatement ps conn.prepareStatement(sql)) { String like % keyword %; ps.setString(1, like); ps.setString(2, like); ps.setInt(3, offset); ps.setInt(4, limit); try (ResultSet rs ps.executeQuery()) { ListStudent list new ArrayList(); while (rs.next()) { list.add(mapRow(rs)); } return list; } } }try-with-resources保证连接、语句、结果集按逆序自动关闭这是 JDBC 里最容易翻车的地方后面避坑章节会展开。LIKE的通配符拼在 Java 侧而不是 SQL 里参数仍然走占位符注入风险被挡住。LEFT JOIN让没有班级的学生也能查出来class_name为空时页面显示“未分班”。分页的offset和limit由 Service 根据页码算好传入DAO 不关心页码语义。4.3 分页查询与列表渲染PageUtil 与 JSTL 遍历分页逻辑抽成PageUtil持有当前页、每页条数、总记录数算出总页数和偏移量。Service 先查总数再查当前页数据两个结果一起返回给 Servlet。public class PageUtilT { private int pageNo 1; private int pageSize 10; private int total; private ListT rows; public int getOffset() { return (pageNo - 1) * pageSize; } public int getTotalPages() { return (total pageSize - 1) / pageSize; } // getter/setter 省略 }JSP 侧用 JSTL 遍历page.rows底部渲染页码链接链接带上keyword和pageNo参数保证翻页时搜索条件不丢。这里常见的坑是页码越界用户手动改 URL 里的pageNo为负数或超过总页数Service 里要做钳制pageNo小于 1 取 1大于总页数取总页数。列表页还要处理空结果显示“暂无数据”而不是一张空表格这些细节在验收演示时很显眼。4.4 成绩录入与统计事务与聚合查询成绩录入涉及“先判断是否已存在再插入或更新”两步操作要放在一个事务里否则并发下可能插出重复记录。Service 层手动管理事务关闭自动提交执行完提交异常回滚。public void saveScore(int studentId, int courseId, BigDecimal score) throws SQLException { Connection conn null; try { conn DBUtil.getConnection(); conn.setAutoCommit(false); scoreDao.upsert(conn, studentId, courseId, score); conn.commit(); } catch (SQLException e) { if (conn ! null) conn.rollback(); throw e; } finally { if (conn ! null) { conn.setAutoCommit(true); conn.close(); } } }upsert用INSERT ... ON DUPLICATE KEY UPDATE依赖前面建的唯一键一条语句搞定插入或更新比先查后写少一次往返。统计查询用AVG、MAX、MIN加GROUP BY course_id算出每门课的平均分与最高最低分结果封装成统计对象传给 JSP 渲染。事务这块答辩常被问“如果提交前断电怎么办”答案是 InnoDB 的 redo 日志保证已提交的落盘、未提交的回滚讲到这里基本就稳了。5. 避坑与排查这套系统最容易翻车的五个点5.1 中文乱码现象是列表姓名变问号现象新增学生后列表里姓名显示为???或者搜索中文关键词查不到数据。原因通常是三处编码不一致JSP 页面pageEncoding、请求体编码、数据库连接串的characterEncoding。解决是把它们统一成 UTF-8JSP 顶部声明% page contentTypetext/html;charsetUTF-8 %EncodingFilter里对request和response都设 UTF-8JDBC URL 加characterEncodingutf8建库建表用utf8mb4。GET 请求的参数编码还依赖容器配置必要时在连接器上显式指定。5.2 连接泄漏现象是跑一会儿就报连接超时现象系统用一段时间后所有数据库操作卡住日志里出现连接池耗尽或Too many connections。原因多半是 DAO 里Connection、PreparedStatement、ResultSet没有在异常路径上关闭或者只关了连接没关语句。解决是统一用try-with-resources把资源声明在 try 的括号里异常时也能自动关闭。排查时可以在DBUtil里加计数每次获取加一、关闭减一跑一轮压测看计数是否归零归不了零就说明有泄漏点。5.3 SQL 注入现象是搜索框输入引号就报错现象搜索框输入导致 SQL 语法错误或者输入 OR 11能查出全部数据。原因是用了字符串拼接 SQL。解决是所有用户输入一律走PreparedStatement占位符LIKE的通配符在 Java 侧拼好再setString。排序字段这种不能参数化的地方用白名单校验只允许预设的几个列名其余一律拒绝。这条在答辩时几乎是必问项能当场演示注入被挡住比口头保证有用。5.4 会话失效与重复提交现象是刷新页面重复新增现象新增表单提交后按 F5 刷新同一条学生记录被插入两次或者登录后过一会儿操作被踢回登录页。前者是转发导致的表单重复提交解决是新增成功后用sendRedirect重定向到列表页形成 PRG 模式。后者是会话超时属于正常行为但要在过滤器里区分“未登录”和“会话过期”给用户友好提示而不是直接 500。涉及金额或成绩的写操作还可以在会话里放一次性令牌提交后校验并作废。5.5 分页与排序错乱现象是翻页后条件丢失现象搜索“张”之后翻到第二页结果又变回全部学生或者按学号排序后翻页顺序乱掉。原因是分页链接没带搜索参数或者 SQL 的ORDER BY字段不唯一导致同值行顺序不稳定。解决是分页链接统一由标签拼接把当前查询条件作为参数带上排序时在ORDER BY末尾追加主键id作为兜底保证顺序确定。这类问题在演示时不一定暴露但数据量一上来就明显属于典型的血泪经验。6. 验收与答辩怎么证明这套系统真的能交付验收分三步走。第一步是功能清单逐项过登录鉴权、学生增删改查、分页搜索、成绩录入与统计、权限隔离每项准备一条正常路径和一条异常路径比如删除不存在的学生要给出提示而不是白屏。第二步是数据一致性验证并发提交同一学生的同一课程成绩确认唯一键生效只留一条手动改 URL 越权访问确认被过滤器拦下返回 403。第三步是代码走查随机抽一个 DAO 方法看是否参数化、是否try-with-resources、Service 是否有事务边界。答辩时我一般建议准备一张“请求链路图”和一张“权限矩阵表”被问到“这个请求怎么走的”就顺着图讲一遍被问到“权限怎么做的”就指着矩阵说对应过滤器规则。演示环节控制在五分钟内先跑主流程再演示一个异常场景比如输入注入字符串被挡住比堆功能列表更能体现理解深度。常见追问还有“会话存在哪”“事务怎么保证”“分页总数怎么查”提前把这三问的答案写进讲稿。验收项通过标准验证方式登录鉴权未登录访问受保护页跳登录清 Cookie 后直接访问列表 URL权限隔离学生访问成绩录入返回 403用学生账号改 URL 访问参数化查询注入字符串不改变结果集搜索框输入 OR 11事务一致性重复录入只留一条成绩并发提交同一学生课程资源释放压测后连接计数归零DBUtil 计数日志从那以后我每次带这类课设都会在交付前强制走一遍“清会话、改 URL、输引号、刷页面”这四步四步都过才敢让学生去答辩。这套动作花不了十分钟却能挡掉大部分现场翻车。希望帮到你。本文还有配套的精品资源点击获取