又是一个老生常谈又躲不开的选题。每年到了这个时候，总有一批计算机相关专业的同学开始焦虑毕业设计，而“选题管理系统”这类题目，几乎年年出现在各个学校的题目库里面。但说实话，我把这类题目接手带过几十次之后发现，真正能把“管理系统”做明白、做到能答辩、能过查重的同学，其实并不算多。很多人卡住的地方并不是代码写不出来，而是整个项目的边界没想清楚，上来就闷头写，最后做出来的东西不是缺功能就是逻辑混乱。
这个题目的核心，是解决高校毕业设计选题环节里最让人头痛的几件事：选题信息不透明、学生选题靠抢、老师审核靠催、管理员统计靠手动。把这个业务场景理清楚，代码反而是水到渠成的事。下面我就拿一个完整的Java Web版本的选题管理系统来拆开讲，从功能设计、数据库建模，到核心代码逻辑，再到调试运行过程中最容易踩的坑，全部捋一遍。
1. 项目定位与预期目标拆解
1.1 这个系统到底在解决什么问题
选题管理系统，本质上是一个带有审批流的业务管理平台。和网上商城、博客系统这类纯展示型项目不同，它最大的特点是有“角色”和“状态流”的概念。
参与这个系统的人员分三类，对应三种完全不同的操作视角：
- 学生：希望看到所有可选题目，快速找到自己感兴趣的题目并提交申请，同时能查看审核结果。
- 教师：需要发布自己的题目、限定人数、查看哪些学生申请了、审核通过或驳回。
- 管理员：负责系统的基础数据维护，比如专业方向设置、账号管理、题目最终归档、公告发布等。
整个系统的核心业务闭环是：教师发布选题 → 学生浏览并选择题目 → 学生提交申请 → 教师审核申请 → 结果反馈给学生。这个流程里面涉及两个非常关键的状态流转：选题的“可选/已满”状态，以及申请记录的“待审核/通过/驳回”状态。这两条状态线如果设计不清楚，后面写代码的时候一定会把自己绕晕。
1.2 技术选型取舍与目标读者
做这个项目，技术栈用的是Java Web的经典组合：Servlet + JSP + MySQL + Tomcat，前端配合JSP页面加一点JavaScript和CSS。可能有的同学会问，现在都2025年了，为什么不用Spring Boot？这里我得说句真心话——如果你的目标是“通过毕业设计答辩”而不是“给简历上添一个Spring Boot项目”，Classic的Servlet + JSP反而更适合。
原因有三点：
第一，Servlet + JSP能让你把HTTP请求处理、Session管理、请求转发与重定向这些Web底层的机制亲手过一遍。这些东西在Spring Boot里被封装得太狠，你根本感知不到。
第二，给毕设做技术选型，讲究的是“稳”，不是“新”。Servlet + JSP的资料极其丰富，你遇到任何问题都能搜到解决方案，不会卡在一个小错误上两三天。
第三，很多指导老师在评阅时更看重你是否理解了项目的整体架构和业务逻辑。用经典Java Web实现，你能把每一层代码是怎么协同工作的讲得明明白白，这比背一套Spring Boot的“自动配置”更有说服力。
总的来说，这个选题适合Java基础一般、想通过一个完整的Web项目串联起Java核心知识、同时对“数据库设计 + 业务逻辑 + 前后端交互”全链路有个整体认识的同学。
2. 系统功能结构与数据库建模
2.1 核心功能模块逐层拆解
在设计功能之前，一定要先画功能结构图（不是流程图，是树状的功能模块图）。这个习惯很多学生没有，上来就建表写代码，结果写一半发现模块职责重叠，返工成本极高。
按照角色来划分，系统的功能模块大致是这样：
- 通用模块：登录、注销、修改密码、个人信息维护。
- 学生端模块：选题浏览列表、按关键词/专业方向搜索、查看选题详情、提交选题申请、我的申请记录、申请结果通知。
- 教师端模块：我的选题管理（发布、修改、下架）、申请审核列表、点击通过或驳回、查看选题被选情况。
- 管理员端模块：用户管理（添加学生/教师账号，重置密码）、专业方向维护、选题终审与归档、公告管理、数据统计（可选）。
这些模块里面，有一个很容易被忽略但很重要的功能：公告管理。很多同学做的管理系统都把这个功能省掉了，但我建议加上，因为它在答辩演示的时候非常有用——你可以现场演示怎么发布一条“选题截止时间延长”的通知，然后学生端立刻能看到，这在业务上是一个很自然的场景，同时也能展示你对“信息同步”这个业务细节的考虑。
2.2 数据库表设计与字段规划
功能模块梳理完毕之后，下面就是数据库设计。这部分是项目的地基，表结构设计得是否合理，直接决定后面写SQL和业务代码是顺手还是痛苦。
一个完整且合理的选题管理系统，至少需要以下这些表：
| 表名 | 用途 | 关键字段 |
|---|---|---|
| t_user | 用户表 | id, username, password, real_name, role, major_id, phone, email, create_time |
| t_major | 专业方向表 | id, major_name, description |
| t_topic | 选题表 | id, title, description, requirements, teacher_id, major_id, max_students, selected_count, status, create_time |
| t_apply | 选题申请表 | id, topic_id, student_id, apply_time, status, audit_opinion, audit_time |
| t_notice | 公告表 | id, title, content, publish_time, publisher_id |
有几个字段在设计的时候要多想一层，我逐个说。
第一个是t_topic表里的status字段。这个字段建议用0/1/2表示“草稿/发布中/已下架”，而不要用布尔类型。因为“已下架”这种状态在实际场景中非常常见——老师这学期不想带这么多学生了，或者题目内容需要大改，题目下架后学生端就看不到了，但历史申请记录还要保留。布尔类型只能表达两种状态，不够用。
第二个是t_topic表里的max_students和selected_count。这两个字段分别表示“题目最多可选人数”和“已经被选中的人数”。有人会疑惑，为什么被选中人数不通过统计t_apply表来算？理论上确实可以用SELECT COUNT(*) FROM t_apply WHERE topic_id = ? AND status = 1来算，但是这样每一次展示选题列表的时候都要多查一次数据表，在数据量上来之后会有明显的性能问题。用冗余字段selected_count可以做到一次查询直接展示剩余名额，代价是更新的时候要多维护一个字段。这个“用空间换时间”的思路在很多管理系统里都会用到，值得在论文里也提一下。
第三个是关于用户表的角色设计。业界有两种做法：一种是把所有用户放一张表，用role字段区分；另一种是分三张表（学生表、教师表、管理员表）。我这里推荐第一种。原因很简单：这个系统的登录逻辑是完全统一的——用账号密码鉴权，然后根据角色进入不同的操作界面。如果分表，登录的时候先要判断你这个人属于哪个角色，再去对应的表里查询，逻辑上是绕了一个圈子，完全没有必要。
数据库这部分，还有一个细节是很多初学者容易忽略的：字符集。建表建议统一使用utf8mb4，在MySQL里，MySQL 5.7之前默认的utf8是utf8mb3，不支持存储一些特殊字符（比如emoji）。如果你在系统里允许用户输入特殊符号或者表情，插入的时候就会报Incorrect string value的错误。用utf8mb4就不会有这个问题。建库语句参考：
CREATE DATABASE IF NOT EXISTS graduation_system DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci;3. 核心代码实现与业务逻辑细究
3.1 三层架构在项目里的落地方式
Java Web项目的标准分层是：Servlet（控制层）、Service（业务逻辑层）、DAO（数据访问层），搭配JSP作为视图层。很多同学对这个分层只是“听说过”，真写代码的时候所有的逻辑都堆在Servlet里面，一个方法几百行，既不美观也极难调试。
我强烈建议按这个包结构来组织代码：
com.graduation ├── controller // Servlet，只做参数接收、调用Service、跳转页面 ├── service // 业务接口 ├── service.impl // 业务实现，核心逻辑都在这里 ├── dao // 数据库访问接口 ├── dao.impl // JDBC访问数据库的实现 ├── entity // 实体类，对应数据库表 ├── util // 工具类：DBUtil、MD5Util、PageBean等 └── filter // 过滤器：编码过滤、登录状态过滤这个分层的核心思想是“各司其职”。Servlet里不应该出现SQL语句，DAO里不应出现业务判断，Service专注处理业务规则。举个例子，学生选题提交申请这个操作，在Service层至少要做三件事：检查这个题目的状态是否为“发布中”、检查剩余名额是否大于0、检查这个学生是否已经选过这个题目。这三项检查是对数据安全的基本保障，必须放在Service层统一处理，不能散落在前端页面的JavaScript里——因为前端的校验是可以被轻易绕过的。
3.2 登录模块的实现与Session管理
登录模块是整个系统的入口，也是一个很容易被检查出问题的点。基础功能谁都写得出来：接收到用户名密码，查数据库，比对成功就跳转首页。但要做到“合理”，至少还得加上三个东西：验证码、密码加密存储、访问控制过滤器。
验证码我用的是Kaptcha组件，引入依赖后，在Servlet里生成验证码图片，把验证码文本存入Session，验证登录时先比对验证码。这一步看似简单，但有一个细节要注意：验证码比对正确后，要立刻从Session中移除验证码属性，防止同一个验证码被人反复使用。
密码存储方面，绝对不允许明文入库。用MD5加盐的方式处理，注册或管理员创建账号的时候，把MD5(密码 + 固定盐值)存进数据库。这里多说一句，网上有文章说MD5已经被破解，不适合用于密码存储。这个说法是对的，但对于一个毕业设计项目来说，MD5加盐已经足以体现你的安全意识了。如果你想更进一步，可以用SHA-256或加随机盐，写进论文里会更好看。
访问控制过滤器是这个系统安全性的重中之重。通过在web.xml里配置Filter拦截所有请求，在过滤器中判断当前Session里有没有登录用户，如果没有就重定向到登录页。同时还需要做角色权限控制：学生用户无权访问/teacher/*路径下的资源，教师用户无权访问/admin/*路径下的资源。这部分逻辑写在Filter里，用一段简单的路径前缀判断即可。
3.3 选题并发控制，最容易翻车的地方
如果说这个系统哪一个地方最能体现技术含量，那就是选题环节的并发控制。现在很多学校选题就是拼手速的“抢课”模式，一个热门题目可能在两分钟内被几百个学生同时申请。如果你的代码在判断剩余名额的时候是“先查再更”，那一定会有问题。
举个例子，假设某个题目最多选10个人，已经选了10个。这时候第11个和第12个学生同时提交申请。如果不加控制，两个请求都先执行SELECT selected_count FROM t_topic WHERE id = 1，发现都是10，都判断为“未满”，然后都执行UPDATE ... SET selected_count = 11，最后结果是只有11，但状态却显示名额已满，数据库里也不会真的超员——看起来没超，但实际上你在并发下逻辑已经错了，因为在极端情况下两个请求同时提交后都成功插入申请记录，selected_count只加了一次，两边都对不上。
解决这个问题的常规思路，是把整个“检查并更新”的操作放到一个数据库事务里，保证原子性。Service层方法加上事务控制，核心逻辑是使用条件更新：
Connection conn = DBUtil.getConnection(); try { conn.setAutoCommit(false); // 1. 用条件更新抢占名额，返回影响行数 String sql = "UPDATE t_topic SET selected_count = selected_count + 1 " + "WHERE id = ? AND status = 1 AND selected_count < max_students"; PreparedStatement ps = conn.prepareStatement(sql); ps.setInt(1, topicId); int rows = ps.executeUpdate(); if (rows == 0) { conn.rollback(); return "该选题已满或已下架"; } // 2. 插入申请记录 String sql2 = "INSERT INTO t_apply(topic_id, student_id, apply_time, status) VALUES(?,?,?,0)"; // ... conn.commit(); } catch (Exception e) { conn.rollback(); throw e; } finally { // 关闭资源 }这个UPDATE ... WHERE selected_count < max_students是整段代码的灵魂。数据库在执行这个语句的时候会锁定匹配的行，两个并发请求到达数据库时，第二个请求会因为第一行已经被锁住而进入等待状态，第一个请求执行完，第二个请求再去执行的时候，selected_count已经变成11了，条件不满足，影响行数为0，事务回滚，学生收到“该选题已满”的提示。这种方式比先查再更加锁要简洁得多，也充分体现了你对“并发安全”的理解，答辩时老师问起“如何保证不会超出名额”，就可以直接讲这个思路。
3.4 教师审核模块的状态流转设计
教师审核模块的业务逻辑相对简单，但状态流转的规则要想清楚。一份申请记录的状态有四种可能：待审核（0）、已通过（1）、已驳回（2）、已撤销（3）。最后一个状态是学生主动取消申请用的——学生提交申请后发现不想要这个题目了，在教师还没审核前可以撤回。这个功能有必要吗？很有必要，而且很常见。有了它，状态流转图才完整，也避免了学生申请错了题目之后只能干等老师驳回的尴尬局面。
审核的时候还有一个边界情况要考虑：如果一份申请已经被审核过（通过或驳回），教师不能重复审核。这就需要在前端和后端都做好判断，后端的判断尤其重要，不能只依赖前端隐藏按钮。
4. 调试运行全流程记录与避坑指南
4.1 从零到能跑通的环境搭建
很多同学在这个环节就被劝退了。其实环境搭建是有标准流程的，照着做基本不会出问题。
工具和版本，我这里给一个亲测稳定的搭配：
- JDK版本：JDK 8。这个版本兼容性最好，Tomcat和Eclipse/IDEA都完美支持，不要一上来就上JDK 17或21，有的Tomcat老版本不支持，遇到
UnsupportedClassVersionError会很头疼。 - 数据库：MySQL 5.7或8.0都可以。用8.0的话要注意JDBC驱动包也要用
mysql-connector-java-8.0.x.jar，不要拿5.x的驱动去连8.0的库，会有认证协议不匹配的问题。 - 服务器：Tomcat 8.5或9.0。JDK8搭配Tomcat 8.5是黄金组合，网上查得最多、资料最全。
- IDE：Eclipse或IDEA都可以，如果你不是特别熟悉IDEA的调试操作，建议Eclipse，因为很多网上的图文教程是Eclipse界面的。
项目结构方面，在IDEA里是标准的Java Web结构，工程名下面有src目录放Java源码，web（或webapp）目录下面有WEB-INF/web.xml、JSP页面、静态资源。所有的Jar包放在WEB-INF/lib下面。
一个很多新手都容易踩的坑：JDBC驱动包一定要放到WEB-INF/lib目录，而不是只添加到项目的Build Path。因为在Tomcat里运行的时候，项目的类加载器是优先从WEB-INF/lib找依赖的，Build Path只是给编译环境用的，运行环境用不上。
4.2 必踩的坑与解决办法
我把带项目过程中见过的高频报错整理成一张表，方便你直接对照排查：
| 报错信息 | 原因分析 | 解决办法 |
|---|---|---|
ClassNotFoundException: com.mysql.jdbc.Driver | MySQL驱动包没放到WEB-INF/lib | 将mysql-connector-java-x.x.x.jar拷贝到WEB-INF/lib |
The server time zone value '乱码' is unrecognized | MySQL 8.0的时区问题 | JDBC连接串加serverTimezone=Asia/Shanghai |
java.sql.SQLException: Access denied for user 'root'@'localhost' | 数据库用户名或密码错误 | 检查DBUtil里的账号密码，注意空格和大小写 |
| 页面表单提交中文乱码 | 请求编码和响应编码不统一 | 添加编码过滤器request.setCharacterEncoding("UTF-8")，所有页面用UTF-8 |
HTTP 404，访问Servlet报错 | Servlet映射路径写错，或项目没部署成功 | 检查web.xml里的<servlet-mapping>，核对访问URL前缀 |
java.lang.NullPointerExceptionat DAO层 | 数据库连接为null | 检查DBUtil的静态代码块是否执行成功，打印异常确认是否加载了配置 |
| 修改代码后页面没变化 | 浏览器缓存了旧JSP或静态资源 | 按Ctrl+F5强制刷新，或者重启Tomcat |
这里面尤其要提一下第一次使用JDBC连接池（比如Druid或C3P0）的同学。配置文件的路径问题是一个大坑，很多人习惯把druid.properties放在src根目录，然后在代码里用ClassLoader.getSystemResourceAsStream("druid.properties")来加载。这个方法在普通Java应用上没问题，但一旦部署到Web容器，类加载路径会变化，加载不到配置文件。更稳妥的做法是DBUtil.class.getClassLoader().getResourceAsStream("druid.properties")，这样用的是当前类的类加载器，能正确读取到classes目录下的资源文件。
4.3 数据库操作时的几个隐蔽问题
写DAO层代码的时候，有几个容易出错的细节，我单独拎出来说。
第一，关于PreparedStatement和Statement。所有的SQL都必须用PreparedStatement，绝对不能图方便用Statement去拼接字符串。这不仅是防SQL注入的安全底线，也是代码规范的一部分，老师评阅代码的时候一眼就能看出来。
第二，关于查询结果集的映射。实体类的属性命名尽量和数据库字段保持一致，比如数据库字段是selected_count，实体类属性就写成selectedCount，SQL查询的时候用别名映射：SELECT selected_count AS selectedCount FROM t_topic。这样一行代码BeanUtils.populate(topic, rs)就能搞定结果集转实体，不用写一堆setXxx()调用。
第三，关于日期时间的存储。申请时间、发布时间建议用DATETIME类型，Java代码里对应java.time.LocalDateTime，通过PreparedStatement.setObject()传入。千万不要用new Date()往里塞java.util.Date，在MySQL 8.0和JDBC 4.2版本里，java.time包下的类型才是标准推荐。实体类里也不要再用老的java.util.Date，用LocalDateTime反而顺手。
5. 论文写作与答辩准备的思路
5.1 论文结构怎么组织
很多同学认为项目做完了论文就好写，其实恰恰相反。论文是对整个项目“设计过程”的复盘，指导老师和评审专家不可能通过代码来判断你做得怎么样，完全是通过论文里的逻辑来理解你的思路。
毕设论文的常见结构是：绪论（背景、意义、国内外现状）→ 相关技术介绍 → 需求分析 → 系统设计 → 系统实现 → 系统测试 → 总结与展望。这个结构虽然模板化，但胜在清晰，也符合老师的阅读习惯。要注意的是不要把需求分析写成百度百科，而是对着自己做的系统，真实地列出功能用例。系统设计部分要多放子模块划分和数据库表设计的说明，配合字段解释。系统实现部分是重点，但不要贴大段代码，而是每个核心功能选几行关键代码，配合业务逻辑的叙述。
数据库设计部分要画E-R图，用PowerDesigner或draw.io画，不要手画。E-R图包括实体、属性和联系，角色之间有“发布”“选择”“审核”等联系，联系上要标出一对多、多对多的关系说明。
5.2 答辩演示的加分项目
答辩演示是有技巧的。不要照着PPT念，也不要一上来就打开IDEA。一个顺畅的演示节奏是：
- 一分钟讲清楚你的系统“是什么、给谁用、解决什么问题”。
- 打开系统，用管理员账号登录，展示用户管理和专业方向维护。
- 切换到教师账号，现场发布一个新选题。
- 再切到学生账号，演示搜索到这个新发布的选题、提交申请。
- 切回教师账号，审核通过这个申请。
- 最后回到管理员视角，展示最终选题归档。
这套流程走完，你的系统业务闭环就完整呈现了。而且整个演示是连贯的故事——发布、申请、审核，老师不需要思考就能理解你在做什么。
两个加分的小细节：一是把数据库连接池的初始大小设置得合理一点，演示的时候不要出现页面加载旋转超过两秒的情况；二是提前准备好一组测试账号数据，比如几个不同专业的学生账号、几个有不同状态选题的教师账号，方便展示列表数据的丰富性。现场临时注册一个学生、再临时发布一个题目，列表页只有一行数据，看起来会非常空，会给人“系统没怎么用过”的错觉。
另外，答辩的时候一定准备一张核心功能的数据流转图，不管是手绘的还是draw.io画的。当老师问“学生选题之后数据是怎么处理”的时候，对着图一步一步讲请求从哪里进来、经过哪些层、最后落库到哪张表，这个回答的完整度会立刻拉开和多数同学的差距。
6. 项目扩展方向，做完基础功能之后还能做什么
如果你的进度比较快，系统基础功能已经全部完成，论文初稿也有了，还有余力的话，可以考虑往这些方向扩展。扩展功能不仅能丰富系统内容，也能让你多掌握一些加分的技术点。
第一个推荐扩展方向：基于时间段的选题开关。管理员可以设置系统开放选题的时间范围，不在时间范围内不允许学生提交申请。这个功能在真实的业务中非常重要，因为每个学校的选题季是有固定时间的。实现上也不复杂，在Service层提交申请前多一次时间判断即可，再在管理员端加一个时间段配置页面。
第二个推荐扩展方向：选题相似度提醒。有些题目在发布的时候，可能连续两三年或者不同老师之间题目高度相似。这个功能用简单的关键词匹配就能实现——发布选题时检查已有题目的标题，如果有连续几个关键词相同就给出提示。技术含量不高，但能体现你站在业务方的角度思考过问题，论文里也能多写一整节。
第三个推荐扩展方向：Excel导入导出。学生名单的批量导入、最终选题名单的导出，都是管理员非常需要但很多系统不做的功能。用Apache POI实现导出学生选题汇总表，一两百行代码，但对实际使用的价值很高。
第四个扩展方向：WebSocket实时通知。学生提交申请后，教师的页面可以实时收到一条“有新的选题申请”的提醒，无需刷新页面。WebSocket技术点新颖，在答辩时可以现场演示这种“实时推送”的效果，对加分会很明显。不过要提醒一句：不要为了追求扩展功能而忽略了基础功能的稳定性。毕业设计的第一原则永远是“基础功能完善、代码没bug、论文能自圆其说”，扩展功能是在这个基础上的锦上添花。
根据我带项目的经验，绝大多数同学把基础功能做完、把逻辑理顺、把论文写透彻，拿到一个不错的评价是完全够用的。真正拉开差距的不是用了多新的技术，而是你对业务的理解有多深、系统设计有多合理、边界情况有多敏锐。这套选题管理系统的代码逻辑并不复杂，但它覆盖了一个典型Web业务系统的完整生命周期，值得静下心来做扎实。
