SpringBoot+Vue毕业论文选题管理系统：从数据库设计到并发控制实战

1. 为什么毕业论文选题管理需要一个专属系统

每到毕业季，指导老师手头同时管着七八个学生，学生又急着定课题，教学秘书那边催着交选题汇总表，三方互相拉扯，几乎每个学院的毕业季都像打仗一样。

我做这个 springboot+vue 毕业论文选题管理系统，起因其实挺朴素：某高校的导师和教务人员受够了 Excel 传阅和微信群抢题。学生看不到哪些课题有名额、哪些已经被选走，老师不知道自己的课题有没有人选中，教务员还要反复核对选题人数是否超额。整个过程信息不同步、操作不透明、追溯无依据，一旦出现争议根本没有记录可以查。

这个系统要解决的就是三件事：课题申报和审核线上化、学生选题过程透明化、教师指导与进度管理闭环化。它不是一个复杂的业务中台，而是一个典型的“流程型管理系统”，覆盖从课题发布、学生选题、教师审核到中期检查和最终成绩归档的完整链路。

如果你正在做类似的管理系统开发，或者你本身就是毕业论文工作的参与者，这篇文章里的数据库设计、角色权限、并发控制、前后端联调方案，都是可以直接抄作业的实战内容。尤其是选题高峰期“多人抢同一课题”这种并发场景，我把踩过的坑和最终方案都写清楚了。

2. 技术选型：SpringBoot + Vue 是怎么定下来的

2.1 后端为什么选 SpringBoot 而不是 SSH 或 Node

很多人会纠结，一个选题管理系统而已，用 Node.js 加个 Express 不也能做？确实能做，但放到真实的高校毕设环境里，你至少要考虑三件事：第一是稳定性，第二是团队协作成本，第三是之后的扩展空间。

SpringBoot 在这三个维度上都比较稳。它本身就是一个整合好的运行时框架，内嵌 Tomcat，不用单独部署容器，java -jar 就能跑起来。配合 Spring Data JPA 或 MyBatis Plus 操作数据库，能少写一大堆样板代码。再加上 Spring Security 或 Sa-Token 做权限控制、Spring AOP 做操作日志，这些能力都是现成的，不需要自己造轮子。

我选 SpringBoot 还有一个现实原因：这种系统大概率要经过不止一轮的迭代。今天只做选题管理，明天可能就要加问卷采集、加评分管理、加通知推送。SpringBoot 的生态足够大，后续接入 Redis、RabbitMQ、文件存储都很顺畅，不会被技术底座限制住。

2.2 前端为什么选 Vue 而不是传统模板引擎

服务端渲染的 Thymeleaf 不是不能用，但问题在于选题系统的交互形态。学生要看课题列表、要筛选教师、要提交选题意向；老师要双列表拖拽审核；管理员要看各种统计图表。这些都是典型的前后端分离场景，用传统模板引擎会写得非常痛苦。

Vue 的优势在于组件化和响应式状态管理。我把课题列表、筛选面板、弹窗表单、状态标签全部拆成独立组件，页面之间的数据结构通过 Vuex 管理，路由用 Vue Router 控制。这样学生端、教师端虽然是两套界面，但复用同一套 API 接口和组件逻辑，开发效率翻倍。

技术栈选择上，我建议版本锁定 SpringBoot 2.7.x 配合 Vue 3 + Element Plus。SpringBoot 3.x 虽然也成熟了，但有些旧版依赖的兼容性处理起来比较费时间；Vue 3 的组合式 API 配合 Element Plus 做后台管理界面，写起来比 Options API 更顺手。

2.3 完整技术栈和工程目录

做系统之前先把技术栈定死，后面能少很多无意义的争吵。我的这套方案是这样的：

工程结构上，后端按 controller / service / mapper / entity 四层分包，前端按 views / components / api / store / router 划分。这种结构不算新颖，但胜在清晰，后期接手的人不需要花时间猜代码在哪。

3. 数据库设计：核心表结构与状态机

3.1 角色与核心业务表的关系

选题管理系统虽然功能看着多，但核心表就五张左右：用户表、课题表、选题记录表、进度记录表、公告表。

用户表建议做成统一结构，用 user_type 字段区分学生、教师、管理员三个角色，不要拆成三张表。拆表看起来很规范，实际上权限判断和关联查询都会变得啰嗦。学生信息里有学号、班级，教师信息里有工号、职称，这些差异字段单独用 student_info 和 teacher_info 扩展表存，主体仍在同一条账户数据上。

课题表是整个系统业务的核心。每个课题要记录所属教师、课题名称、研究方向、选题人数上限、当前已选人数、审核状态和时间窗口。这里有一个容易忽略的点：课题的“选题开放时间”一定要做独立的窗口字段，而不是直接复用系统的全局配置。因为不同教师可能希望在自己方便的时间段内审核学生，管理员也需要能够精细控制“是否开放选题”的整体开关。

3.2 选题记录表的状态流转

选题记录表是最容易踩坑的地方。表里除了 student_id 和 topic_id，一定要有一个 status 字段，并且用数字约定状态值。我的约定是：

为什么用什么状态值都要写死？因为 CRUD 系统里大量 bug 来自状态错乱。比如学生已经选题成功，却还能重复提交申请，就是因为代码里没有对已有的成功记录做唯一性校验。这种问题在后期统计“选题通过率”的时候会变成灾难性的数据错误。

我还建议加一个 update_time 字段，并在每次状态变化时把前后状态写入操作日志表。很多学校在毕业季会出现“学生说选了、教师说没收到、教务说要个说法”的纠纷，操作日志就是唯一的仲裁依据。日志表的成本很低，但价值很高，绝不要省略。

3.3 配额与防超额设计

教师指导学生的数量不能无限，否则会出现一个老师带二十个人的离谱情况。因此在课题表或教师配置表里必须设计配额逻辑。

我第一次做这个系统的时候是在代码里硬核判断 current_count >= max_count，这种方式在单用户操作时没问题，一旦并发就玩脱了。后来我改成事务内加锁的方式解决，具体实现在后面专门讲。数据库设计层面要注意的是：配额字段放在教师表里还是课题表里，取决于你的业务粒度。

如果每个老师的所有课题共享同一配额，就放教师表；如果每个课题单独限制人数，就放课题表。实际业务中往往两者同时存在：教师有总指导学生数上限，课题也有单独的人数上限。这个双重限制，在实现时要在一个事务里同时校验，不然会出现总配额没超、某个课题却爆满的尴尬。

4. 核心功能模块与角色权限控制

4.1 统一登录和权限控制

三个角色共用一套登录逻辑，登录后根据用户类型跳转到不同首页。后端的权限控制我用 Sa-Token 或者 JWT 都试过，最后选择 Sa-Token，因为它内置了权限码和角色码，代码可读性更强。

前端拿到 token 后存到 localStorage，通过路由守卫逐个比对当前路由的 meta.roles 字段。如果用户角色不在允许列表里，直接重定向到 403 页面。整套逻辑清晰且好维护。

typescript复制// 前端路由守卫核心代码
router.beforeEach((to, from, next) => {
  const token = localStorage.getItem('token')
  if (!token) {
    if (to.path === '/login') return next()
    return next('/login')
  }
  const role = localStorage.getItem('userRole')
  if (to.meta && to.meta.roles && to.meta.roles.indexOf(role) === -1) {
    return next('/403')
  }
  next()
})

这一段代码基本够用，但是要注意 token 过期问题。如果后端只返回 401，而前端没有统一拦截处理，用户就会遇到“点着点着突然卡住，刷新又回到登录页”的体验问题。我是在 Axios 响应拦截器里统一判断 HTTP 状态码，遇到 401 时清空本地登录态并跳转登录页，同时给用户一个“登录已过期，请重新登录”的提示。

4.2 学生端：从课题浏览到选题确认

学生端的核心诉求只有一个：快速找到合适且能选上的课题。

课题列表页默认展示所有“审核通过且当前可申请”的课题，按研究方向分类筛选，搜索框支持课题名称和教师姓名模糊查询。每张课题卡片上显示剩余名额、时间窗口、课题简介。如果是第一次进入系统，可以直接收藏意向课题，方便后续对比。

提交选题申请之前，学生需要确认自己的状态是“未选题”。如果已经有一条状态为“待审核”或“已通过”的选题记录，后端必须拒绝再次提交。这个校验必须在后端做，前端隐藏按钮只是体验优化，不是安全边界。

学生提交申请的那一刻，后端直接扣减课题剩余名额。这里没做待锁定机制，因为考虑到学校场景里学生总量不大、并发量也可以接受。如果做锁定机制，反而会引来不少问题，比如学生选了不确认、占着名额不释放，教师要手动清理，这个复杂度完全不值得。

4.3 教师端：课题申报和审核工作台

教师端的功能密度其实比学生端高得多。第一步是课题申报，教师填写课题名称、研究内容、难度、类别，提交后由管理员审核。课题审核通过才能进入学生选题池。

第二步是选题审核。当学生提交申请后，教师工作台会出现待办列表。教师可以查看学生的基础信息和已修课程成绩（如果有相关数据权限），然后选择批准或拒绝。如果教师希望约定时间面试筛选，系统里还支持“发起线下沟通待确认”状态，状态流转会多一条分支。

第三步是过程管理。课题通过后，教师可以定期发布阶段任务，比如开题报告提交、中期检查、初稿提交等。每个阶段有截止日期和完成状态。这条线看似简单，实际上比选题本身更重要，因为它是论文质量过程监控的关键抓手。

4.4 管理员端：兜底、统计和流程控制

管理员端没有太炫酷的功能，但每一样都服务全局：

• 用户导入：支持 Excel 批量导入学生和教师账号，初始密码可设置身份证后六位或学号。
• 流程开关：控制“选题申报”“开放选题”“开题检查”“中期答辩”等阶段是否可用。
• 课题审核：对教师申报的课题做内容合规检查。
• 报表统计：按学院、专业、课题方向统计学生选题分布情况；实时查看当前未选题学生列表。
• 手工调题：个别学生因特殊原因没选上课题时，管理员手动指定课题，同时记录操作日志。

报表统计是我最建议优先实现的模块。它虽然在需求文档里只占一行字，但在答辩汇报和学校巡检时，图表化展示比任何功能都有说服力。

5. 后端关键流程与并发问题实战

5.1 选题提交流程的接口设计

后端最重要的一个接口就是学生提交选题申请。给出一段核心代码，注意这是综合了大量项目实践后的精简版本，但流程是完整的：

java复制@PostMapping("/api/selection/apply")
@SaCheckRole("student")
public Result apply(@RequestBody SelectionApplyDTO dto) {
    return selectionService.apply(dto);
}

@Transactional(rollbackFor = Exception.class)
public void apply(SelectionApplyDTO dto) {
    // 1. 校验学生当前选题状态
    StudentSelection current = getCurrentByStudent(dto.getStudentId());
    if (current != null && !StatusEnum.REJECTED.equals(current.getStatus())) {
        throw new BizException("当前已有选题记录，不可重复申请");
    }

    // 2. 锁定课题行，防止并发超选
    TopicDO topic = topicMapper.selectByIdForUpdate(dto.getTopicId());

    // 3. 校验课题状态、时间窗口和剩余名额
    if (!TopicStatusEnum.APPROVED.equals(topic.getStatus())) {
        throw new BizException("课题未开放申请");
    }
    if (topic.getSelectedCount() >= topic.getMaxCount()) {
        throw new BizException("该课题剩余名额不足");
    }

    // 4. 插入选题记录、更新已选人数
    selectionMapper.insert(buildRecord(dto, topic));
    topic.setSelectedCount(topic.getSelectedCount() + 1);
    topicMapper.updateById(topic);
}

关键就在第二步的 selectByIdForUpdate，这是 MySQL 的行级排他锁。多个学生同时抢同一个课题时，后面的请求会阻塞在当前行锁上，等前一个事务提交后再执行校验。这样就从根本上避免了两个人同时通过名额校验、最终超过人数上限的问题。

5.2 事务边界和控制粒度

事务在这里绝不能只包住单条 SQL，而是要把“校验 + 插入 + 更新计数”整体包进一个事务。如果只对 update 加锁，那么校验和插入之间还是会有空隙。

另外一个我踩过的坑是事务内部调用 selectByIdForUpdate 的时候，如果对应的索引没建好，MySQL 会升级为锁整个表，反而拖垮了其他不相关的操作。给外键字段、状态字段、学号、课题编号都建好索引，不是可有可无的优化，而是直接影响并发正确性的基础。

5.3 时间窗口控制的两种实现方式

选题系统里的时间窗口控制很容易被忽略。我最初是把开始和截止时间写死在前端页面里，结果过了截止时间学生改个系统时间还能继续提交，后端完全没有拦截。正确做法是后端每次校验时取出当前时间和系统配置比较：

java复制SelectionConfig config = configMapper.selectOne();
LocalDateTime now = LocalDateTime.now();
if (now.isBefore(config.getSelectionStart()) || now.isAfter(config.getSelectionEnd())) {
    throw new BizException("当前不在选题开放时间内");
}

这种实现逻辑很简单，但要注意的是服务器时间必须做 NTP 时钟同步。否则服务器时间和真实时间偏差太大，可能出现学生明明可以选题却提示“未开放”或反过来过期还能提交的情况。

6. 前端实现细节与体验优化

6.1 Axios 拦截器统一处理请求与异常

前端第一道关卡就是统一封装请求。项目里所有接口调用都走同一个 Axios 实例，这样拦截器可以统一处理 token 注入、错误提示、401 跳转。

typescript复制const service = axios.create({
  baseURL: '/api',
  timeout: 15000
})

service.interceptors.request.use(config => {
  const token = localStorage.getItem('token')
  if (token) config.headers['Token'] = token
  return config
})

service.interceptors.response.use(
  response => {
    const res = response.data
    if (res.code !== 200) {
      ElMessage.error(res.message)
      return Promise.reject(new Error(res.message))
    }
    return res
  },
  error => {
    if (error.response && error.response.status === 401) {
      localStorage.clear()
      router.push('/login')
    }
    ElMessage.error(error.response?.data?.message || '网络异常')
    return Promise.reject(error)
  }
)

这块代码几乎每个 Vue 项目都会用，但有一个细节值得多提一句：不要把后端返回的 code 和 HTTP 状态码混为一谈。后端业务的逻辑错误（比如选题冲突、名额不足）应当返回 HTTP 200 + 业务 code 非 0，让前端走统一的业务错误处理；只有真正未认证、未授权的情况才用 HTTP 401/403。这样前后端对错误的认知会一致很多。

6.2 列表页的性能与交互细节

课题列表页如果数据量上千，一次性渲染所有卡片会很卡。我建议使用 Element Plus 的 el-pagination 做服务端分页，每页 10 条。筛选条件通过请求参数提交，例如 keyword、categoryId、status、pageNum、pageSize。

筛选时还要注意一个问题：用户筛选“剩余名额 > 0”时，这份数据在用户看到后的一秒内可能就已经变化了。所以在界面展示上，我刻意把“剩余名额”数字做成实时从后端返回，但不做前端本地缓存，并且申请提交时后端再次做最终校验。前端展示只是信息参考，后端校验才是可信依据。

6.3 表单校验与组件封装

课题申报页面是教师端使用频率最高的表单之一。涉及字段包括课题名称、研究方向、内容简介、难度、最大选人数、时间要求。Element Plus 的表单校验我写了 rules 对象，重点约束两点：课题名称 5 到 30 个字符，不能包含违规字符；最大选人数必须在 1 到 20 之间。

封装的思路是：把所有和课题相关的请求单独放进 api/topic.ts，所有表单子组件统一从 Pinia store 获取用户信息，不要在页面里到处散布 localStorage.getItem。代码可维护性在多人协作时会被无限放大，早养成良好习惯省得后期返工。

6.4 待办事项角标的实时刷新

教师端和学生端都有待办提醒。学生端有待审核的进度节点，教师端有待审核的选题申请、待提交的选题结果。这个数字如果总是手动刷新才变化，用户会觉得系统不智能。

我的方案非常简单：用 setInterval 每 60 秒请求一次统计接口，获取各状态数量。虽然实时性一般，但对这个量级的系统完全够用，也不需要引入 WebSocket。注意组件销毁时要把定时器清理干净，避免路由切换后还在后台轮询造成内存泄漏。

typescript复制let timer: any
onMounted(() => {
  timer = setInterval(loadStatistics, 60000)
})
onUnmounted(() => {
  clearInterval(timer)
})

7. 部署上线与问题排查记录

7.1 前后端分离部署

部署环境我选了一台 2 核 4G 的轻量云服务器，系统是 Ubuntu 22.04。后端打 jar 包直接运行，用 systemd 管理进程；前端 npm run build 生成 dist 目录，由 Nginx 托管。

Nginx 配置主要有两个关键点：一是 root 指向前端 dist 目录，二是将 /api 路径代理到后端 8080 端口。

nginx复制server {
    listen 80;
    server_name your-domain.com;

    root /www/graduation-font/dist;
    index index.html;

    location /api/ {
        proxy_pass http://127.0.0.1:8080/api/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    location / {
        try_files $uri $uri/ /index.html;
    }
}

try_files 这一行很关键，它保证前端路由在 history 模式下刷新页面时能回退到 index.html，而不是 404。如果忘了这个配置，每次用户停留在某个深层路由时刷新都会报错。

7.2 跨域与代理问题

开发环境我用 Vite 的 proxy 解决跨域，生产环境用 Nginx 反向代理，这样实际上全程都没有真正跨域。如果你坚持在后端配 CORS，记得要把具体域名白名单配置好，不要直接用 * 允许所有来源，否则 Cookie 和认证信息很容易出问题。

我遇到过比较隐蔽的坑是 Vite 代理配置里 rewrite 写错，导致请求路径变成了 /api/api/selection/apply，后端直接报 404。排查这个问题花了大半天，最后发现是代理路径重复拼接。定位方法也很简单：打开浏览器开发者工具的 Network，看实际请求的 URL 路径，一眼就能看出来。

7.3 上线后遇到的一批真实问题

这套系统在模拟环境和真实使用中暴露出不少问题，我把典型问题整理在一个速查表里，供参考：

7.4 上线前的自查清单

每次改动后发布，我基本都会过一遍这个清单：

1. 后端配置文件里的 MySQL、Redis 密码不要用默认值。
2. 生产环境关闭 Swagger 文档，避免接口信息泄露。
3. 数据库导出并验证备份恢复流程，确保灾备可行。
4. 用模拟账号完整走一遍“学生注册-教师申报-管理员审核-选题申请-通过-进度提交”全流程。
5. Nginx 的 proxy_read_timeout 不要设得太短，后端答辩文件上传接口可能耗时较长。
6. 设置定时任务，凌晨三点自动备份数据库，保留最近七天的备份文件。

8. 个人经验总结

做完这个系统之后，我最大的体会是：论文选题管理系统的核心难点从来不在代码本身，而在业务流程的梳理。技术层面用 SpringBoot 加 Vue 实现 CRUD 并不难，难的是你要想清楚每个状态什么时候变、谁能变、变了之后给谁看通知。

如果你也在开发类似的系统，我建议先把业务流程图画透再动手写代码。尤其是选题状态机，把每一种状态转移的前置条件和后置动作都列清楚，代码就只是翻译而已。先改数据库结构再改代码的成本，远远大于先想清楚再动手的成本。

最后分享一个小技巧：选题记录表里除了状态，我额外加了 apply_reason 和 approve_comment 两个看似多余的字段。后来发生几次选题争议时，这两个字段成了还原现场的关键证据。做管理系统就是这样，多留一条数据，就多一份说不清时的底气。