每年三月中旬教务处的电话就响个不停——老师问为什么自己挂上去的题目一直没人选学生问为什么心仪的题目一点进去就提示已被选走辅导员抱着一摞Excel表格挨个核对谁还没选题。你如果开发过类似的校园信息系统应该对这种选题季大混乱不陌生。我就是在这种背景下用Spring Boot Vue从零搭了一套毕业论文选题管理系统从需求梳理、数据库设计到前后端联调、最后部署上线前后迭代了三个版本把整个选题流程从线下Excel接力变成了线上自主操作。这篇文章不写空话直接把我踩过的坑、设计取舍、核心代码思路、部署经验全部摊开讲给正在做毕设、或者在学校信息中心需要类似系统的你一份完整参考。这套系统能做什么我用一句话概括把老师出题、学生选题、双向确认、教务审核这套完整流程搬上Web让每个人在自己的角色页面里完成权限范围内的事——学生登录后能看到全部可选课题按专业、方向、剩余名额筛选教师能发布课题、查看被选情况、审核学生申请管理员能统筹全校选题进度、手动调整异常数据、导出统计报表。适合哪些人看正在做毕业设计的学生尤其是计算机方向的选题学校信息中心或教务处的开发人员以及想了解Spring Boot Vue完整项目从零落地流程的初学者。1. 选题管理的真实痛点为什么这个系统非做不可1.1 传统选题流程的四个失控时刻不谈理论先说几个我在调研阶段亲耳听到的抱怨。第一个失控发生在题目收集阶段——老师把题目发到邮箱或者微信群格式五花八门有的发Word有的直接写在聊天框里还有的题目里面带着emoji和特殊符号。教务干事对着屏幕一条条抄到Excel里一抄就是两三天抄错了标题都没人知道。第二个失控发生在学生选题阶段。系统不存在的时候学生选题就是看谁手快一个题目被四五个人同时报名老师得挨个解释名额已满更麻烦的是学生之间互相不知道对方选了哪个最后撞题了只能线下协调。热门题目秒没冷门题目没人碰两极分化严重。第三个失控在审核确认阶段。纸质申请表要学生打印、老师签字、院系盖章、教务留档一张表转一圈起码一周。赶上老师出差整个流程就卡住了。有个辅导员跟我说过他有年收了两百多张表光分类整理就花了整整一个周末。第四个失控在数据统计阶段。选题结束后要统计每个老师的指导数量、每个专业的选题分布、热门方向排名全部靠人工数。这种工作看起来简单但几百条数据分分钟让人眼花数错一两行又得从头再来。这四个失控点就是系统最核心的需求来源。1.2 系统的核心诉求与功能边界有了上面的痛点功能边界其实就很清晰了。我给这套系统定的核心功能清单是这样的用户管理学生、教师、管理员三类账号支持院系、专业、年级等基础信息维护。课题管理教师发布课题、修改课题、查看选题情况管理员可代录或批量导入。选题管理学生浏览课题、提交选题申请、撤销申请教师审核通过或拒绝。流程控制选题窗口期设定、每人选题数量限制、同一课题选题人数上限。数据统计按院系、专业、教师、课题方向等多个维度统计选题进度。消息通知选题申请提交、审核结果通过站内消息或邮件告知相关人员。功能边界同样重要——我刻意没有做的东西包括论文在线提交与查重、答辩分组编排、成绩录入。原因很简单那套东西是另一个系统的范畴硬塞进来会让项目复杂度翻倍而且在这个阶段用户根本用不上。做系统最忌讳的是什么都要锁定边界才能快速交付。1.3 技术选型为什么是Spring Boot Vue这套系统用Spring Boot Vue技术选型上可以说是稳字当头一点都不冒险。Spring Boot生态成熟社区资料多遇到问题搜一下基本都有答案内嵌Tomcat打成Jar包就能跑部署门槛极低。Vue作为前端框架上手曲线平缓配合Element Plus组件库表格、表单、弹窗这类管理系统的常见界面半天就能搭出雏形。而且对这个项目来说选这套组合还有一个很实际的原因——它是目前校园信息化项目里最通用的语言。系统做完不是一次性的后续要交给其他同事维护他们最熟悉的往往就是Spring Boot和Vue。技术选型这件事不能光看技术本身好不好还要看团队熟不熟、招不招得到人、出问题了谁能接。2. 系统整体设计权限模型、数据表与选题状态机2.1 三类角色的权限边界系统的权限设计属于典型的RBAC基于角色的访问控制模型。我建了user用户、role角色、permission权限三张核心表用户通过角色关联权限没有给用户单独挂权限这样后续如果要加教务干事教研室主任之类的新角色不需要动表结构只要在角色表里插一条记录再绑定权限就行。三类角色的权限矩阵如下功能模块学生教师管理员浏览课题可查看可筛选可查看全部可查看全部发布课题无权限可发布/修改/下架可代录/导入提交选题申请可提交/撤销无权限无权限可后台干预审核选题申请无权限可审核可审核/驳回/强制分配用户管理无权限无权限可增删改查数据统计仅看自己的选题状态看自己的课题数据全校范围报表前端根据角色渲染不同的菜单后端在每个接口上做角色校验。这里有一条我后来才深刻体会到的原则前端的菜单隐藏只是体验优化不能当安全手段。必须后端接口层层校验否则随便拿个接口地址就能越权操作这在管理系统里是致命的。我的做法是在Controller里用PreAuthorize(hasRole(ADMIN))这种注解做声明式校验同时在一些敏感操作比如管理员强制分配课题里再做一次二次校验。2.2 数据库表结构设计数据库我用的MySQL 8.0字符集统一utf8mb4这样才能稳定存下中文和生僻字。核心表一共五张外加几张关联表。先看最核心的几张表的设计思路。用户表 user字段名类型说明idbigint主键usernamevarchar(50)登录账号学号/工号passwordvarchar(100)BCrypt加密后的密码real_namevarchar(50)真实姓名role_idint角色IDcollege_idint所属院系major_idint专业学生必填gradevarchar(10)年级学生必填学生和教师统一放在一张表里用角色ID区分不要拆成两张表。拆表的教训我在别的项目里吃过亏——后来要加一个校外导师角色拆表方案得改一堆代码加角色则只需要加一行数据。课题表 topic字段名类型说明idbigint主键titlevarchar(200)课题名称descriptiontext课题描述与要求directionvarchar(50)研究方向teacher_idbigint发布教师IDmax_studentsint最大可选人数selected_countint当前已选人数statusint状态0草稿 1发布 2下架 3已满员create_timedatetime创建时间选题记录表 selection_record字段名类型说明idbigint主键student_idbigint学生IDtopic_idbigint课题IDstatusint状态0待审核 1通过 2拒绝 3已撤销create_timedatetime申请时间update_timedatetime最后更新时间选题记录表是整个系统里数据变动最频繁、并发压力最大的表也是后面讲并发控制时的主角。关键约束是唯一索引UNIQUE KEY uk_student_topic (student_id, topic_id)保证同一个学生针对同一个课题只能有一条申请记录再配合业务层面一个学生同一时间只能有一条待审核或已通过的选题的校验防止一人占多个坑。2.3 选题流程的状态流转状态机设计是这个系统的灵魂。一开始我没画状态图直接用if-else硬写结果加了几个新状态之后代码就乱成一团。后来规规矩矩把所有状态和允许的转换列出来一切才清爽起来。课题侧的状态比较简单草稿0→ 发布1→ 已满员3→ 下架2已满员之后如有学生撤销选题自动回退为发布状态。这个回退逻辑很关键——不是满员就永久锁定而是要能动态恢复否则一个学生撤销了课题就永远选不了管理员只能手动改数据库体验极差。选题记录侧的状态流转是核心这里有几条铁律般的约束待审核0只能由学生提交选题申请产生且前提是该课题状态为发布且未满员。待审核状态下学生可以主动撤销变成已撤销3。教师审核通过变成已通过1同时课题的selected_count加1如果达到上限则课题状态变为已满员。教师审核拒绝变成已拒绝2。已通过状态下学生不能自行撤销必须联系管理员或教师操作防止反复横跳把课题名额搞得一团糟。这套状态机的完整转换规则我用一张表固定在设计文档里后端实现的时候所有状态变更都走同一个入口方法不允许在Service里散落着多处直接改status字段。这样后面排查问题的时候只要看入口方法的日志就能还原整个操作链路。3. 后端Spring Boot核心实现从实体类到接口的落地细节3.1 项目结构与分层设计后端项目我采用的Maven标准多模块结构但实际写的时候发现单模块其实也够用反而是包结构更重要。我的包划分是这样的com.example.topic ├── controller # 控制层只做参数接收和结果封装 ├── service # 业务层核心逻辑都在这一层 ├── mapper # MyBatis-Plus数据访问层 ├── entity # 数据库实体类 ├── dto # 前端交互的数据传输对象 ├── vo # 返回给前端的视图对象 ├── config # 配置类安全、跨域、拦截器等 ├── common # 通用类统一返回结果、异常处理、常量等分层遵循的原则是Controller不写业务逻辑Service不写SQL拼接。具体到代码里Controller方法体内一般只有三行——接收参数、调用service、返回统一结果。这样做的好处是当接口出现问题时定位非常快责任边界清楚。MyBatis-Plus我用了简单的增删改查完全不用手写SQL复杂统计就自定义Mapper方法两者结合效率很高。3.2 选题核心接口的实现选题操作是系统最核心的接口我把它拆成三个方法submitApply学生提交申请、withdrawApply学生撤销申请、reviewApply教师审核申请。其中submitApply的完整逻辑是校验学生身份和选题窗口是否开放。校验该学生是否已有待审核或已通过状态的记录有则拒绝。校验课题是否存在且状态为发布。执行条件更新UPDATE topic SET selected_count selected_count 1, status IF(selected_count 1 max_students, 3, 1) WHERE id ? AND status 1 AND selected_count max_students这里利用数据库行锁和条件更新来防止超选。如果第4步影响行数为0说明课题状态已经变化被抢完或下架告知用户重新选择。插入选题记录状态为待审核。给教师发送站内消息通知。这里第4步是整个并发控制的核心下面单独展开讲。3.3 并发抢题与数据一致性做过带并发选择的系统的人都知道学生抢题本质上和电商秒杀是同一类问题——多个用户同时操作同一个资源处理不当就会出现超卖。我第一版实现是纯Java判断先查课题再看剩余名额满足条件就更新。上线第一天就被打脸了两个学生同时点提交都通过了剩余名额检查最后课题被选了三个名额只有两个。后来我采用了两层保险。第一层是上面提到的条件更新SQL把检查和更新合并成一个原子操作数据库的行锁保证同一时刻只有一个事务能成功更新这一行。第二层是唯一索引兜底(student_id, topic_id)的唯一索引保证同一个学生不会对同一课题产生多条记录(student_id)在业务上要求同一时间只能有一个有效选题这部分我用代码加锁实现。这里有个细节必须注意加唯一索引的字段插入重复数据时MySQL会报DuplicateKeyException必须捕获这个异常并转成友好的业务提示你已经选过这个课题了而不能让500错误直接抛给前端。我见过不少系统在并发场景下崩得一塌糊涂其实就是没处理好这类约束异常。3.4 权限校验与安全设计安全这块我用的是JWT Spring Security的组合。用户登录成功后后端生成一个有效期为24小时的Token返回给前端前端每次请求都在请求头里带上Authorization: Bearer token后端通过过滤器解析、校验、把用户信息放进SecurityContext里。密码存储必须用BCrypt加密这个没有商量余地。明文存密码的系统在校园网里被拖库的案例太多了哪怕系统只是内网使用也不能在安全上偷懒。登录接口要做登录失败次数限制——连续错误5次后锁定账号15分钟有效防止暴力破解。另一个安全要点是接口级别的越权防护。以选题记录查询为例学生只能查自己的WHERE student_id #{currentUserId}。如果你在SQL里写死了前端传过来的学生ID那学生把ID改成别人的就能看到别人的选题记录这就是典型的越权漏洞。我的做法是当前登录用户ID一律从SecurityContext取前端传来的ID只用于管理员等有管理权限的场景并且再做一轮角色校验。4. 前端Vue页面设计与交互从登录到选题操作台的完整链路4.1 工程初始化与依赖安装前端我用的是Vue 3 Vite Element Plus Pinia这套组合。Vue 3的组合式APIComposition API写起来比选项式API清爽得多配合Vite的冷启动速度开发体验比Webpack时代提升了一个档次。初始化步骤网上很多我简单说几个关键点# 创建项目 npm create vitelatest topic-frontend -- --template vue # 安装依赖 npm install element-plus axios vue-router pinia # 按需引入Element Plus配合unplugin-auto-import npm install -D unplugin-auto-import unplugin-vue-componentsVite配置文件里加上Element Plus的自动按需导入插件构建速度更快打包体积也小不少。这里有个容易踩的坑create vite创建项目时Node版本要求比较高如果你本机Node还是14.x很可能会提示版本不支持。我的建议是直接用Node 18避免一堆莫名其妙的兼容问题。4.2 路由守卫与角色菜单前端路由我是用动态路由实现的登录后根据角色动态注册对应的路由表。整体设计分两部分一部分是静态路由包括登录页、404页、首页另一部分是动态路由管理员、教师、学生各有一套页面路由登录后通过router.addRoute()逐个注册。路由守卫的核心代码如下router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (!token to.path ! /login) { next(/login) return } if (token to.path /login) { next(/) return } if (token !hasRoute(to.path)) { // 检查用户角色是否已加载未加载则先拉取用户信息 store.dispatch(fetchUserInfo).then(() { next({ ...to, replace: true }) }).catch(() { localStorage.removeItem(token) next(/login) }) return } next() })这里的hasRoute判断很关键不然刷新页面时动态路由丢失用户一刷新就被踢回登录页这个问题在部署后会被用户骂死。有了这个判断后刷新时如果发现当前路径还没注册就去拉取用户信息、重新注册路由然后再跳转一次这样用户感知不到异常。侧边菜单的渲染是根据后端返回的权限码动态过滤的。比如学生端返回的菜单只有课题浏览、我的选题、个人中心教师端才有课题管理、选题审核。权限码在用户登录后一次性返回前端存到Pinia里菜单和数据操作按钮都根据权限码控制显隐。4.3 选题操作台的关键组件学生端的核心页面是课题浏览我用Element Plus的el-table做课题列表每一行展示课题标题、方向、指导教师、可选人数/总人数、当前状态右侧一个操作按钮。列表顶部放了筛选条件研究方向下拉框、关键词搜索框、状态筛选。选课按钮点击后弹确认框然后走提交申请接口。页面里最有挑战的一点是剩余人数的实时感。因为是前后端分离列表数据是进入页面时一次性加载的这时候如果两个学生同时操作展示的剩余名额就可能过期。我的处理是提交选题成功或失败后立刻调用一次刷新列表接口并且给关键字段加上了轮询更新每30秒刷新一次可用课题。不搞WebSocket因为对这个小系统来说websocket有点杀鸡用牛刀轮询简单可靠。教师端的核心是选题审核页面。教师看到的是自己名下课题的所有申请记录每条记录对应一个学生带学生姓名、学号、专业、申请时间和个人说明。审核操作是两个按钮——通过、拒绝。无论通过还是拒绝都要求教师填写一句审核意见这个强制填写的交互虽然看起来多了一步但能有效防止老师无理由拒绝学生后面如果有纠纷也有据可查。4.4 前后端联调的常见问题联调阶段最容易出问题的不是逻辑而是那些不起眼的约定。我总结一下出现频率最高的三类跨域问题。开发时前端跑在5173端口后端跑在8080端口浏览器默认禁止跨域请求。我在Spring Boot里加了一个全局CORS配置类允许http://localhost:5173访问但生产环境是同一个端口提供服务就不需要这个配置了。实现时我特意把CORS配置做成只在本地环境生效用Profile(dev)注解控制避免上线后带着一个全放开的跨域配置在线上裸奔。时间字段格式。后端返回的时间默认是2025-03-15T10:30:00这种ISO格式前端如果不做处理表格里显示出来就是一串奇怪的大写T连接符。我的解决方案是统一在后端配置Jackson的日期格式spring.jackson.date-formatyyyy-MM-dd HH:mm:ss同时把时区设为GMT8。这个坑非常普遍很多人调半天还以为是数据问题其实就是个格式化问题。长字段换行。课题描述的text类型字段返回给前端后el-table默认一行显示结果表格拉得又长又丑。我在前端对description列做了样式处理show-overflow-tooltip鼠标悬浮显示完整内容列表保持干净简洁。另外所有接口返回结构统一用{ code: 200, data: ..., message: success }包裹前端axios拦截器统一处理code不等于200的情况这样接口报错时用户能看到可读的错误提示而不是网络404的白屏。5. 联调、打包与部署把系统真正跑起来5.1 前端构建与后端集成系统开发完成后一定要做一次完整的前后端集成部署。这里我用的是最经典的做法前端构建后将静态文件放进Spring Boot的src/main/resources/static目录后端打成Jar包后同时提供静态页面和API服务一个端口搞定一切不搞Nginx反向代理不搞跨域部署成本最低。具体操作是# 前端构建 npm run build # 构建产物在 dist 目录 # 将 dist 下的文件全部复制到后端的 src/main/resources/static/ # 重新打包后端 mvn clean package -DskipTests复制的时候有个细节dist目录下的index.html里引用的静态资源路径如果是绝对路径/assets/xxx.js后端直接把它作为根路径访问就正常但如果构建时的base属性没配好可能生成/topic-frontend/assets/xxx.js这种带前缀的路径后端就找不到了。我在vite.config.js里统一设置base: ./让资源路径变成相对的省去一堆配置麻烦。如果后续还有更复杂的部署需求可以把static目录用Nginx来代理性能更高、动静分离也更清晰但那是下一档的事情了。5.2 数据库初始化与一键启动数据库迁移这块我用的是Flyway。在resources/db/migration下放V1__init.sql、V2__add_notice.sql等脚本项目启动时Flyway自动按版本号依次执行保证任何环境上都能一键建表。这个机制对维护多环境开发库、测试库、生产库特别有用——你再也不用担心测试库漏加一个字段导致功能在测试环境跑得好好的、一上生产就报错。application.yml里我按环境拆成三个配置文件application-dev.yml本地开发、application-prod.yml线上部署。差异点主要在数据库连接地址、日志级别、CORS配置、JWT过期时间这几个地方。启动命令很简单java -jar topic-system-1.0.0.jar --spring.profiles.activeprod部署完成后建议第一时间做一遍冒烟测试用三种角色各登录一次走一遍核心操作流程——教师发布课题、学生申请选题、教师审核通过、管理员查看统计。这个冒烟用例我在一个Markdown文档里固定下来每次发版后照着跑一遍十几分钟就能确认系统核心链路没被改坏。5.3 部署到云服务器云服务器部署我用的是宝塔面板Docker的组合。宝塔面板的可视化界面降低了Linux命令行操作门槛适合小团队或单人维护Docker则保证了环境一致性不在服务器上直接装JDK和MySQL。Docker部署的时候我写了两个容器一个跑MySQL 8.0挂载数据卷持久化另一个跑Spring Boot应用镜像基于openjdk:17-jdk-slim。这里有一个Docker部署Spring Boot的坑提醒一下容器内时间默认是UTC时区数据库里的created_at全部比北京时间早8个小时。解决方法是启动容器时加环境变量TZAsia/Shanghai或者启动命令里加-e TZAsia/Shanghai。前端静态资源是直接打进Jar包里面的所以只要后端的8080端口对外放行访问服务器IP就能直接看到系统。如果希望访问路径更美观可以在宝塔里配一个域名反向代理把80端口流量转发到8080开启HTTPS就更稳妥了。6. 踩坑记录与实战经验两年里我趟过的那些坑6.1 Spring Boot版本升级引发的连锁反应写这套系统的第一年我用的还是Spring Boot 2.3后来项目重构时想升级到3.0结果一堆坑。最大的一个是**javax包名变成了jakarta**——所有引入的javax.servlet、javax.validation依赖全部报找不到类。这个变动看似简单但涉及到的文件很多我几乎是全局搜索替换。另外Spring Security的配置方式也有变化很多过时的链式API在新版本里被移除了要改写成新版Lambda DSL的写法。经验教训是不要为了尝鲜盲目升级大版本。如果在配置新项目可以考虑直接用新版本如果是对已有项目的增量改造升级成本往往大于收益。因为Spring Boot相关的开源组件比如一些第三方的封装starter不一定已经适配新版查到一半发现某个依赖不支持整个项目就被卡住了。我们做的是业务系统稳定压倒一切。6.2 Vue项目里诡异的前端问题排查前端有个问题我想单独说说因为排查过程非常折磨人。上线后有个老师反馈说在Edge浏览器里打开系统菜单点击没有反应控制台也不报错但换Chrome就正常。我第一反应是浏览器兼容问题克隆了Edge的调试模式排查花了半天都没头绪。后来仔细看才发现——是用户把Edge浏览器开了IE模式兼容性设置而系统基于Web标准API开发Vue在IE模式下根本没法运行。这提醒我当用户反馈浏览器打开异常时不要先入为主以为是代码问题先问清楚对方用的什么浏览器、什么版本、有没有装什么插件或特殊设置。很多时候是用户侧的怪问题而不是你的Bug。类似的例子还有360浏览器兼容模式下Vue页面白屏都是浏览器内核版本太老的锅。系统里我在登录页底部加了一行兼容提示建议使用Chrome或Edge非兼容模式访问把这类问题挡在门外。6.3 字段校验与数据完整性的细节最后再分享几个细节都是平时开发中容易忽略、但出了问题特别尴尬的。手机号校验别用严格正则。我最初用了一个网上常见的正则^1[3-9]\d{9}$结果有教师填了座机号就被拦截了用户非常恼火。后来我把手机号字段改成宽松校验前端只判断11位数字后端只做非空和非中文判断。校园环境经常有座机、短号、分机号过度校验只会增加用户的使用成本。Excel导入必须给模板。管理员批量录课题时支持Excel导入为此我写了一个模板下载功能并在模板里预置了几行示例数据。前端导入时后端会对每一行做校验课题名不能为空、教师必须存在、名额必须为正整数某一行出错要精准指出第几行、第几列、什么错误而不是整批导入失败否则用户根本不知道怎么改。删除操作要谨慎再谨慎。用户管理界面我提供了删除按钮但教师和管理员角色是不允许删除的只能停用账号。删除学生账号前系统会检查该学生是否已有选题记录如果有则提示该学生存在选题记录请改用停用操作。这种软删除设计在后来的运营中帮了大忙——有次一个学生转学了管理员直接就把他账号停用但选题历史记录完整保留统计报表不受影响。日志别嫌多。系统上线后我加了一圈操作日志功能谁在什么时间发布了课题、谁审核通过了哪位学生的申请全部记录下来。程序好不好用是一回事出了问题能不能追溯是另一回事。有一次两个学生对同一个课题的各执一词最后就是靠操作日志还原了时间线谁先谁后一目了然。这套系统从第一个版本到第三个版本我最大的体会是业务状态设计比代码技巧更重要。如果一开始就把状态机、权限边界、数据一致性方案想清楚后面开发就是体力活如果绕过了这些后面每一个功能都会变成补丁。你说Spring Boot Vue这套技术栈难吗不难网上教程一抓一大把。真正拉开差距的是你对业务流程的理解深度是你在并发、安全、部署这些细节上有没有提前留一手。希望这篇长文能帮你把一个又一个的坑提前填平把精力花在真正有价值的需求实现上。