每到毕业设计和求职作品集准备的季节选课系统总能排进热门选题的前三名。原因不难理解角色边界清楚、业务流程完整、既有后台管理又有前端交互该踩的坑一个不落作为全栈练手项目非常合适。很多同学定的方向就是基于Spring Boot Vue的学生选课系统最后交付的东西通常是源码、数据库脚本和一份说明文档。这个组合看起来不算新鲜但真正想做得能答辩、能写到简历里、甚至能部署上线给真实用户用中间还是有不少门道的。这篇文章不打算做泛泛的功能列表我按自己做这类项目的思路把选课系统从需求拆解、技术选型、数据库设计、并发控制到部署运行的完整链路捋一遍重点说清每个关键设计背后的理由和实操中容易忽略的细节。无论你是拿它做毕业设计还是想通过这个项目熟悉前后端分离开发都可以按这份思路复现。1. 选课系统到底在解决什么问题1.1 业务背景与核心场景选课系统的业务场景几乎每个上过大学的人都经历过。以前没系统的时候选课靠的是纸质表格和人工登记学生去教务办公室排队老师在笔记本上手动备注名额满了就换课然后到处是人情和糊涂账。后来有了局域网版选课系统再后来是Web版本质上解决的痛点是三件事选课过程公开透明、选课结果可回溯、课程资源的管理有据可查。从软件角度看这套系统的核心场景可以拆成三个时间段。选课前管理员要维护课程信息、教师信息、学生信息并且确定本学期开哪些课、每个课堂容量多大、选课时间窗口是什么时候。选课中学生登录系统浏览课程、查看余量、提交选课、退选课程系统要实时反馈选课结果。选课后教师可以查看自己课程下的学生名单管理员可以统计选课数据、处理漏选补退。大部分毕业设计的问题恰恰出在这里只做了中间那一段选课的交互前后两端的管理和统计没有做完整答辩的时候被老师问一句选课之前数据怎么来的退课之后名额怎么释放很容易卡壳。所以做这个项目第一件事不是急着写代码是把业务流程图画清楚。1.2 角色权限与用户故事我比较推荐把角色设计成四类而不是很多教程里用的学生和教师两类角色核心诉求典型操作学生快速找到可选课程完成选课和退课浏览课程、筛选可选课、提交选课、查看已选列表教师知道自己教什么、有哪些学生查看任教课程、维护课程信息、导出学生名单管理员保证选课秩序管理基础数据维护用户、维护课程库、开设教学班、配置选课时间系统保证数据一致性和并发正确性校验课程冲突、控制选课人数、记录操作日志在设计后端接口时四种角色对应的是不同的接口访问范围。比如学生不该有教师管理课程的接口权限管理员不该走学生选课的逻辑。这就引出了技术选型里非常关键的一个点认证与授权。1.3 功能边界与需求优先级很多同学做选课系统容易陷入一个误区就是什么功能都想加结果每个功能都做得很浅。我的经验是先守住一条主线学生能选课教师能确认名单管理员能配课。按这个主线功能清单可以这样排序基础数据维护用户管理、学生信息导入、课程信息维护开课管理管理员创建教学班设置教师、上课时间、容量、选课时间段学生选课课程查询、余量显示、选课提交、退课提交、已选列表教师视图任教课程列表、选课学生名单系统保障登录认证、权限控制、选课时间开关先把这些做到稳定、可用再去考虑什么成绩录入、课表导出、消息通知那都是加分项而不是必选项。如果时间和精力有限优先做一个功能完整、边界清晰的系统比半成品叠加一堆花哨功能要值钱得多。2. 技术选型与项目架构2.1 为什么是Spring Boot Vue基于Spring Boot Vue这个标题已经锁死了技术栈所以很多同学觉得选型这一步没什么好聊的。但其实这个组合能成为毕业设计的主流是有其必然性的。后端选Spring Boot看中的是它开箱即用的生态。内嵌Tomcat、自动配置、Starter机制不需要像传统SSH那样手动装配一大堆XML配置文件。写一个Controller只需要几个注解操作数据库有MyBatis-Plus或者Spring Data JPA安全认证有Spring Security的扩展支持几乎每个功能点都能找到现成的解决方案。对于还没有太多工业级开发经验的学生来说这是最不容易走偏的框架。前端选Vue核心原因是它的上手曲线和学习成本。Vue的响应式数据绑定、组件化开发、单文件组件配合Element Plus这样的组件库页面搭建效率非常高。而且Vue 3的Composition API让代码组织更灵活一个中等规模的前端项目拆成十几个组件完全不是问题。2.2 前后端分离的项目结构既然是前后端分离项目就要分成两个独立的工程。我建议前端叫course-ui后端叫course-service不要混在一个模块里。后端标准分层是Controller - Service - Mapper三层结构加上实体类和DTO对象。Controller只做参数接收和结果返回不在里面写业务逻辑。Service层处理选课事务、校验规则、并发控制。Mapper层通过MyBatis-Plus提供数据库操作能力。权限这块用Spring Security JWT无状态认证前端登录拿到token之后放在请求头里后端通过过滤器统一拦截。前端标准结构是视图组件、路由、状态管理和API请求封装四部分。视图组件按页面维度拆分比如登录页、课程列表页、已选课程页、管理后台页。路由用Vue Router管理页面访问权限通过路由守卫控制。状态管理用Pinia存用户信息和token。API请求统一封装axios实例设置baseURL和请求拦截器在拦截器里自动带上token。2.3 JWT认证与权限控制的细节这里有一个很多教程没讲透的地方JWT的作用是身份认证不是权限控制。权限控制还是要靠后端接口层面做校验。我的做法是后端定义角色枚举在需要权限的接口上加自定义注解或者Spring Security的PreAuthorize(hasRole(ADMIN))。JWT令牌里携带用户ID和角色信息后端解析令牌后拿到当前用户身份再判断接口是否允许访问。这样即使前端路由守卫漏配了某个页面后端接口也能挡住没有权限的请求。JWT本身的配置有几个关键参数token过期时间、签名密钥、token刷新策略。毕业设计一般不需要做太复杂的刷新机制token过期时间设长一点比如24小时或者7天前端在登录时记住账号密码token失效就重新登录。但生产环境这么干是不行的生产环境一般用双token或者单tokenrefresh token机制这个可以写在文档的后续优化里答辩时是个加分点。2.4 依赖清单与版本选型版本选择直接影响后期开发和部署。我用的比较稳妥的一套组合是框架/工具推荐版本说明JDK8 或 11部分学校的服务器环境比较旧JDK 8最保险Spring Boot2.7.x2.x版本资料多踩坑少不用急着上3.xMyBatis-Plus3.5.x单表CRUD基本不用写SQLMySQL5.7 或 8.08.0默认认证插件要注意连接驱动版本Vue3.x配合Element PlusNode.js16 或 18Vite构建工具的版本要求Spring Boot 3.x要求JDK 17如果开发机用的就是JDK 17直接上3.x也可以。但如果要部署到学校机房的老机器或者参考的资料大多是基于2.x写的我建议还是一步到位用2.7.x省得遇到版本兼容问题的时候查资料查到怀疑人生。3. 数据库设计选课系统的地基3.1 核心数据表划分选课系统的数据库设计是决定后续开发顺畅与否的关键。我见过不少项目把选课记录直接塞到课程表里用逗号分隔学生ID这种设计写起来一时爽后面查数据、统计、退课的时候全是坑。正常做法是把数据拆成下面几张核心表用户表sys_user存储登录账号、密码、姓名、角色类型学生信息表student_info学号、专业、年级、班级教师信息表teacher_info工号、职称、所在院系课程库表course课程编号、课程名称、学分、课程性质教学班表teaching_class一个课程在一个学期的一次开课、授课教师、上课时间、上课地点、容量选课记录表enrollment学生选课结果记录关联教学班和学生用户表和角色信息表可以合并也可以拆开。学生信息表里的学号、姓名这些数据平时展示不一定要每次查账号表如果需求里有按专业统计选课人数拆开更灵活。3.2 核心字段与关键设计下面这张表是我在多个类似项目里反复调整后定的核心字段直接照着改就能用。表关键字段设计说明sys_userid, username, password, roleusername唯一密码使用BCrypt加密student_infoid, user_id, student_no, majorstudent_no唯一关联user_idteacher_infoid, user_id, teacher_no同样关联user_idcourseid, course_name, credit, course_type课程基本信息不涉及学期teaching_classid, course_id, teacher_id, capacity, selected_count, semester, scheduleselected_count表示当前已选人数enrollmentid, student_id, class_id, create_timestudent_id class_id做唯一联合索引特别说一下teaching_class表和enrollment表的设计。一个课程一个学期可能开好几个教学班每个班容量不同、上课时间不同所以教学班表必须单独建。选课记录表只存课堂ID和选课学生ID通过联合唯一索引保证一个学生在一个教学班里不会重复选课。selected_count字段可以在页面直接显示余量但其实不应该完全依赖它做容量校验并发情况下这个数字是不准确的后面细说。3.3 约束与索引的设计时机数据库约束和索引最好在创建表的阶段就一起想好不要等代码写完再回头补。常见的必加约束有三类一是唯一约束比如用户名唯一、学号唯一、学生和教学班组合唯一二是非空约束比如课程名称、学生姓名、选课时间三是外键约束虽然实际开发中外键不一定建议加但毕业设评论文里写清楚外键关系是加分点代码里可以用逻辑外键替代物理外键。索引的设计要看查询场景。比如学生查看已选课程查询条件是student_id那么enrollment表上要建以student_id为核心的索引。教师查看任教课程查询条件是teacher_id和semester那teaching_class表上建议建(teacher_id, semester)的联合索引。这些细节在答辩时拿出来讲比你背十条框架特性更有说服力。3.4 初始化数据的准备数据库设计完成之后还有一个很多人会忽略的工作准备一份完整的初始化SQL脚本。脚本里除了建库建表语句还要插入测试数据。测试数据要有层次比如至少5个教师、30个学生、10门课程、20个教学班覆盖正常选课、课程冲突、容量已满这些不同场景。我在交付项目的时候习惯再准备一份init_data.sql插入了足够多的测试数据这样别人拿到项目一启动就能直接点选课体验感完全不同。4. 选课核心逻辑与并发处理4.1 一次选课请求的完整校验链选课是系统里最核心的业务逻辑不能用简单的插入一条记录来对待。一次正常的选课请求后端至少要经过下面几条校验当前时间是否在选课时间段内教学班是否存在并且状态正常教学班当前已选人数是否小于容量学生是否已经选过这门课的教学班学生所选课程之间的上课时间是否冲突学生本学期选课总学分是否超限。这些校验如果全写在控制器里代码会很难看。我的建议是把校验逻辑放在Service层每一类校验写成一个私有方法按顺序逐一执行任何一个不通过就直接抛出业务异常由全局异常处理器统一封装返回给前端。4.2 三类典型冲突的处理选课系统里最常见的业务冲突是这三类课程时间冲突、课程重复、容量不足。应付答辩把这三类冲突的解决方案讲清楚基本就稳了。时间冲突的判断逻辑是先查询这个学生所有已选教学班的上课时间再和当前要选的教学班时间做交集判断。数据结构上教学班表要存一个可解析的时间字段。比较通用的做法是用weekday加class_time组合比如周一第3-4节或者用一个时间段字符串。判断冲突时先把已选课程的上课时间段解析出来和目标时间段比较是否有重叠。重复选课的判断前面说到了联合唯一索引可以兜底。但业务层面仍然要主动查询一次给出友好的提示信息不能等数据库抛异常了再返回一个模糊的报错。容量不足的判断是最需要小心的地方。selected_count是页面展示用的不能当作并发下的准确判断依据。真实处理逻辑要放到事务里通过带条件的更新去判断。比如执行UPDATE teaching_class SET selected_count selected_count 1 WHERE id ? AND selected_count capacity如果更新影响的行数为0说明容量满了事务回滚。这个思路比先查再更新要安全得多。4.3 并发选课下的数据一致性选课系统的并发量在真实场景里可能非常高尤其是开放选课的前几分钟几百上千个学生同时点提交。如果代码写成先查询剩余容量再判断是否足够最后插入记录在高并发下一定出问题。前一个事务还没提交后一个事务查询到的还是旧数据最后实际选课人数会超过容量。解决并发问题有三层手段层层加固第一层事务边界。选课和更新selected_count必须在同一个数据库事务里要么一起成功要么一起回滚。第二层条件更新。在事务里执行前面说的带容量判断的UPDATE语句数据库的行锁会保证同一时刻只有一个事务能成功更新同一行数据更新不成功就回滚事务可以防止超选。第三层唯一索引兜底。enrollment表的联合唯一索引即使前两层因为某些原因漏了数据库也会拒绝重复选课的插入。这三层做完并发安全基本不用担心。如果有精力还可以在代码里加乐观锁版本号但选课场景几个条件更新已经能覆盖大部分情况不一定要用复杂机制给自己增加负担。4.4 退课逻辑与名额释放退课看起来简单删除一条选课记录就行但里面有细节。退课业务要做的操作顺序是先删除enrollment记录再执行UPDATE teaching_class SET selected_count selected_count - 1 WHERE id ?。如果先减名额再删除记录删记录失败就会导致名额少了但课没退成。虽然正常代码里这两个操作在同一个事务里顺序不对的话日志排查时容易被误导。另外退课要校验权限和时间。只有选课记录本人能退而且要在退课截止时间之前退。这个业务约束虽然简单但很多项目里经常被忽略。5. 项目跑通与二次开发实操5.1 本地开发环境准备准备好开发环境是第一步我第一次带别人跑项目的时候发现大部分问题不是代码逻辑而是环境不一致。后端需要JDK 8或11、Maven 3.6以上、MySQL 5.7或8.0。环境变量配置好之后在命令行输入java -version和mvn -v确认版本没问题。前端需要Node.js 16以上npm随Node自动安装。数据库准备需要创建一个库比如course_system然后依次执行建表SQL和初始化数据SQL。这里有个很容易踩的坑MySQL 8.0默认的认证插件是caching_sha2_password而旧版本的数据库驱动可能不认识这个插件导致连接时报错。解决方式是把连接驱动升级到mysql-connector-java8.0.x以上或者创建用户时指定mysql_native_password。5.2 后端工程的快速初始化后端直接用Spring Initializr创建工程依赖选择web、mysql、mybatis-plus、lombok、validation、security。如果网络不方便也可以直接建一个Maven工程在pom.xml里手动加上这些依赖。application.yml配置文件里几个关键项的示例server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/course_system?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl map-underscore-to-camel-case: true jwt: secret: something-random-and-secret expire-time: 604800000serverTimezoneAsia/Shanghai这个参数一定要加不然插入时间的时候会报错或者在数据库里显示的时间相差8小时。map-underscore-to-camel-case开启之后数据库的下划线字段能自动映射到Java的驼峰字段写代码时不用每个字段都加映射注解。实体类加TableName注解指定对应表名加TableId(type IdType.AUTO)配置主键策略。选课接口的核心代码大致是下面这样的逻辑Transactional public void selectCourse(Long studentId, Long classId) { // 1. 校验选课时间 checkSelectTime(classId); // 2. 校验课程是否重复 checkDuplicate(studentId, classId); // 3. 校验时间冲突 checkTimeConflict(studentId, classId); // 4. 容量条件更新 boolean success updateSelectedCountWithLock(classId); if (!success) { throw new BizException(课程容量已满); } // 5. 插入选课记录 enrollmentMapper.insert(...); }注意第4步和第5步之间的顺序。先条件更新容量如果成功再插入记录。如果第5步失败整个事务回滚容量更新也会恢复数据仍然保持一致。5.3 前端工程搭建前端使用Vite构建。在命令行执行npm create vitelatest course-ui -- --template vue进入目录后安装依赖然后依次安装vue-router、pinia、axios、element-plus。前端项目的核心配置是axios实例的封装。要注意几点baseURL要和后端接口前缀一致比如后端接口都在/api下前端就设置baseURL: /api然后在开发环境的vite配置里设置代理转发到localhost:8080。这样开发时不会有跨域问题打包部署到生产环境时只需要在Nginx里配置同样路径的转发规则。选课页面的核心交互是查看课程列表、点击选课按钮、提示成功或失败。列表数据里要展示课程名、教师、上课时间、容量、余量余量小于1时按钮置灰。前端按钮的防重复提交要注意点击选课之后立即把按钮设为loading状态等接口返回再恢复不然用户连续点几次就会发好几个请求。5.4 联调与自测前后端分别启动之后用浏览器访问前端地址登录、浏览课程、选课、退课走通一遍完整流程。自测的时候我建议准备一张checklist把每个接口的正常、异常、边界情况都列出来学生登录后能否看到已选课程列表选课时间未开始时选课按钮是否可点重复选同一门课是否有提示选课人数已满是否有提示退课后余量是否增加教师登录后能否看到所选学生名单管理员能否创建教学班并设置容量把这些都过一遍项目质量会有一个肉眼可见的提升。6. 常见问题与排查技巧实录6.1 数据库连接失败与时区报错启动后端时最常见的就是连接不上数据库报错里通常会提示Communications link failure或者Public Key Retrieval is not allowed。前者多半是数据库服务没启动、端口不对或者账号密码错误。后者是MySQL 8.0的认证机制问题在连接URL上加上allowPublicKeyRetrievaltrue即可。时区报错长这样The server time zone value Öйú±ê׼ʱ¼ä is unrecognized。这个中文乱码看着唬人其实就是时区问题把连接URL里的serverTimezone设置为Asia/Shanghai重新启动就好。6.2 前后端联调跨域问题前端访问后端接口浏览器控制台报Access-Control-Allow-Origin错误就是典型的跨域问题。开发环境最省事的办法不是在Spring Boot里写跨域配置而是用Vite的代理功能。前端请求发到同源的/api路径Vite开发服务器把它代理到后端地址浏览器看到的就是同源请求不存在跨域。如果前后端不在同一台机器部署或者不走代理就在后端写一个跨域配置类允许指定来源访问。注意不要直接配成*毕业设评论文里被问为什么允许所有来源的时候很难解释清楚。6.3 端口被占用Spring Boot默认端口是8080如果本机有其他程序占用了8080启动会报Port already in use。排查方法用netstat -ano | findstr 8080查看占用进程然后杀掉进程或者改配置端口。前端Vite默认端口是5173被占用时Vite会自动跳一个端口这种情况一般不用管但要注意baseURL代理配置要跟着变。6.4 选课人数超限和重复数据这是并发问题最典型的两个现象选课人数超出容量、同一个人同一门课出现多个选课记录。排查顺序是先看数据库有没有唯一索引再看代码逻辑里容量判断是不是用条件更新实现的最后看事务注解有没有漏加。大多数情况下问题是数据库表缺少联合唯一索引导致并发插入时完全没有拦截。6.5 登录之后接口返回401前端登录成功能拿到token但请求接口时反复返回401多数是token没有发送到后端。看前端network请求的Headers里有没有Authorization字段。axios请求拦截器里要在每次请求头里带上值。另一个常见问题是token过期时间设置太短调试的时候可以先设长一点比如7天等部署上线前再调整。6.6 部署环境打包配置项目交付通常用文档形式但有些场景需要真正部署到服务器上。后端打包用Maven执行mvn clean package -DskipTests生成jar包服务器上直接执行java -jar course-service.jar。注意生产环境的数据源配置密码那些不硬编码在yml里用环境变量覆盖。前端打包用npm run build产物是dist目录。服务器上用Nginx托管这个目录同时加一条/api路径的转发规则。配置大概长这样location /api/ { proxy_pass http://127.0.0.1:8080/api/; }坑点是前后端都想跑通必须保证前端请求的/api前缀能正确转发到后端接口。如果前端请求地址是http://服务器IP:8080/api/...而后端接口前缀正好也对得上那就不需要做代理但更规范的做法还是前端和页面同源通过Nginx转发。7. 写在最后的经验体会做选课系统这类毕业设计最大的收获不是学会了Spring Boot和Vue两个框架而是理解了一个业务系统从需求到落地的完整过程。选课业务本质上是带有竞争性的资源分配容量有限、时间有限、多个用户同时操作这比单纯写CRUD复杂得多。把并发控制、事务一致性、权限管理这些点想清楚哪怕最后没有任何创新功能项目的含金量也是达标的。我给复现这个项目的同学一个建议不要直接照着别人的源码抄一遍就算完事把自己代入到需求方的角色想一想为什么会有选课时间限制、为什么要做容量控制、为什么选课后要有退课机制。把这些为什么想明白了代码怎么写只是顺手的事。如果时间来得及尽量自己把数据库表从零设计一遍再去看参考实现收获会比重复编译十遍源码大得多。