JSP+Servlet学生信息管理系统：从需求到验收的完整架构指南

简介：这份资源是面向Java Web初学者与课程实践者的学生信息管理系统完整项目，以JSP与Servlet为核心，结合MVC设计模式串联数据模型、页面展示与请求控制，帮助读者理解动态网页生成、HTTP请求响应流程及容器部署等关键环节。压缩包共576个文件，约2.75MB，以html、css、png、js等前端资源为主，辅以java源码与class文件、jsp页面、jar依赖、sql初始化脚本及json配置，覆盖界面、业务逻辑与数据库环境搭建。已有998人学习下载。项目将JDBC增删改查、会话管理、异常处理与日志记录等知识点落到可运行代码中，读者可据此梳理分层结构、对照Servlet与DAO的调用关系，并借助数据库脚本快速还原学生信息存储环境，适合作为课程设计或入门练手参考。

1. 从一份“能跑起来”的课设说起：JSP + Servlet 学生信息管理系统要解决什么

每年到了课程设计季，总有人拿着一个能登录、能增删改查的 JSP 页面来找我，说“功能都做完了，但答辩讲不清架构”。问题不在功能多少，而在于这套系统从需求到实现之间缺了一条清晰的线。JSP + Servlet 学生信息管理系统看起来是最经典的 Java Web 入门题目，但它恰好覆盖了一个完整业务系统该有的全部骨架：身份认证、角色权限、数据建模、分页查询、表单校验、异常处理。把这套骨架搭对，比堆十个花哨页面更有价值。这套方案面向两类人：需要交一份结构完整、能讲清设计思路的课程设计或毕业设计的学生，以及想用一套最小可运行范例快速验证 Java Web 分层思路的开发者。下面按需求、设计、实现、避坑、验收的顺序，把这份方案拆到可以直接照着改的程度。

2. 需求与选型：为什么是 JSP + Servlet 而不是别的组合

2.1 先把角色和用例钉死

学生信息管理系统的需求边界其实很窄，窄到很多人一上来就写代码，结果写到一半发现权限没设计、分页没预留。我一般会先画一张角色—用例表，把“谁能在哪个页面做什么”固定下来，后面所有表结构和接口都围绕它展开。

这张表的价值在于：它直接决定了后面 Servlet 里要不要做数据过滤。很多课设翻车就翻在“学生登录后能改别人信息”，原因不是代码写错，而是需求阶段根本没定义数据权限。把这张表贴在需求文档第一页，答辩时老师问“权限怎么做的”，你指这张表就能接住。

2.2 技术选型：原生 JSP + Servlet 的合理性

有人会问，都什么年代了还用 JSP。放在课程设计和教学场景里，这个组合恰恰是最合适的：它把 HTTP 请求响应、会话管理、页面渲染这三件事拆得清清楚楚，没有框架帮你藏黑匣子。你写的每一个doGet、每一次request.getAttribute，都能对应到浏览器发出的那个请求上。这种“看得见”对理解 Web 运行机制非常重要。

具体选型上，我建议保持最小依赖：Servlet 3.1+、JSP 2.3、JDBC 直连数据库、JSTL 做页面逻辑、Tomcat 作为容器。不引入 Spring 不是因为不能用，而是这套方案的目标是让你能逐行讲清每个请求的流转路径。数据库选 MySQL，连接池用 Druid 或 HikariCP 都行，前者在国内教学环境里资料多，后者性能更好，二选一即可。前端不搞脚手架，Bootstrap 加少量 jQuery 足够撑起一个像样的界面。

提示：选型一旦定下来，就在文档里写死版本号，别中途换。我见过一个组做到第七周把 JDBC 换成 MyBatis，结果所有 DAO 重写，进度直接崩盘。

2.3 分层结构：四层各管一件事

这套系统的总体架构按经典四层划分，每层职责单一，层间只允许上层调下层：

• 表现层（JSP）：只负责渲染和表单收集，不写业务判断，不直接连数据库。
• 控制层（Servlet）：接收请求、参数校验、调用 Service、选择跳转页面。
• 业务层（Service）：事务边界、业务规则（如学号唯一、成绩范围校验）。
• 数据访问层（DAO）：只做 SQL 执行和结果集映射，不含业务逻辑。

这个划分听起来像教科书，但真正落地时最容易破功的是“Servlet 里顺手写 SQL”。一旦破功，后面所有复用和测试都无从谈起。我的做法是在项目初期就约定：Servlet 里出现Connection或PreparedStatement一律打回重写。这条规矩比任何架构图都管用。

3. 数据库与核心模块设计：从表结构到请求流转

3.1 表结构设计：五张表撑起全部业务

学生信息管理系统的数据模型不复杂，但字段设计上的小疏忽会在后期放大成返工。下面是我一般会用的核心表结构，字段类型按 MySQL 8 给：

-- 用户表：登录凭证与角色分离，避免学生表和账号表耦合 CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(32) NOT NULL UNIQUE COMMENT '登录名，学号或工号', password VARCHAR(64) NOT NULL COMMENT 'SHA-256 加盐后的密文', role TINYINT NOT NULL COMMENT '1管理员 2教师 3学生', status TINYINT DEFAULT 1 COMMENT '1启用 0禁用', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 学生表：业务信息，通过 user_id 关联账号 CREATE TABLE student ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, stu_no VARCHAR(20) NOT NULL UNIQUE COMMENT '学号', name VARCHAR(32) NOT NULL, gender TINYINT COMMENT '1男 2女', class_id BIGINT, phone VARCHAR(20), email VARCHAR(64), FOREIGN KEY (user_id) REFERENCES sys_user(id) ); -- 班级表、成绩表、操作日志表略，结构同理

这里有两个设计点值得说。第一，账号和业务信息分表，sys_user只管登录，student只管业务属性，这样教师、管理员账号不需要往学生表里塞空字段。第二，密码字段长度给到 64，是因为存的是 SHA-256 加盐后的十六进制串，明文密码字段长度给 32 是常见错误，一存哈希就截断。学号加唯一索引也是必须的，否则并发导入时会出现重复学号，这种脏数据后期清理非常麻烦。

3.2 登录与会话：一个 Filter 管住所有入口

登录逻辑本身简单，难的是“登录后每个请求都要校验身份”。如果每个 Servlet 里都写一遍session.getAttribute("user") == null，代码会臭得没法看。正确做法是用 Filter 统一拦截：

@WebFilter("/*") public class AuthFilter implements Filter { // 白名单：登录页、登录接口、静态资源不拦截 private static final Set<String> WHITE_LIST = Set.of("/login.jsp", "/login", "/css/", "/js/"); @Override public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { HttpServletRequest request = (HttpServletRequest) req; HttpServletResponse response = (HttpServletResponse) resp; String uri = request.getRequestURI().substring(request.getContextPath().length()); // 白名单直接放行 if (WHITE_LIST.stream().anyMatch(uri::startsWith)) { chain.doFilter(req, resp); return; } // 未登录跳登录页，已登录放行 if (request.getSession().getAttribute("loginUser") == null) { response.sendRedirect(request.getContextPath() + "/login.jsp"); return; } chain.doFilter(req, resp); } }

这段代码的关键在WHITE_LIST的判断顺序：先放行白名单，再校验会话。顺序反了会导致登录页本身被拦截，形成死循环，这是新手最常见的翻车点。另外uri要去掉 contextPath，否则部署路径一变，白名单就失效。Filter 里只做“有没有登录”的判断，具体“这个角色能不能访问这个页面”放到各模块的 Servlet 里做，职责分开，排查问题时定位更快。

3.3 分页查询：把 LIMIT 参数算对

学生列表是使用频率最高的页面，数据一多就必须分页。分页的核心就两个参数：当前页pageNo和每页条数pageSize，SQL 里用LIMIT offset, size。offset 的计算是(pageNo - 1) * pageSize，这个公式写错一次，第一页就会漏数据。

public PageResult<Student> queryByPage(int pageNo, int pageSize, String keyword) { // 参数兜底，防止前端传负数或超大值 pageNo = Math.max(pageNo, 1); pageSize = Math.min(Math.max(pageSize, 1), 100); String countSql = "SELECT COUNT(*) FROM student WHERE name LIKE ?"; String dataSql = "SELECT * FROM student WHERE name LIKE ? LIMIT ?, ?"; int offset = (pageNo - 1) * pageSize; // 先查总数算总页数，再查当前页数据 // 两个查询共用同一个 keyword 参数，保证条件一致 ... }

参数兜底那两行看着不起眼，但线上真有人传pageSize=100000把数据库拖垮。Math.min(..., 100)就是给这种情况上的保险。另外 count 查询和 data 查询的条件必须完全一致，我见过 count 忘了带 keyword、data 带了，结果总页数永远偏大，翻到后面全是空页。这种 bug 不报错，只能靠自测发现，所以分页功能做完一定要用边界值（第一页、最后一页、超出范围）各点一遍。

3.4 表单校验：前端拦一遍，后端再拦一遍

新增和修改学生的表单，前端用 HTML5 的required、pattern能挡掉大部分误操作，但后端必须再校验一次，因为请求可以绕过页面直接发。后端校验我一般放在 Service 层，用一个小工具类集中处理：

public void validateStudent(Student s) { if (s.getStuNo() == null || !s.getStuNo().matches("\\d{8,12}")) { throw new BizException("学号必须为8到12位数字"); } if (s.getName() == null || s.getName().trim().isEmpty()) { throw new BizException("姓名不能为空"); } if (s.getPhone() != null && !s.getPhone().matches("1\\d{10}")) { throw new BizException("手机号格式不正确"); } // 学号唯一性在 DAO 层用唯一索引兜底，这里只做格式校验 }

校验失败抛自定义的BizException，Servlet 捕获后把错误信息塞回 request，JSP 用 EL 表达式显示在表单上方。这样用户提交失败后页面不跳走，已填内容还在，体验比直接弹 alert 好得多。学号唯一性不要只靠 Service 里“先查再插”，并发下会漏，最终要靠数据库唯一索引兜底，Service 层捕获DuplicateKeyException转成友好提示即可。

4. 避坑与排查：这套系统最容易翻车的五个地方

4.1 中文乱码：现象是页面显示问号，根因在编码链没统一

现象：表单提交中文姓名，数据库里存进去是乱码，或者页面回显成问号。原因通常有三处没统一：JSP 页面pageEncoding、请求体编码、数据库连接串编码。解决方法是三处一起改：JSP 头部写<%@ page contentType="text/html;charset=UTF-8" pageEncoding="UTF-8" %>；在 Filter 里统一request.setCharacterEncoding("UTF-8")，注意这行必须在读取任何参数之前执行；JDBC 连接串加上characterEncoding=utf8。三处缺一处都可能出问题，排查时按“页面—请求—数据库”的顺序逐个确认。

4.2 连接泄漏：现象是跑一会儿就卡死，根因是没关资源

现象：系统刚启动正常，点几十次之后所有请求都卡住，日志里出现连接池耗尽。原因多半是 DAO 里Connection、PreparedStatement、ResultSet没有在 finally 里关闭，或者异常路径漏关。解决办法是用 try-with-resources 语法，把资源声明在 try 的括号里，JVM 保证关闭：

String sql = "SELECT * FROM student WHERE stu_no = ?"; try (Connection conn = dataSource.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setString(1, stuNo); try (ResultSet rs = ps.executeQuery()) { // 处理结果集 } }

连接池配置里把maxActive设成 20 左右，再开一个监控页面看活跃连接数，压测时如果活跃数只增不减，基本就是泄漏。这个坑在课设答辩现场被问到的概率不低，因为老师会问“并发怎么办”。

4.3 事务没生效：现象是扣了成绩没更新记录，根因是自动提交没关

现象：一个业务操作涉及两张表，比如录入成绩同时更新学生状态，结果一张表成功一张表失败，数据对不上。原因是 JDBC 默认自动提交，每条 SQL 独立事务。解决办法是在 Service 层手动控制事务：conn.setAutoCommit(false)，全部成功commit()，异常rollback()，最后恢复自动提交。注意事务边界要放在 Service，不能放在 DAO，否则一个业务调多个 DAO 方法时事务管不住。这个点答辩时能讲清楚，说明你真的理解分层。

4.4 路径写死：现象是换台机器就 404，根因是绝对路径

现象：在自己电脑上跑得好好的，拷到同学机器或者部署到服务器上，所有跳转和静态资源全 404。原因是 JSP 里写了/student/list这种以斜杠开头的绝对路径，没带 contextPath。解决办法是统一用${pageContext.request.contextPath}拼前缀，或者用 JSTL 的<c:url>标签。Servlet 里的重定向也要用request.getContextPath() + "/xxx"。这个坑不报错、只 404，排查时先看浏览器地址栏的路径对不对，再看服务器部署的 context 名。

4.5 密码明文：现象是数据库里能直接看到密码，根因是没做哈希

现象：打开数据库一看，password字段就是123456。这在课设里很常见，但答辩时是个减分项。解决办法是存 SHA-256 加盐哈希，注册和改密时哈希后入库，登录时把用户输入哈希后比对。盐可以每个用户随机生成存一列，也可以用一个全局固定盐（安全性低但实现简单，课设够用）。至少要做到“数据库里看不到明文”，这一步改动量很小，但能体现安全意识。

5. 验收与答辩：怎么证明这套系统真的能交付

5.1 验收清单：按功能点逐条过

验收不是“能登录就行”，而是按需求表逐条核对。我一般会准备一张验收清单，每条对应一个可操作的动作和预期结果：

这张表的价值在于：答辩时老师随便点一个，你都能当场演示，而不是“这个功能在另一个页面”。清单里的“异常路径”尤其重要，正常流程谁都会点，能演示失败场景才说明系统健壮。

5.2 答辩讲法：先讲请求怎么走，再讲为什么这么分

答辩时间通常只有几分钟，讲代码细节讲不完，也不讨巧。我的建议是准备一张请求流转图（口述即可）：浏览器发请求 → Filter 校验登录 → Servlet 收参数做校验 → Service 开事务调 DAO → DAO 执行 SQL → 结果回传 JSP 渲染。沿着这条线讲，每个环节说一句“这里为什么这么设计”，比如“Filter 统一鉴权是为了避免每个 Servlet 重复写判断”“事务放在 Service 是因为一个业务可能调多个 DAO”。老师听到这种回答，基本就认可你理解了分层，而不是抄了个模板。

再准备一个“如果数据量涨到十万条怎么办”的问题。答案不用复杂：分页已经做了，加索引（学号、姓名），列表页只查必要字段，导出走异步。能说出这几点，说明你想过扩展性。反过来，如果被问到“你的系统有什么不足”，别硬撑，直接说“目前没做缓存，高频查询会压数据库，后续可以加 Redis”，坦诚比编造强。

5.3 一个我踩过的坑：演示环境一定要提前跑一遍

说个血泪经验。有次帮人看答辩，本地一切正常，到了现场连不上数据库，原因是演示机器没装 MySQL，临时装又忘了导数据，最后只能拿截图讲。从那以后我每次交付前都强制走一遍“干净环境部署”：换一台没配过的机器，从建库脚本开始，按文档一步步操作，记录每一步耗时和报错。这个习惯救过好几次场，也顺带把部署文档写扎实了。希望这套从需求到验收的拆法，能帮你把这份 JSP + Servlet 学生信息管理系统真正做成一份拿得出手的方案。

本文还有配套的精品资源，点击获取