简介：基于Java/JSP实现的毕业选题系统源码包，面向高校毕业设计、课程设计及Java Web学习者。系统覆盖管理员、教师、学生三类角色：管理员能维护系主任信息并负责系统日常运行，教师可录入毕业设计题目、审核学生选题，学生则通过网页完成在线选题，业务链路完整，可直接参考其模块划分与数据库设计。资源共547个文件，以353个gif操作演示和61个jsp页面文件为主，辅以css样式、js交互脚本、jar依赖包，以及docx/caj论文与说明文档，另含MySQL数据库文件，压缩包整体仅8.65MB，轻量便于部署。已有53人学习浏览，适合需要快速落地毕设功能或理解选题流程的开发者。包内附带前后端完整代码、数据库脚本和文档，可在Eclipse/IDEA配合Tomcat环境下导入运行，便于二次开发与论文撰写。
1. 毕业选题系统用 Java 做，为什么毕业设计都爱选这个题
每年三、四月份，高校教务系统的选题入口一开，几千名学生同时刷新页面，教师端还要手动维护几十条题目，很多人最后把 Excel 用成了核心业务库。基于 java 的毕业选题系统，目标就是把“教师申报题目—学生志愿选题—管理员审核分配—结果导出”这条链路做成一个完整的前后端应用：后端用 Java 写接口，前端做操作页面，数据沉到 MySQL 里，附带的说明文档再把部署步骤和模块设计讲明白。这个标题适合两类人：一类是正在找课程设计或毕业设计题目的学生，另一类是刚学完 Spring Boot，想拿一个“有真实业务流转、有角色权限、有完整前后端”的案例练手的新手开发者。它不炫技，但能一次覆盖建库、联调、部署、答辩全流程。
2. 选题系统拆开看：技术栈选型和三个端口的模块边界
2.1 SSM、Spring Boot 还是前后端分离：三个技术路线的取舍清单
标题里写了 java、完整前后端、mysql，但“java”这三个字能落地的方式差别很大。我见过不少毕设源码包，同一个选题在不同年份迭代出了三代技术路线，工作量完全是两个量级。
| 技术路线 | 适合人群 | 前后端耦合度 | 答辩讲解难度 | 面试认可度 |
|---|---|---|---|---|
| SSM + JSP | Java Web 刚入门 | 高，JSP 里混 Java 和 HTML | 低，代码都在 controller 里 | 一般 |
| Spring Boot + Thymeleaf | 想快速交付课设 | 中，后端渲染页面 | 中，讲清楚 ModelAndView 即可 | 中 |
| Spring Boot + Vue 前后端分离 | 求职方向或想练接口设计 | 低，前端调接口 | 高，要讲跨域、鉴权、联调 | 更高 |
这个系统的业务不算复杂，很多人的第一反应是“没必要做前后端分离”。但标题里明确带了“完整前后端”这个词，而且你现在去看招聘市场，前后端分离项目实战经验几乎成了 Java 工程师的基础门槛，所以我的建议是：只要时间够六周以上，就直接走 Spring Boot + Vue 的路线。JSP 这条路最容易被低价源码包采用，改造空间小，答辩时老师让你当场改个页面样式，你要翻半天 JSP 标签库，体验很糟糕。
选型上还有一个反直觉的坑：别因为自己 Vue 不熟就退回 Thymeleaf。Thymeleaf 确实不用配跨域、不用管 npm，但学期末的调试成本并不低于前端工程——后端模板渲染一旦报错，你要同时懂 HTTP 状态码、模板语法和 Java 对象模型，排错链路比“前端看 Network、后端看日志”要长得多。
2.2 学生端、教师端、管理员端：模块边界先厘清再写代码
拿到这个源码包，你面对的不是十几个不明所以的文件夹，而是一套按角色划分的用例集合。毕业选题系统的核心角色只有三类，看起来简单，但大部分翻车项目都死在角色职责混在一起。
| 角色 | 核心用例 | 涉及数据表 | 关键页面 |
|---|---|---|---|
| 学生 | 浏览题目、提交志愿（1-3个优先级）、查看审核结果 | user、topic、select_record | 选题大厅、我的志愿 |
| 教师 | 申报题目、审核学生志愿、确认录取名单 | user、topic、select_record | 题目管理、志愿审核 |
| 管理员 | 账号管理、题目审批、专业维护、统计导出 | user、major、topic、select_record | 控制台、报表导出 |
三类角色的用例有重叠也有边界。教师的“申报题目”和管理员的“审批题目”是两个动作，不是同一个；学生的“提交志愿”和教师的“确认学生”也是两个动作。我一般会先画一张角色-功能矩阵，再按矩阵去拆 controller、service、mapper 三层，而不是把所有方法堆在一个TopicController里。
拿到源码后，我建议按这个顺序读代码：先看controller目录里有哪些路由，再对应用例矩阵找“申报、审核、选题、导出”四个核心方法。搜索时优先找listPage、submit、audit、export这四个方法名，它们基本串起了整个系统的主链路。前端工程则从router/index.js开始看路由权限，能判断页面是动态路由还是静态路由——很多源码包在这块写得很随意，接口鉴权形同虚设。
3. MySQL 数据库设计：五张核心表与一条状态机的落地
3.1 user 表与角色设计：为什么角色权限做在单表里更快
数据库设计是这套系统里最能看出“有没有真跑过”的部分。很多毕设源码包会表结构一大片，但实际业务只用了其中两张表。我比较推荐的最小核心表是五张：user用户表、major专业表、topic题目表、select_record选题记录表，再加一张可选的notice公告表。先看用户表和专业表：
CREATE TABLE `user` ( `id` int NOT NULL AUTO_INCREMENT COMMENT '主键', `username` varchar(50) NOT NULL COMMENT '登录账号', `password` varchar(100) NOT NULL COMMENT 'BCrypt 加密后的密码', `role_type` tinyint NOT NULL DEFAULT 2 COMMENT '0=管理员 1=教师 2=学生', `real_name` varchar(50) NOT NULL COMMENT '姓名', `user_no` varchar(30) DEFAULT NULL COMMENT '工号或学号', `major_id` int DEFAULT NULL COMMENT '专业ID，教师可不填', `phone` varchar(20) DEFAULT NULL COMMENT '联系方式', `status` tinyint NOT NULL DEFAULT 1 COMMENT '1=启用 0=禁用', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表'; CREATE TABLE `major` ( `id` int NOT NULL AUTO_INCREMENT COMMENT '主键', `major_name` varchar(50) NOT NULL COMMENT '专业名称', `dept_name` varchar(50) DEFAULT NULL COMMENT '所属学院', PRIMARY KEY (`id`), UNIQUE KEY `uk_major_name` (`major_name`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='专业表';用户表这里有个设计取舍：为什么不把admin、teacher、student拆成三张角色表？因为这个体量下用 RBAC 三张表属于过度设计，角色字段加一个tinyint就够。登录接口拿到用户名后，先查出role_type，再决定放行到哪个前端路由，这个逻辑简单直接。如果你的需求真的要做精细化权限点，再把它升级成role+permission两张表也不晚。
这段设计里还藏着一个 MyBatis 相关的细节：很多源码包用 MyBatis-Plus 根据实体类反向生成建表语句，user_no会被自动映射成userNo之类的驼峰字段。如果你自己建库，建议显式设置map-underscore-to-camel-case: true，否则查询结果会全空，这是一个非常典型的坑。
3.2 topic 表与选题记录表：用 status 字段串起审核状态机
题目表和选题记录表是整个系统的业务核心，也是最容易设计错的地方。
CREATE TABLE `topic` ( `id` int NOT NULL AUTO_INCREMENT COMMENT '主键', `teacher_id` int NOT NULL COMMENT '教师 user.id', `title` varchar(100) NOT NULL COMMENT '题目名称', `description` text COMMENT '题目内容与要求', `major_id` int DEFAULT NULL COMMENT '限选专业', `max_students` int NOT NULL DEFAULT 3 COMMENT '可选人数上限', `selected_count` int NOT NULL DEFAULT 0 COMMENT '已确认人数（冗余字段）', `status` tinyint NOT NULL DEFAULT 0 COMMENT '0=待审核 1=通过 2=退回', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_teacher` (`teacher_id`), KEY `idx_major` (`major_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='题目表'; CREATE TABLE `select_record` ( `id` int NOT NULL AUTO_INCREMENT COMMENT '主键', `student_id` int NOT NULL COMMENT '学生 user.id', `topic_id` int NOT NULL COMMENT '选题 ID', `priority` tinyint NOT NULL DEFAULT 1 COMMENT '志愿优先级 1/2/3', `status` tinyint NOT NULL DEFAULT 0 COMMENT '0=待审核 1=通过 2=退回', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, `audit_time` datetime DEFAULT NULL COMMENT '审核时间', `audit_comment` varchar(255) DEFAULT NULL COMMENT '退回原因', PRIMARY KEY (`id`), KEY `idx_student` (`student_id`), KEY `idx_topic` (`topic_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='选题记录表';两张表各有一个status字段，含义不同。topic.status管的是“这道题目本身能不能被学生看到”，select_record.status管的是“这个学生的这条志愿是否被教师确认”。我见过很多新手把这两个状态混到一起，导致教师通过了题目、但学生看不到，或者学生选了题、教师审核的却是题目状态。
状态值用tinyint而不是把“待审核”“已通过”直接写进表里，是为了统计时不用到处写case when。查询“某位教师名下的通过题目”时，一条 SQL 就能把排序和过滤做干净：
SELECT id, title, selected_count, max_students, create_time FROM topic WHERE teacher_id = 1 AND status = 1 ORDER BY create_time DESC, status ASC;这里的ORDER BY create_time DESC, status ASC其实是 mysql 排序里很常用的写法：先按创建时间倒序把最新题目排前面，再用status保证同批数据里已通过的状态优先展示。selected_count是一个典型的冗余字段，它可以用子查询算出来，但选题页高频展示已选人数，实时聚合会导致每次查询都扫select_record，冗余字段在这个场景下是合理的。更新的时机放在“教师确认通过志愿”后，不要放在学生提交志愿时。
3.3 说明文档（LW）里最该画的三张图：ER 图、流程图与架构图
标题里的“说明文档+LW”是答辩时老师最先翻的东西。很多学生花两周写完代码，最后两天赶文档，画图全靠复制粘贴，结果 ER 图的表名字段对不上源码。我的经验是：文档里最值得认真画的图只有三张。
第一张是 ER 图，只要画清user、major、topic、select_record四张表，以及表之间的关联关系。重点标出“一个学生可以提交多条选题记录，但同一题只能有一条有效记录”。第二张是业务流程图，从“教师申报题目”开始，到“管理员审批通过”，再到“学生提交志愿、教师确认、管理员发布结果”，用箭头把状态流转画出来，这张图直接对应第 3.2 节的状态机。第三张是系统架构图，按 Vue 前端、Spring Boot 接口层、Service 业务层、Mapper 数据层、MySQL 数据库分四层画，标注每个请求的调用链路。
这三张图不需要多精美，但必须和代码一致。文档里出现的所有接口路径、状态枚举值、表名字段名，都应该能对着源码找到，这是答辩时最容易加分也最容易翻车的地方。
4. 本地部署跑通完整前后端：从 JDK 检查到 Vue 联调的最小操作
4.1 环境检查：JDK、Maven、Node、MySQL 的四条命令
部署这套系统前，先把环境捋一遍。很多源码包报错，八成不是代码问题，而是环境版本对不上，这一类问题我最常看到的是“玄学启动失败”，其实一点都不玄，先跑四条命令：
java -version mvn -v node -v npm -v mysql --version这四条命令分别检查 JDK、Maven、Node、MySQL。重点看前两个输出。如果java -version显示的是 1.8，而项目里的pom.xml用的是 Spring Boot 3.x，那启动会直接报错，因为 Spring Boot 3.x 强制要求 JDK 17。反过来，如果项目是 Spring Boot 2.x，用 JDK 17 虽然能起，但会碰到反射相关的警告，不如老老实实装 JDK 8 或 11。判断标准很简单：打开pom.xml，看spring-boot-starter-parent的版本号，3.x 配 JDK 17，2.x 配 JDK 8/11。
mvn -v找不到命令，是环境变量没配好，不是没装好。Windows 下需要把 Maven 的bin目录手动加到系统变量Path里。MySQL 也是同样道理，你在 Windows 上刚装完 MySQL 5.7 或 8.0，cmd 里敲不出mysql命令，不用重装，去环境变量里加一行 MySQL 的bin目录路径就行。
4.2 建库导数据：一条 mysql 命令把 SQL 导进本地实例
源码包里通常会带一个db_init.sql或init.sql，里面是建库、建表、导入初始账号的完整脚本。拿到手后先在本地建一个空库，再把数据导进去。
mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS graduation_topic DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;" mysql -u root -p graduation_topic < db_init.sql第一条命令用mysql -e执行建库语句，IF NOT EXISTS防止重复建库报错；CHARACTER SET utf8mb4直接指定字符集，这是后面避免中文乱码的关键。第二条命令把db_init.sql导入graduation_topic库，注意库名要写在<重定向之前。
如果你更习惯进入 MySQL 控制台操作，等价的写法是：
mysql -u root -p mysql> source D:/code/graduation_topic/db_init.sql;Windows 下用source命令时，路径里的反斜杠容易出问题，建议全部改成正斜杠，比如D:/code/...。导入完成后可以用SHOW TABLES;确认有没有生成user、topic、select_record这几张表。
4.3 后端改造与启动：application.yml 里必须改的三个地方
后端工程里需要改的配置基本都集中在application.yml或application.properties。先找到这个文件，改三个地方：数据库连接地址、用户名、密码。
server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/graduation_topic?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: "你的数据库密码" mybatis-plus: mapper-locations: classpath*:mapper/*.xml type-aliases-package: com.example.graduation.entity configuration: map-underscore-to-camel-case: trueurl里的graduation_topic要和 4.2 里建的库名一致；username和password改成你本地 MySQL 的登录账号。password一定要加引号，如果密码里有#、@、:这些特殊字符，YAML 会把它们当成注释或分隔符，导致连接串被截断，报出莫名其妙的Access denied。
driver-class-name这里写的是com.mysql.cj.jdbc.Driver，这是 MySQL 8.x 驱动的写法。老项目里常见的com.mysql.jdbc.Driver是 5.x 时代的驱动路径，如果你本地装的是 MySQL 8.0，建议统一用前者。Spring Boot 2.7 以上版本可以自动识别驱动，不写这行也能跑，但显式写出来，启动日志里排查数据库问题时更直观。
后端启动命令很简单，在工程根目录执行：
mvn spring-boot:run如果你想打包成 jar 再启动，用：
mvn clean package -DskipTests java -jar target/graduation-0.0.1-SNAPSHOT.jar-DskipTests是跳过单元测试。我一般会带上它，因为很多源码包里的测试类没有配置测试环境数据库，直接打包会被测试挂掉。看到Started Application in xx seconds就说明后端起来了，你可以先访问http://localhost:8080看看有没有接口返回。
4.4 前端跑起来与联调：npm 依赖和 proxy 转发的常见报错
前端工程和后端是两个独立进程，联调的核心是解决跨域。主流做法是在前端的vue.config.js里配代理，而不是在后端写 CORS 过滤器，因为代理更接近生产环境里 Nginx 的做法。
const { defineConfig } = require('@vue/cli-service') module.exports = defineConfig({ devServer: { port: 8081, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } })这段配置把前端 8081 端口收到所有以/api开头的请求，转发到后端 8080。两个点容易踩坑：一是前端 axios 请求的 baseURL 必须带上/api前缀，否则请求不会命中代理规则；二是后端的 controller 路由里不一定有/api这个前缀，如果代理把/api原样转发给后端，后端会报 404。常见做法是后端在application.yml里加一个server.servlet.context-path: /api，让所有接口统一挂到/api下，这样前后端路径就对齐了。
前端启动命令：
npm install npm run devnpm install卡住或者超时，是这类源码包最常见的翻车点。可以先执行npm cache verify清一下缓存，再看是不是网络源太慢，换成国内镜像源后重新安装会快很多。启动后浏览器访问http://localhost:8081，能出现登录页、并且点击登录能跳转，就说明前后端联调通了。
5. 避坑记录：从端口冲突、白屏到中文乱码的 5 次现场排错
5.1 前端白屏，后端日志一切正常：CORS 跨域拦截了你的登录请求
现象：后端启动没有报错，前端npm run dev也正常，但浏览器打开登录页后点击登录，一直转圈，Network 面板里请求标红或超时。
原因：前端页面跑在 8081，接口跑在 8080，跨域请求被浏览器拦截。如果前端没有走 proxy，后端也没有配置 CORS 过滤器，浏览器会先发一个OPTIONS预检请求，后端没处理直接返回了错误。
解决：优先按 4.4 的方式配置前端 proxy，这是开发环境里最干净的路子。如果确实要在后端放行，可以加一个全局 CORS 配置类，允许 8081 来源访问。但注意生产环境不要把allowedOrigins写成*，否则带登录凭证的请求会被浏览器拒收。
5.2 MySQL 密码带特殊字符，yml 默默把 # 后面的内容当成了注释
现象：后端启动报Access denied for user 'root'@'localhost'，但你在命令行里用同样的密码能正常连上 MySQL。
原因：application.yml里password: abc#123，YAML 解析器把#后面的123当成了注释，实际生效的密码是abc，自然连不上。
解决：密码用引号包起来，password: "abc#123"。另外 MySQL 8.0 默认加密方式是caching_sha2_password，如果你的项目用的还是 mysql-connector-java 5.x 老驱动，即使密码对了也会报认证失败。两个办法选一个：把驱动版本升级到 8.x，或者在 MySQL 里执行ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '新密码';。我建议直接升级驱动，不要改数据库加密方式，因为改回去会让数据库安全性降级。
5.3 中文乱码：连接串里缺了 characterEncoding 与 useUnicode
现象：数据库里中文显示正常，但前端页面拿到的是???或者乱成一串不可读字符。
原因：三层都可能出问题。第一层是数据库实例或表本身不是 utf8mb4；第二层是 JDBC 连接串没带编码参数；第三层是db_init.sql文件本身的编码是 ANSI，导入时中文已经变成乱码。
解决：数据库建表时指定DEFAULT CHARSET=utf8mb4；JDBC URL 里加上useUnicode=true&characterEncoding=utf8；导入 SQL 前先用编辑器把文件另存为 UTF-8 编码，注意不要带 BOM，否则第一条建表语句会报语法错误。这三件事都做完，乱码基本能根治。
5.4 端口被占用：netstat 找到进程，或者换一个 server.port
现象：后端启动到一半报Web server failed to start. Port 8080 was already in use.，前端也偶尔会遇到 8081 被占。
原因：你机器上已经有另一个 Java 进程或开发服务器占用了 8080，Spring Boot 默认端口抢不到。
解决：Windows 下先执行下面的命令定位占用进程：
netstat -ano | findstr 8080netstat -ano会把端口和进程 PID 列出来，findstr 8080过滤出目标端口。看最后一列的 PID，然后执行taskkill /PID 那个PID号 /F强杀进程。如果那个进程不能杀，就在application.yml里把server.port改成 8082，同时把前端 proxy 的target改成 8082。端口冲突本身不是大事，但很多人只改后端端口、不改前端代理，导致联调时又白屏一次。
5.5 说明文档和源码对不上：LW 落后于代码，部署别照着文档硬抄
现象：说明文档里写“系统基于 Spring Boot 2.3 + Vue 2”，但pom.xml里是 Spring Boot 3.2，前端用的是 Vue 3 + Element Plus。按文档里的部署步骤走，第一步就卡住。
原因：这是毕业题源码包特别常见的情况——文档是早期模板留下的，代码在后期升级过，但文档没跟着改。说白了就是文档和源码是两拨人写的东西。
解决：所有版本号以pom.xml的spring-boot-starter-parent和package.json里的dependencies为准。部署时完全不要看文档里的环境要求，直接看我第 4 章的顺序操作。等到你要交 LW 时，再把文档里的技术栈描述、接口列表、界面截图逐一更新成当前版本。这一步逃不掉，我吃过亏：答辩老师对着文档查源码，发现类名都对不上，场面很尴尬。
6. 二开加分项：给系统加一个“选题结果导出”报表功能
最后聊一个进阶技巧，这也是让这套系统从“能跑”变成“能交差”的关键一步：把最终选题结果导出成 Excel。这个功能不在核心业务链路上，但它天然需要你把状态机、关联查询、前端下载交互串起来，答辩时讲出来很加分。
实现不复杂，常见做法是用 EasyExcel 替代 Apache POI，避免写太多样板代码。先给后端加一个导出接口：
@GetMapping("/export") public void export(@RequestParam(required = false) Integer majorId, HttpServletResponse response) throws IOException { List<ExportVO> list = selectRecordService.listPassedRecords(majorId); response.setContentType("application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"); response.setHeader("Content-Disposition", "attachment;filename=topics.xlsx"); EasyExcel.write(response.getOutputStream(), ExportVO.class) .sheet("已选题学生") .doWrite(list); }接口里只做两件事：查数据和写文件。listPassedRecords(majorId)在 Service 层做关联查询，SQL 的过滤条件是select_record.status = 1，也就是只导出教师已经确认通过的记录；majorId参数是可选的，管理员可以按专业维度筛选。ExportVO是一个普通 DTO，字段上加上 EasyExcel 的@ExcelProperty("学号")注解，列名就自动生成了。
写这个接口时有一个很容易踩的坑：直接导出所有select_record，而不过滤status = 1。这样会把待审核和退回的记录也导出去，管理员拿到的报表和实际发布结果对不上。另一个坑是学生可能同时有多条志愿记录，其中一条通过、另外两条退回，导出时必须在 SQL 里做去重，只保留确认通过的那条。
验证方法很简单：先手动让一个学生选题，跑到教师端审核通过，再调一次导出接口，打开 Excel 确认只有一条记录。如果导出的记录数和学生实际被录取数对不上，八成是状态过滤条件写漏了。
我每次部署完这类系统，都会把导出功能作为最后的验收项。因为导出本身就是一次全链路测试：前端要能正确发起下载请求、后端要能跨域返回文件流、数据库状态要准确、关联查询要没写错——它把整条链路都串起来了。文档写完再对照源码走一遍这三个状态，比反复读代码检查有效得多。希望帮到你。
本文还有配套的精品资源，点击获取
