尧图网页设计 
简介这份资源是面向计算机相关专业学生与指导教师的Java毕业设计完整项目包聚焦毕业选题环节的在线化管理。系统以Java语言开发基于JDK1.8与MySQL 5.7及以上数据库可在Eclipse或IDEA中运行涵盖用户登录注册、学生自主选题或教师指导选题、教师题目录入、题目审核标记通过与驳回、选题数据统计并导出表格等核心模块适合作为毕业设计或课程设计的参考实现。压缩包共386个文件约66.81MB包含53个java源文件、88个xml配置、56个class编译文件以及38个html、32个js、26个css等前端资源另附sql脚本、docx说明文档与pdf资料便于理解项目结构与部署流程。目前已有112人学习下载。读者可获得完整前后端源码、数据库脚本与说明文档对照Controller分层与页面实现快速掌握选题系统的开发思路并在此基础上完成二次开发或论文撰写。1. 从一份 zip 说起毕业选题系统到底在解决谁的痛每年到了十月、十一月计算机学院的群里就开始刷屏——选题系统又卡了导师名额怎么瞬间没了我的题目被抢了。如果你正在做 Java 方向的毕业设计或者被安排给学院写一套选题管理平台那这份「毕业选题系统的设计与实现源码完整前后端说明文档LW」大概率就是你正在找的东西。它要解决的核心问题很具体把过去靠 Excel 表格、微信群接龙、导师手动登记的选题流程搬成一套有角色权限、有并发控制、有数据留痕的 Web 系统。这套系统面向三类人学生要能浏览题目、提交志愿、查看录取结果导师要能发布题目、审核学生、管理名额管理员要能导入名单、分配批次、导出统计。听起来简单但真正动手你会发现难点根本不在增删改查而在同一时刻几百人抢同一个导师名额这种并发场景以及选题轮次、志愿优先级、调剂规则这套业务状态机。这也是为什么它适合作为毕业设计——业务闭环完整技术栈主流SpringBoot Vue 前后端分离又能塞进数据一致性、权限控制这些能写进论文的点。这篇笔记不打算复述一份不存在的官方文档而是顺着这个标题把一套典型选题系统从环境搭建、数据库设计、核心接口到部署排错按我实际带学生做项目的路径讲一遍。新手可以照着一步步跑通熟手可以直接跳到并发控制和状态机那两章看边界。源码和说明文档是起点不是终点真正值钱的是你理解它为什么这么设计。2. 技术选型与本地跑通SpringBoot Vue 前后端分离的最小闭环2.1 为什么是 SpringBoot Vue而不是 JSP 或纯后端模板拿到一份 Java 毕业设计源码第一件事是判断它的技术栈是否还值得投入。这套系统用的是 SpringBoot Vue 的前后端分离架构这个选择在当下几乎是毕业设计的默认答案原因有三点。第一前后端分离让前端可以独立部署Vue 打包出来的静态资源丢给 Nginx后端只负责 JSON 接口调试时前端同学不用等后端重启。第二SpringBoot 的自动装配把 Tomcat、数据源、事务管理都内置了一个 main 方法就能起服务比传统 SSM 少写一堆 XML。第三这套组合的招聘市场需求量大你写在简历上比JSP Servlet有说服力得多。对比一下另外两条路JSP 把 Java 代码嵌在 HTML 里页面逻辑和业务逻辑搅在一起改一个按钮颜色都要重新编译部署纯后端模板Thymeleaf虽然比 JSP 干净但依然逃不开服务端渲染做不了前后端并行开发。所以除非你的学校明确要求必须用 JSP否则 SpringBoot Vue 是更稳的选择。这里要提醒一句网上很多标着若依框架前后端分离的模板确实能省事但若依自带权限、代码生成器直接套用会让你的论文显得没有工作量建议只借鉴它的分层思路核心业务自己写。2.2 本地环境搭建JDK、Maven、MySQL、Node 四件套跑通这套源码本地需要四个东西JDK 8 或 11SpringBoot 2.x 对 17 支持有限别一上来就装最新版、Maven 3.6、MySQL 5.7 或 8.0、Node.js 14 以上。下面是我一般会走的命令流程Windows 和 macOS 通用路径自己替换。# 1. 验证基础环境四个命令都要有版本输出 java -version # 期望 1.8 或 11 mvn -v # 期望 3.6 以上 mysql --version # 期望 5.7 或 8.0 node -v # 期望 14 以上 # 2. 创建数据库并导入初始化脚本脚本一般在 sql/ 目录下 mysql -u root -p -e CREATE DATABASE topic_selection DEFAULT CHARSET utf8mb4; mysql -u root -p topic_selection sql/init.sql # 3. 后端改配置、编译、启动 # 编辑 src/main/resources/application.yml 里的数据库账号密码 mvn clean package -DskipTests java -jar target/topic-selection-0.0.1-SNAPSHOT.jar # 4. 前端装依赖、改接口地址、启动 cd frontend npm install # 编辑 .env.development 里的 VUE_APP_BASE_API 指向后端地址 npm run serve这几步里最容易翻车的是数据库字符集。init.sql 里如果有中文题目数据而你的库建成了 latin1导入后全是乱码所以建库时务必带DEFAULT CHARSET utf8mb4。另外application.yml里通常有server.port、spring.datasource.url、spring.datasource.username/password三个必改项url 里的时区参数建议写成serverTimezoneAsia/Shanghai否则插入时间会差 8 小时这个坑我在三个项目里都遇到过。2.3 前后端联调跨域、接口前缀和登录态怎么对齐前后端分离项目跑起来后第一个报错十有八九是 CORS 跨域。前端跑在 8080后端跑在 8081浏览器直接拦截请求。常见做法有两种后端加全局跨域配置或者前端配代理。我一般推荐开发阶段用前端代理生产环境用 Nginx 反向代理这样后端代码干净。// frontend/vue.config.js —— 开发环境代理配置 module.exports { devServer: { port: 8080, proxy: { /api: { // 所有 /api 开头的请求转发给后端 target: http://localhost:8081, // 后端实际地址 changeOrigin: true, // 修改请求头中的 Host绕过部分校验 pathRewrite: { ^/api: } // 去掉 /api 前缀再转发 } } } }这里的逻辑是前端代码里统一用/api/xxx调接口开发时由 devServer 转发到后端生产时由 Nginx 转发。changeOrigin: true是为了让后端看到的 Host 是它自己的地址避免某些安全校验拦截。pathRewrite要不要写取决于你后端 Controller 上有没有RequestMapping(/api)有的话就不需要重写没有才需要去掉前缀。登录态一般用 JWT前端把 token 存在 localStorage每次请求在拦截器里塞进Authorization头后端用过滤器校验。联调时如果一直提示 401先看请求头里 token 有没有带上再看后端 JWT 密钥和过期时间配置是否一致。3. 数据库设计与核心业务表选题系统最容易设计错的地方3.1 五张核心表用户、题目、志愿、录取、轮次选题系统的数据库设计决定了后面业务逻辑好不好写。我见过不少同学一上来就建十几张表结果字段冗余、关联混乱。其实核心就五张表用户表区分学生/导师/管理员角色、题目表导师发布含名额上限、志愿表学生填报含优先级、录取表记录最终结果、轮次表控制选题批次和时间窗口。下面这张表把关键字段和设计意图列清楚。表名关键字段设计意图sys_userid, username, password, role, real_namerole 用枚举区分三种角色避免多表继承topicid, title, teacher_id, max_count, current_count, round_id, statuscurrent_count 实时记录已选人数配合乐观锁applicationid, student_id, topic_id, priority, status, create_timepriority 表示第几志愿status 表示待审/通过/拒绝admissionid, student_id, topic_id, teacher_id, round_id最终录取结果独立成表便于统计导出roundid, name, start_time, end_time, status控制选题开放时间status 区分未开始/进行中/已结束这里有个关键设计点题目表里的current_count和max_count是并发控制的核心。很多同学图省事录取时直接查 application 表 count 一下判断有没有超名额这在低并发下没问题但几百人同时提交时必然超卖。正确做法是在 topic 表上维护计数更新时用UPDATE topic SET current_count current_count 1 WHERE id ? AND current_count max_count靠数据库行锁保证原子性返回影响行数为 0 就说明名额已满。3.2 志愿优先级与录取状态机别把业务写成 if-else 堆砌选题业务最绕的地方是状态流转。一个学生可以填多个志愿系统按轮次、按优先级依次录取导师可以审核通过或拒绝管理员可以调剂。如果全用 if-else 判断代码会变成一坨。我的做法是给 application 表定义清晰的状态枚举用状态机约束流转。// 志愿状态枚举明确每个状态能往哪走 public enum ApplicationStatus { PENDING(0, 待审核), APPROVED(1, 已通过), REJECTED(2, 已拒绝), ADJUSTED(3, 已调剂), CANCELED(4, 已取消); private final int code; private final String desc; // 构造和 getter 省略 // 定义合法流转待审 - 通过/拒绝/取消通过 - 调剂 public static boolean canTransfer(ApplicationStatus from, ApplicationStatus to) { switch (from) { case PENDING: return to APPROVED || to REJECTED || to CANCELED; case APPROVED: return to ADJUSTED; default: return false; } } }这段代码的价值在于把什么状态能变成什么状态集中在一个地方业务层调用canTransfer判断非法流转直接抛异常。参数说明code存数据库用数字desc给前端展示用两者分离避免改文案要动数据库。录取逻辑按轮次执行时先按priority升序排学生志愿再逐个尝试录取录取成功就更新 topic 的 current_count 并写 admission 表。这里要注意调剂状态是管理员手动触发的不能由学生自己改所以权限校验必须做在 service 层不能只靠前端隐藏按钮。3.3 索引与查询优化学生列表和导师名额页为什么慢系统上线后管理员最常抱怨的是学生列表加载慢导师名额页转圈。这类问题八成是缺索引。application 表按 student_id 和 topic_id 查询最频繁这两个字段都要建索引topic 表按 round_id 和 teacher_id 过滤也要建。另外统计类查询比如每个导师已录取多少人如果实时 group by数据量大了会很慢可以加一张统计缓存表或者用定时任务每小时刷新一次。-- 高频查询字段补索引注意不要给低区分度字段建索引 ALTER TABLE application ADD INDEX idx_student (student_id); ALTER TABLE application ADD INDEX idx_topic (topic_id); ALTER TABLE topic ADD INDEX idx_round_teacher (round_id, teacher_id); -- 统计每个导师当前录取人数走覆盖索引避免回表 SELECT teacher_id, COUNT(*) AS admitted FROM admission WHERE round_id ? GROUP BY teacher_id;索引不是越多越好每个索引都会拖慢写入。application 表写入频繁学生提交志愿所以索引控制在三个以内。另外注意idx_round_teacher是联合索引遵循最左前缀原则单独查 teacher_id 时用不上如果确实有这种查询再单独建一个。分页查询别用LIMIT 100000, 10这种深分页改成基于 id 的游标分页或者限制最大页数否则越翻越慢。4. 并发抢名额与数据一致性几百人同时提交怎么不超卖4.1 超卖是怎么发生的一个真实的翻车现场先说一个我亲眼见过的翻车现场。某学院的选题系统开放当天一个导师只带 3 个学生结果录取列表里出现了 5 个人。排查后发现代码逻辑是先查当前人数再判断是否小于上限最后插入录取记录三步之间没有任何锁。当 5 个请求几乎同时到达都查到了当前 2 人未满于是都执行了插入最终 5 人。这就是典型的检查后执行竞态条件。解决思路有三层数据库层用行锁或乐观锁应用层用分布式锁业务层用队列串行化。对于毕业设计这种单机部署的场景数据库乐观锁就够了不用上 Redis 分布式锁那是给自己加复杂度。核心就是前面提到的UPDATE ... WHERE current_count max_count让数据库来保证原子性。4.2 乐观锁实现一条 UPDATE 语句搞定名额扣减具体实现上我把名额扣减封装成一个 mapper 方法返回影响行数service 层根据返回值判断是否成功。// TopicMapper.java —— 原子扣减名额返回 1 表示成功0 表示已满 Update(UPDATE topic SET current_count current_count 1 WHERE id #{topicId} AND current_count max_count AND status 1) int increaseCount(Param(topicId) Long topicId); // TopicServiceImpl.java —— 录取逻辑 Transactional(rollbackFor Exception.class) public void admit(Long studentId, Long topicId) { // 1. 先尝试扣名额这一步是原子的 int affected topicMapper.increaseCount(topicId); if (affected 0) { throw new BizException(该题目名额已满请选择其他题目); } // 2. 扣减成功后再写录取记录失败会随事务回滚 Admission admission new Admission(); admission.setStudentId(studentId); admission.setTopicId(topicId); admissionMapper.insert(admission); }逻辑说明increaseCount把判断和更新合并成一条 SQL数据库在执行时会加行锁同一行的并发更新会串行执行所以不会出现两个请求都判断成功的情况。参数上status 1是额外条件确保只有开放状态的题目能被选。Transactional保证扣名额和写录取记录在同一个事务里如果插入录取记录失败名额会自动回滚不会出现名额扣了但没录取的脏数据。这里有个细节事务的隔离级别用默认的 REPEATABLE READ 就行不用改MySQL 的行锁已经够用。4.3 幂等与重复提交学生狂点提交按钮怎么办除了超卖另一个高频问题是重复提交。学生网络卡顿狂点提交志愿按钮结果同一个人对同一个题目生成了多条申请记录。前端可以加按钮禁用但那是防君子不防小人后端必须做幂等。最简单的做法是给 application 表加唯一索引UNIQUE KEY uk_student_topic (student_id, topic_id)重复插入直接报错service 层捕获后返回友好提示。-- 唯一索引防止同一学生对同一题目重复申请 ALTER TABLE application ADD UNIQUE KEY uk_student_topic (student_id, topic_id);// service 层捕获唯一键冲突转成业务提示 try { applicationMapper.insert(app); } catch (DuplicateKeyException e) { throw new BizException(你已经申请过该题目请勿重复提交); }唯一索引的代价是如果业务允许学生取消后重新申请就不能用物理删除得用逻辑删除status 标记否则唯一索引会挡住重新插入。所以 application 表建议加deleted字段查询时过滤deleted 0唯一索引改成(student_id, topic_id, deleted)这种组合或者干脆用状态字段区分。这个坑我在做第二版时才意识到第一版直接物理删除结果学生取消后无法再申请被投诉了好几次。5. 避坑与排查部署和运行阶段最常见的五个问题5.1 现象启动报错 Table xxx doesnt exist原因通常是 init.sql 没执行完整或者执行时选错了数据库。有些 init.sql 里没有USE database_name语句你如果直接mysql -u root -p init.sql而不指定库脚本会跑到默认库里。解决方法是先USE topic_selection;再执行或者导入命令里带上库名mysql -u root -p topic_selection init.sql。另外注意脚本里的建表顺序有外键依赖时顺序错了也会失败可以先关掉外键检查SET FOREIGN_KEY_CHECKS0;再导入。5.2 现象前端页面空白控制台报 404 或 502404 一般是接口路径对不上检查前端.env里的VUE_APP_BASE_API和后端 context-path 是否一致。502 通常是后端没起来或者 Nginx 转发地址写错。部署到 Tomcat 时要注意SpringBoot 内置 Tomcat 打成的 jar 包不能直接丢进外部 Tomcat 的 webapps会冲突。正确做法是打成 war 包并继承SpringBootServletInitializer或者干脆用 jar 包独立运行前面挂 Nginx。这也是tomcat 部署前后端分离项目这个搜索词下最多人踩的坑。5.3 现象中文乱码题目和姓名显示成问号三个地方要检查数据库字符集、连接 URL 字符集、前端页面编码。数据库建库建表都要utf8mb4JDBC URL 加useUnicodetruecharacterEncodingutf8前端 HTML 的 meta 声明charsetutf-8。如果都对了还乱码看是不是 MySQL 8.0 的驱动类名写成了旧版com.mysql.jdbc.Driver应该用com.mysql.cj.jdbc.Driver旧驱动在新版 MySQL 上会有编码问题。5.4 现象登录后操作提示 403 无权限这是权限校验没配对。常见原因是 JWT 过滤器里解析出的角色和接口要求的角色不匹配或者前端路由守卫拦截了但后端没拦。排查时先看后端日志里当前登录用户的角色是什么再看接口上的PreAuthorize或自定义注解要求什么角色。还有一种情况是 token 过期了但前端没跳转登录页一直拿着旧 token 请求后端返回 401前端却当成 403 处理。建议统一异常处理401 跳登录403 提示无权限。5.5 现象录取结果和志愿列表对不上这类数据不一致八成是事务没加对。比如录取时先更新了 topic 的 current_count再写 admission但方法上没加Transactional中间抛异常就导致名额扣了但没录取。排查方法是看 service 方法有没有事务注解以及异常是不是被 catch 后没重新抛出。另外如果用了多数据源或者手动提交事务要确认事务管理器配置正确。我一般会在关键写操作前后打日志记录 current_count 的变化出问题时能快速定位是哪一步没回滚。6. 从能跑到能写进论文把选题系统做出差异化的小技巧一套选题系统跑通只是及格线想让它成为能拿得出手的毕业设计得在别人也有的功能里做出别人没有的细节。我的经验是别贪多挑一两个点做深。比如并发控制大部分同学只写用了乐观锁你可以进一步做压测用 JMeter 模拟 500 并发抢 10 个名额把 QPS、响应时间、超卖次数做成图表放进论文这就是实打实的数据。再比如状态机别人用 if-else你用枚举加流转校验再画一张状态流转图论文里就是加分项。另一个差异化方向是数据统计和可视化。选题结束后管理员需要知道哪些题目热门、哪些导师名额没满、各专业选题分布如何。用 ECharts 做一个统计看板后端提供聚合接口前端渲染柱状图和饼图。这个功能代码量不大但演示效果好答辩时老师一眼就能看到亮点。实现上注意聚合查询别实时算数据量大时用定时任务预计算存到统计表里。-- 预计算统计表定时任务每小时刷新一次 CREATE TABLE stat_topic ( id BIGINT PRIMARY KEY AUTO_INCREMENT, round_id BIGINT, topic_id BIGINT, apply_count INT DEFAULT 0, -- 申请人数 admit_count INT DEFAULT 0, -- 录取人数 refresh_time DATETIME ); -- 刷新语句用 INSERT ... ON DUPLICATE KEY UPDATE 实现幂等 INSERT INTO stat_topic (round_id, topic_id, apply_count, admit_count, refresh_time) SELECT t.round_id, t.id, (SELECT COUNT(*) FROM application a WHERE a.topic_id t.id AND a.deleted 0), (SELECT COUNT(*) FROM admission ad WHERE ad.topic_id t.id), NOW() FROM topic t WHERE t.round_id ? ON DUPLICATE KEY UPDATE apply_count VALUES(apply_count), admit_count VALUES(admit_count), refresh_time VALUES(refresh_time);这段 SQL 的关键是ON DUPLICATE KEY UPDATE配合 topic_id 上的唯一索引实现有则更新、无则插入定时任务重复执行也不会产生脏数据。参数上round_id按轮次统计deleted 0过滤掉逻辑删除的申请。刷新频率别太高每小时一次足够太频繁反而增加数据库压力。最后说个我自己的习惯每做完一个模块我都会把为什么这么设计写成一段注释或者笔记而不是只留代码。因为答辩时老师问的往往不是你怎么实现的而是你为什么不用另一种方案。比如为什么用乐观锁不用悲观锁为什么用 JWT 不用 Session这些取舍想清楚了论文的深度自然就有了。源码和说明文档能帮你起步但真正让你通过答辩的是你对每个技术决策的理解。希望帮到你。本文还有配套的精品资源点击获取 毕业选题系统源码实战：SpringBoot+Vue前后端分离与并发抢名额防超卖
简介这份资源是面向计算机相关专业学生与指导教师的Java毕业设计完整项目包聚焦毕业选题环节的在线化管理。系统以Java语言开发基于JDK1.8与MySQL 5.7及以上数据库可在Eclipse或IDEA中运行涵盖用户登录注册、学生自主选题或教师指导选题、教师题目录入、题目审核标记通过与驳回、选题数据统计并导出表格等核心模块适合作为毕业设计或课程设计的参考实现。压缩包共386个文件约66.81MB包含53个java源文件、88个xml配置、56个class编译文件以及38个html、32个js、26个css等前端资源另附sql脚本、docx说明文档与pdf资料便于理解项目结构与部署流程。目前已有112人学习下载。读者可获得完整前后端源码、数据库脚本与说明文档对照Controller分层与页面实现快速掌握选题系统的开发思路并在此基础上完成二次开发或论文撰写。1. 从一份 zip 说起毕业选题系统到底在解决谁的痛每年到了十月、十一月计算机学院的群里就开始刷屏——选题系统又卡了导师名额怎么瞬间没了我的题目被抢了。如果你正在做 Java 方向的毕业设计或者被安排给学院写一套选题管理平台那这份「毕业选题系统的设计与实现源码完整前后端说明文档LW」大概率就是你正在找的东西。它要解决的核心问题很具体把过去靠 Excel 表格、微信群接龙、导师手动登记的选题流程搬成一套有角色权限、有并发控制、有数据留痕的 Web 系统。这套系统面向三类人学生要能浏览题目、提交志愿、查看录取结果导师要能发布题目、审核学生、管理名额管理员要能导入名单、分配批次、导出统计。听起来简单但真正动手你会发现难点根本不在增删改查而在同一时刻几百人抢同一个导师名额这种并发场景以及选题轮次、志愿优先级、调剂规则这套业务状态机。这也是为什么它适合作为毕业设计——业务闭环完整技术栈主流SpringBoot Vue 前后端分离又能塞进数据一致性、权限控制这些能写进论文的点。这篇笔记不打算复述一份不存在的官方文档而是顺着这个标题把一套典型选题系统从环境搭建、数据库设计、核心接口到部署排错按我实际带学生做项目的路径讲一遍。新手可以照着一步步跑通熟手可以直接跳到并发控制和状态机那两章看边界。源码和说明文档是起点不是终点真正值钱的是你理解它为什么这么设计。2. 技术选型与本地跑通SpringBoot Vue 前后端分离的最小闭环2.1 为什么是 SpringBoot Vue而不是 JSP 或纯后端模板拿到一份 Java 毕业设计源码第一件事是判断它的技术栈是否还值得投入。这套系统用的是 SpringBoot Vue 的前后端分离架构这个选择在当下几乎是毕业设计的默认答案原因有三点。第一前后端分离让前端可以独立部署Vue 打包出来的静态资源丢给 Nginx后端只负责 JSON 接口调试时前端同学不用等后端重启。第二SpringBoot 的自动装配把 Tomcat、数据源、事务管理都内置了一个 main 方法就能起服务比传统 SSM 少写一堆 XML。第三这套组合的招聘市场需求量大你写在简历上比JSP Servlet有说服力得多。对比一下另外两条路JSP 把 Java 代码嵌在 HTML 里页面逻辑和业务逻辑搅在一起改一个按钮颜色都要重新编译部署纯后端模板Thymeleaf虽然比 JSP 干净但依然逃不开服务端渲染做不了前后端并行开发。所以除非你的学校明确要求必须用 JSP否则 SpringBoot Vue 是更稳的选择。这里要提醒一句网上很多标着若依框架前后端分离的模板确实能省事但若依自带权限、代码生成器直接套用会让你的论文显得没有工作量建议只借鉴它的分层思路核心业务自己写。2.2 本地环境搭建JDK、Maven、MySQL、Node 四件套跑通这套源码本地需要四个东西JDK 8 或 11SpringBoot 2.x 对 17 支持有限别一上来就装最新版、Maven 3.6、MySQL 5.7 或 8.0、Node.js 14 以上。下面是我一般会走的命令流程Windows 和 macOS 通用路径自己替换。# 1. 验证基础环境四个命令都要有版本输出 java -version # 期望 1.8 或 11 mvn -v # 期望 3.6 以上 mysql --version # 期望 5.7 或 8.0 node -v # 期望 14 以上 # 2. 创建数据库并导入初始化脚本脚本一般在 sql/ 目录下 mysql -u root -p -e CREATE DATABASE topic_selection DEFAULT CHARSET utf8mb4; mysql -u root -p topic_selection sql/init.sql # 3. 后端改配置、编译、启动 # 编辑 src/main/resources/application.yml 里的数据库账号密码 mvn clean package -DskipTests java -jar target/topic-selection-0.0.1-SNAPSHOT.jar # 4. 前端装依赖、改接口地址、启动 cd frontend npm install # 编辑 .env.development 里的 VUE_APP_BASE_API 指向后端地址 npm run serve这几步里最容易翻车的是数据库字符集。init.sql 里如果有中文题目数据而你的库建成了 latin1导入后全是乱码所以建库时务必带DEFAULT CHARSET utf8mb4。另外application.yml里通常有server.port、spring.datasource.url、spring.datasource.username/password三个必改项url 里的时区参数建议写成serverTimezoneAsia/Shanghai否则插入时间会差 8 小时这个坑我在三个项目里都遇到过。2.3 前后端联调跨域、接口前缀和登录态怎么对齐前后端分离项目跑起来后第一个报错十有八九是 CORS 跨域。前端跑在 8080后端跑在 8081浏览器直接拦截请求。常见做法有两种后端加全局跨域配置或者前端配代理。我一般推荐开发阶段用前端代理生产环境用 Nginx 反向代理这样后端代码干净。// frontend/vue.config.js —— 开发环境代理配置 module.exports { devServer: { port: 8080, proxy: { /api: { // 所有 /api 开头的请求转发给后端 target: http://localhost:8081, // 后端实际地址 changeOrigin: true, // 修改请求头中的 Host绕过部分校验 pathRewrite: { ^/api: } // 去掉 /api 前缀再转发 } } } }这里的逻辑是前端代码里统一用/api/xxx调接口开发时由 devServer 转发到后端生产时由 Nginx 转发。changeOrigin: true是为了让后端看到的 Host 是它自己的地址避免某些安全校验拦截。pathRewrite要不要写取决于你后端 Controller 上有没有RequestMapping(/api)有的话就不需要重写没有才需要去掉前缀。登录态一般用 JWT前端把 token 存在 localStorage每次请求在拦截器里塞进Authorization头后端用过滤器校验。联调时如果一直提示 401先看请求头里 token 有没有带上再看后端 JWT 密钥和过期时间配置是否一致。3. 数据库设计与核心业务表选题系统最容易设计错的地方3.1 五张核心表用户、题目、志愿、录取、轮次选题系统的数据库设计决定了后面业务逻辑好不好写。我见过不少同学一上来就建十几张表结果字段冗余、关联混乱。其实核心就五张表用户表区分学生/导师/管理员角色、题目表导师发布含名额上限、志愿表学生填报含优先级、录取表记录最终结果、轮次表控制选题批次和时间窗口。下面这张表把关键字段和设计意图列清楚。表名关键字段设计意图sys_userid, username, password, role, real_namerole 用枚举区分三种角色避免多表继承topicid, title, teacher_id, max_count, current_count, round_id, statuscurrent_count 实时记录已选人数配合乐观锁applicationid, student_id, topic_id, priority, status, create_timepriority 表示第几志愿status 表示待审/通过/拒绝admissionid, student_id, topic_id, teacher_id, round_id最终录取结果独立成表便于统计导出roundid, name, start_time, end_time, status控制选题开放时间status 区分未开始/进行中/已结束这里有个关键设计点题目表里的current_count和max_count是并发控制的核心。很多同学图省事录取时直接查 application 表 count 一下判断有没有超名额这在低并发下没问题但几百人同时提交时必然超卖。正确做法是在 topic 表上维护计数更新时用UPDATE topic SET current_count current_count 1 WHERE id ? AND current_count max_count靠数据库行锁保证原子性返回影响行数为 0 就说明名额已满。3.2 志愿优先级与录取状态机别把业务写成 if-else 堆砌选题业务最绕的地方是状态流转。一个学生可以填多个志愿系统按轮次、按优先级依次录取导师可以审核通过或拒绝管理员可以调剂。如果全用 if-else 判断代码会变成一坨。我的做法是给 application 表定义清晰的状态枚举用状态机约束流转。// 志愿状态枚举明确每个状态能往哪走 public enum ApplicationStatus { PENDING(0, 待审核), APPROVED(1, 已通过), REJECTED(2, 已拒绝), ADJUSTED(3, 已调剂), CANCELED(4, 已取消); private final int code; private final String desc; // 构造和 getter 省略 // 定义合法流转待审 - 通过/拒绝/取消通过 - 调剂 public static boolean canTransfer(ApplicationStatus from, ApplicationStatus to) { switch (from) { case PENDING: return to APPROVED || to REJECTED || to CANCELED; case APPROVED: return to ADJUSTED; default: return false; } } }这段代码的价值在于把什么状态能变成什么状态集中在一个地方业务层调用canTransfer判断非法流转直接抛异常。参数说明code存数据库用数字desc给前端展示用两者分离避免改文案要动数据库。录取逻辑按轮次执行时先按priority升序排学生志愿再逐个尝试录取录取成功就更新 topic 的 current_count 并写 admission 表。这里要注意调剂状态是管理员手动触发的不能由学生自己改所以权限校验必须做在 service 层不能只靠前端隐藏按钮。3.3 索引与查询优化学生列表和导师名额页为什么慢系统上线后管理员最常抱怨的是学生列表加载慢导师名额页转圈。这类问题八成是缺索引。application 表按 student_id 和 topic_id 查询最频繁这两个字段都要建索引topic 表按 round_id 和 teacher_id 过滤也要建。另外统计类查询比如每个导师已录取多少人如果实时 group by数据量大了会很慢可以加一张统计缓存表或者用定时任务每小时刷新一次。-- 高频查询字段补索引注意不要给低区分度字段建索引 ALTER TABLE application ADD INDEX idx_student (student_id); ALTER TABLE application ADD INDEX idx_topic (topic_id); ALTER TABLE topic ADD INDEX idx_round_teacher (round_id, teacher_id); -- 统计每个导师当前录取人数走覆盖索引避免回表 SELECT teacher_id, COUNT(*) AS admitted FROM admission WHERE round_id ? GROUP BY teacher_id;索引不是越多越好每个索引都会拖慢写入。application 表写入频繁学生提交志愿所以索引控制在三个以内。另外注意idx_round_teacher是联合索引遵循最左前缀原则单独查 teacher_id 时用不上如果确实有这种查询再单独建一个。分页查询别用LIMIT 100000, 10这种深分页改成基于 id 的游标分页或者限制最大页数否则越翻越慢。4. 并发抢名额与数据一致性几百人同时提交怎么不超卖4.1 超卖是怎么发生的一个真实的翻车现场先说一个我亲眼见过的翻车现场。某学院的选题系统开放当天一个导师只带 3 个学生结果录取列表里出现了 5 个人。排查后发现代码逻辑是先查当前人数再判断是否小于上限最后插入录取记录三步之间没有任何锁。当 5 个请求几乎同时到达都查到了当前 2 人未满于是都执行了插入最终 5 人。这就是典型的检查后执行竞态条件。解决思路有三层数据库层用行锁或乐观锁应用层用分布式锁业务层用队列串行化。对于毕业设计这种单机部署的场景数据库乐观锁就够了不用上 Redis 分布式锁那是给自己加复杂度。核心就是前面提到的UPDATE ... WHERE current_count max_count让数据库来保证原子性。4.2 乐观锁实现一条 UPDATE 语句搞定名额扣减具体实现上我把名额扣减封装成一个 mapper 方法返回影响行数service 层根据返回值判断是否成功。// TopicMapper.java —— 原子扣减名额返回 1 表示成功0 表示已满 Update(UPDATE topic SET current_count current_count 1 WHERE id #{topicId} AND current_count max_count AND status 1) int increaseCount(Param(topicId) Long topicId); // TopicServiceImpl.java —— 录取逻辑 Transactional(rollbackFor Exception.class) public void admit(Long studentId, Long topicId) { // 1. 先尝试扣名额这一步是原子的 int affected topicMapper.increaseCount(topicId); if (affected 0) { throw new BizException(该题目名额已满请选择其他题目); } // 2. 扣减成功后再写录取记录失败会随事务回滚 Admission admission new Admission(); admission.setStudentId(studentId); admission.setTopicId(topicId); admissionMapper.insert(admission); }逻辑说明increaseCount把判断和更新合并成一条 SQL数据库在执行时会加行锁同一行的并发更新会串行执行所以不会出现两个请求都判断成功的情况。参数上status 1是额外条件确保只有开放状态的题目能被选。Transactional保证扣名额和写录取记录在同一个事务里如果插入录取记录失败名额会自动回滚不会出现名额扣了但没录取的脏数据。这里有个细节事务的隔离级别用默认的 REPEATABLE READ 就行不用改MySQL 的行锁已经够用。4.3 幂等与重复提交学生狂点提交按钮怎么办除了超卖另一个高频问题是重复提交。学生网络卡顿狂点提交志愿按钮结果同一个人对同一个题目生成了多条申请记录。前端可以加按钮禁用但那是防君子不防小人后端必须做幂等。最简单的做法是给 application 表加唯一索引UNIQUE KEY uk_student_topic (student_id, topic_id)重复插入直接报错service 层捕获后返回友好提示。-- 唯一索引防止同一学生对同一题目重复申请 ALTER TABLE application ADD UNIQUE KEY uk_student_topic (student_id, topic_id);// service 层捕获唯一键冲突转成业务提示 try { applicationMapper.insert(app); } catch (DuplicateKeyException e) { throw new BizException(你已经申请过该题目请勿重复提交); }唯一索引的代价是如果业务允许学生取消后重新申请就不能用物理删除得用逻辑删除status 标记否则唯一索引会挡住重新插入。所以 application 表建议加deleted字段查询时过滤deleted 0唯一索引改成(student_id, topic_id, deleted)这种组合或者干脆用状态字段区分。这个坑我在做第二版时才意识到第一版直接物理删除结果学生取消后无法再申请被投诉了好几次。5. 避坑与排查部署和运行阶段最常见的五个问题5.1 现象启动报错 Table xxx doesnt exist原因通常是 init.sql 没执行完整或者执行时选错了数据库。有些 init.sql 里没有USE database_name语句你如果直接mysql -u root -p init.sql而不指定库脚本会跑到默认库里。解决方法是先USE topic_selection;再执行或者导入命令里带上库名mysql -u root -p topic_selection init.sql。另外注意脚本里的建表顺序有外键依赖时顺序错了也会失败可以先关掉外键检查SET FOREIGN_KEY_CHECKS0;再导入。5.2 现象前端页面空白控制台报 404 或 502404 一般是接口路径对不上检查前端.env里的VUE_APP_BASE_API和后端 context-path 是否一致。502 通常是后端没起来或者 Nginx 转发地址写错。部署到 Tomcat 时要注意SpringBoot 内置 Tomcat 打成的 jar 包不能直接丢进外部 Tomcat 的 webapps会冲突。正确做法是打成 war 包并继承SpringBootServletInitializer或者干脆用 jar 包独立运行前面挂 Nginx。这也是tomcat 部署前后端分离项目这个搜索词下最多人踩的坑。5.3 现象中文乱码题目和姓名显示成问号三个地方要检查数据库字符集、连接 URL 字符集、前端页面编码。数据库建库建表都要utf8mb4JDBC URL 加useUnicodetruecharacterEncodingutf8前端 HTML 的 meta 声明charsetutf-8。如果都对了还乱码看是不是 MySQL 8.0 的驱动类名写成了旧版com.mysql.jdbc.Driver应该用com.mysql.cj.jdbc.Driver旧驱动在新版 MySQL 上会有编码问题。5.4 现象登录后操作提示 403 无权限这是权限校验没配对。常见原因是 JWT 过滤器里解析出的角色和接口要求的角色不匹配或者前端路由守卫拦截了但后端没拦。排查时先看后端日志里当前登录用户的角色是什么再看接口上的PreAuthorize或自定义注解要求什么角色。还有一种情况是 token 过期了但前端没跳转登录页一直拿着旧 token 请求后端返回 401前端却当成 403 处理。建议统一异常处理401 跳登录403 提示无权限。5.5 现象录取结果和志愿列表对不上这类数据不一致八成是事务没加对。比如录取时先更新了 topic 的 current_count再写 admission但方法上没加Transactional中间抛异常就导致名额扣了但没录取。排查方法是看 service 方法有没有事务注解以及异常是不是被 catch 后没重新抛出。另外如果用了多数据源或者手动提交事务要确认事务管理器配置正确。我一般会在关键写操作前后打日志记录 current_count 的变化出问题时能快速定位是哪一步没回滚。6. 从能跑到能写进论文把选题系统做出差异化的小技巧一套选题系统跑通只是及格线想让它成为能拿得出手的毕业设计得在别人也有的功能里做出别人没有的细节。我的经验是别贪多挑一两个点做深。比如并发控制大部分同学只写用了乐观锁你可以进一步做压测用 JMeter 模拟 500 并发抢 10 个名额把 QPS、响应时间、超卖次数做成图表放进论文这就是实打实的数据。再比如状态机别人用 if-else你用枚举加流转校验再画一张状态流转图论文里就是加分项。另一个差异化方向是数据统计和可视化。选题结束后管理员需要知道哪些题目热门、哪些导师名额没满、各专业选题分布如何。用 ECharts 做一个统计看板后端提供聚合接口前端渲染柱状图和饼图。这个功能代码量不大但演示效果好答辩时老师一眼就能看到亮点。实现上注意聚合查询别实时算数据量大时用定时任务预计算存到统计表里。-- 预计算统计表定时任务每小时刷新一次 CREATE TABLE stat_topic ( id BIGINT PRIMARY KEY AUTO_INCREMENT, round_id BIGINT, topic_id BIGINT, apply_count INT DEFAULT 0, -- 申请人数 admit_count INT DEFAULT 0, -- 录取人数 refresh_time DATETIME ); -- 刷新语句用 INSERT ... ON DUPLICATE KEY UPDATE 实现幂等 INSERT INTO stat_topic (round_id, topic_id, apply_count, admit_count, refresh_time) SELECT t.round_id, t.id, (SELECT COUNT(*) FROM application a WHERE a.topic_id t.id AND a.deleted 0), (SELECT COUNT(*) FROM admission ad WHERE ad.topic_id t.id), NOW() FROM topic t WHERE t.round_id ? ON DUPLICATE KEY UPDATE apply_count VALUES(apply_count), admit_count VALUES(admit_count), refresh_time VALUES(refresh_time);这段 SQL 的关键是ON DUPLICATE KEY UPDATE配合 topic_id 上的唯一索引实现有则更新、无则插入定时任务重复执行也不会产生脏数据。参数上round_id按轮次统计deleted 0过滤掉逻辑删除的申请。刷新频率别太高每小时一次足够太频繁反而增加数据库压力。最后说个我自己的习惯每做完一个模块我都会把为什么这么设计写成一段注释或者笔记而不是只留代码。因为答辩时老师问的往往不是你怎么实现的而是你为什么不用另一种方案。比如为什么用乐观锁不用悲观锁为什么用 JWT 不用 Session这些取舍想清楚了论文的深度自然就有了。源码和说明文档能帮你起步但真正让你通过答辩的是你对每个技术决策的理解。希望帮到你。本文还有配套的精品资源点击获取