简介这份资源是面向高校计算机相关专业学生与毕业设计写作者的完整论文文档题目为基于SpringBoot的学生网上选课系统设计与实现适合需要参考选题结构、撰写毕业论文或进行同类系统开发的读者使用。压缩包内共1个文件为一份doc格式的毕业论文约1.29MB可直接查阅章节排版与写作范式。论文围绕选课管理的信息化需求展开涵盖绪论与选题动因、开发环境与技术选型、系统分析、系统设计与实现、系统测试、结论与展望等完整章节。技术层面以SpringBoot为核心框架结合Eclipse开发环境与Mysql数据库功能模块包含用户管理、新闻公告、课程管理、选课操作与数据统计并给出用户表、课程表、选课表等数据库表设计思路同时涉及需求收集、业务流程分析和可行性研究等内容可帮助读者理解从需求到落地的论文写作脉络与系统搭建方法。目前已有92人学习适合作为毕业设计选题与论文框架的参考材料。1. 选课系统真正的难点不在增删改查拿到这类资源包的人第一反应通常是数页面登录、课程管理、排课管理、公告管理、成绩管理一套 CRUD 下来功能表就填满了。可真跑到几十个人同时点「选课」的时候问题全冒出来同一门课被选了两次、学分上限形同虚设、选课时间过了还能提交。论文里那张「选课限制表」业务字段只有数量、开始时间、结束时间三个看着最不起眼它却是整套学生网上选课系统的规则中枢。这份资源是一份完整毕业论文正文覆盖了技术选型Eclipse MySQL Tomcat Vue SpringBoot、系统分析、8 张实体表的物理设计和功能测试章节。它适合两类人拿它当毕设底稿的同学需要把论文里的表格文字落成能跑的代码以及想找一个业务规则足够明确的小项目练 SpringBoot 事务边界、MySQL 唯一索引和前后端分离联调的人。下面按「库表 → 后端 → 前端 → 压测排错」推进每一步都给到可直接抄的语句。2. 从论文实体属性图还原一套能跑的 MySQL 库2.1 论文给的是表结构说明不是可执行 DDL论文 4.3.2 把学生表、教师表、课程信息表、排课信息表、选课信息表、选课限制表、学生成绩表、公告信息表加一张字典表列成了表格。列名全是拼音yonghu_name、kecheng_types、jiaoshi_delete这种。这个命名习惯在毕设里很常见好处是和实体名一一对应答辩时讲得清坏处是类型全写成 String / Integer / Date 这种泛化说法落到 MySQL 里必须自己翻译一遍。几个必须翻译对的点表格里的 String 对应varchar长度按业务给姓名 50、课程详情 2000、图片路径 255表格里的 Date 对应datetime而不是date因为排课表里shangke_time要精确到节次*_delete字段论文标注「假删」Integer 类型约定 1 为已删除、0 为正常所有查询都要带上这个条件否则删过的课程还会出现在选课列表里。字典表dic_code / dic_name / code_index / super_id这套结构实质是用一张表承载所有下拉选项kecheng_types、xueqi_types、jieke_types全部指过去。表 2-1 先理清各表职责避免后面写 SQL 时把paike和kecheng的字段记混表名论文中的实体关键业务字段主要写入方yonghu学生yonghu_uuid_number 学号、yonghu_name管理员jiaoshi教师jiaoshi_uuid_number 工号、banji_types 班级管理员kecheng课程信息kecheng_uuid_number 课程编号、xuenfen_number 学分管理员paike排课信息kecheng_id、xingqi_types 周次、jieke_types 第几节管理员xuanke选课信息kecheng_id、yonghu_id、insert_time学生xuankexianzhi选课限制xuankexianzhi_number 数量、kaishi_time、jieshu_time管理员chengji学生成绩chengji_types 成绩类型、xuenfen_number 成绩教师news / dictionary公告 / 字典news_types、dic_code管理员2.2 课程、排课、选课三张主表的建表语句论文里最核心的三张表是课程、排课、选课其余表都是围绕它们做人员归属和权限。下面的 DDL 直接可执行字段名保留论文的拼音命名方便对照论文图表答辩时一一指认。-- 课程信息表学分字段是后续所有上限校验的依据 CREATE TABLE kecheng ( id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 主键, kecheng_uuid_number VARCHAR(32) NOT NULL COMMENT 课程编号业务上唯一, kecheng_name VARCHAR(100) NOT NULL COMMENT 课程名称, kecheng_types INT NOT NULL DEFAULT 0 COMMENT 课程类型对应 dictionary.code_index, xuenfen_number INT NOT NULL DEFAULT 0 COMMENT 学分用于选课上限校验, kecheng_content VARCHAR(2000) DEFAULT NULL COMMENT 课程详情, kecheng_delete INT NOT NULL DEFAULT 0 COMMENT 假删0 正常 1 删除, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, PRIMARY KEY (id), UNIQUE KEY uk_kecheng_uuid (kecheng_uuid_number), KEY idx_kecheng_types (kecheng_types) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT课程信息表; -- 排课信息表一行代表某个学期、某一周、第几节的一次上课安排 CREATE TABLE paike ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, kecheng_id INT UNSIGNED NOT NULL COMMENT 关联 kecheng.id, shangke_time DATETIME NOT NULL COMMENT 上课时间, xiake_time DATETIME NOT NULL COMMENT 结束时间, jieke_types INT NOT NULL COMMENT 第几节对应字典, xueqi_types INT NOT NULL COMMENT 学期, xingqi_types INT NOT NULL COMMENT 周次第几周, paike_address VARCHAR(120) DEFAULT NULL COMMENT 上课地点, jiaoshi_id INT UNSIGNED NOT NULL COMMENT 授课教师关联 jiaoshi.id, paike_delete INT NOT NULL DEFAULT 0 COMMENT 假删标记, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_paike_kecheng (kecheng_id), KEY idx_paike_teacher (jiaoshi_id), -- 同一教师同一时间的排课不能重复防止排课页面重复提交 UNIQUE KEY uk_paike_conflict (jiaoshi_id, xingqi_types, jieke_types, xueqi_types) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT排课信息表; -- 选课信息表学生与课程的多对多关系表 CREATE TABLE xuanke ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, kecheng_id INT UNSIGNED NOT NULL COMMENT 所选课程, yonghu_id INT UNSIGNED NOT NULL COMMENT 选课学生, insert_time DATETIME NOT NULL COMMENT 选课时间用于时间窗内外的判断留痕, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), -- 关键同一个学生对同一门课只能有一条记录 UNIQUE KEY uk_xuanke_ke_yonghu (kecheng_id, yonghu_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT选课信息表;uk_paike_conflict和uk_xuanke_ke_yonghu这两个唯一索引不是可选项。排课那条把教师、周次、节次、学期组合起来约束住管理员在页面上连点两次保存只会失败一次不会产生两条冲突排课选课那条是防重复选课的底线无论前端有没有置灰按钮、后端有没有判重最终都靠它拦住。2.3 选课限制表的查询方式决定校验是否生效选课限制表在论文里只列了xuankexianzhi_number选课数量、kaishi_time、jieshu_time三个业务字段。这套设计的隐含语义是「管理员配置一条当前生效的规则」所以代码里不能假设表里只有一行而要靠时间条件筛出当前那条。学分上限和已选学分的两条统计 SQL 是选课校验的全部分支来源-- 1) 取当前生效的选课限制条件必须同时包含时间窗并按 id 倒序取最新 SELECT id, xuankexianzhi_number, kaishi_time, jieshu_time FROM xuankexianzhi WHERE kaishi_time NOW() AND jieshu_time NOW() ORDER BY id DESC LIMIT 1; -- 2) 统计某学生已选总学分必须 join 课程表并排除已下架课程 SELECT IFNULL(SUM(k.xuenfen_number), 0) AS total_credit FROM xuanke x JOIN kecheng k ON k.id x.kecheng_id AND k.kecheng_delete 0 WHERE x.yonghu_id 123; -- 3) 学生课表选课记录 join 排课再 join 课程拿名称 SELECT k.kecheng_name, p.xingqi_types, p.jieke_types, p.paike_address FROM xuanke x JOIN kecheng k ON k.id x.kecheng_id JOIN paike p ON p.kecheng_id k.id AND p.paike_delete 0 WHERE x.yonghu_id 123 AND k.kecheng_delete 0 ORDER BY p.xingqi_types, p.jieke_types;第 2 条 SQL 里最容易漏的是kecheng_delete 0。漏掉之后管理员把某门课假删了学生已选学分的统计里仍然包含它结果就是明明还有额度却提示超限。第 1 条的ORDER BY id DESC LIMIT 1同样不能省限制表在测试阶段通常会被插进好几条记录没有排序取最新就会随机命中一条历史规则。提示xuenfen_number在课程表里是「学分」在成绩表里论文也用了同名字段表示「成绩」。两张表分开看没问题写多表 join 时一定要带表别名否则字段撞名报Column xuenfen_number in field list is ambiguous。3. SpringBoot 后端选课接口的事务边界与索引兜底3.1 依赖配置为什么能省掉一堆 XML论文 2.4 节专门讲了 SpringBoot 的两点价值配置损耗和依赖管理。这句话翻译到工程上就是两个注解的功劳。SpringBootApplication内部组合了EnableAutoConfiguration启动时按约定加载自动配置类类路径下有 HikariCP 和 MySQL 驱动DataSourceAutoConfiguration就顺手把数据源建好有 MyBatis 的 starterMybatisAutoConfiguration就去扫Mapper。所以对一个选课系统来说application.yml写十来行就能跑起来不用再手写DispatcherServlet、事务管理器和 Mapper 扫描器这三段传统 XML。server: port: 8080 # 内嵌 Tomcat 端口前端 devServer 代理指向这里 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/xuanke?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: root password: root jackson: date-format: yyyy-MM-dd HH:mm:ss # 排课时间直接按可读格式返回前端 mybatis: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true # yonghu_id 自动映射 yonghuIdmap-underscore-to-camel-case这一行能省掉大量resultMap但要注意它只负责下划线转驼峰像kecheng_uuid_number这种带多段下划线的字段实体属性写成kechengUuidNumber才能对上。JDK 版本这里有个常见坑老版本 SpringBoot 要求 JDK 8新版本要求 JDK 17 起步用低版本 JDK 去创建项目会直接在依赖解析阶段失败选版本时先看本机java -version。3.2 选课 Service 的事务边界选课这个方法有四步校验和一次写入任何一步失败都不能留下脏数据所以Transactional是必需的。但要说清楚它能管什么本地事务只能保证「插入选课记录」和「后续统计更新」要么都成、要么都不成它挡不住并发超选——两个线程同时读到已选学分 24各自算出 243 没超 30然后都去插入。真正兜住重复提交的是第 2 章建的唯一索引。Service public class XuanKeServiceImpl implements XuanKeService { Autowired private XuanKeMapper xuanKeMapper; Autowired private KeChengMapper keChengMapper; Autowired private XuanKeXianZhiMapper xianZhiMapper; Override Transactional(rollbackFor Exception.class) public void xuanKe(Integer yonghuId, Integer kechengId) { // 1) 课程必须存在且未被假删 KeCheng kc keChengMapper.selectByIdNotDeleted(kechengId); if (kc null) { throw new BizException(课程不存在或已下架); } // 2) 当前是否处于选课时间窗内取最新一条生效规则 XuanKeXianZhi xz xianZhiMapper.selectCurrent(); if (xz null) { throw new BizException(当前不在选课开放时间内); } // 3) 学分上限已选学分 本门学分不得超过限制数量 int used xuanKeMapper.sumCreditByYonghu(yonghuId); if (used kc.getXuenfenNumber() xz.getXuanKeXianZhiNumber()) { throw new BizException(已超出选课学分上限); } // 4) 写入靠 uk_xuanke_ke_yonghu 兜住并发下的重复提交 try { xuanKeMapper.insert(yonghuId, kechengId, new Date()); } catch (DuplicateKeyException e) { throw new BizException(该课程已选请勿重复提交); } } }第 3 步的读-算-写是典型的检查后执行并发下必然有窗口。如果压测中出现超选常见做法有三种把校验改成条件更新UPDATE xuankexianzhi SET ... WHERE这类带条件的原子操作用SELECT ... FOR UPDATE锁住该学生的统计行或者在入口加一层 Redis 预扣减扣成功再落库。前两种改动小适合毕设环境的单机部署第三种要引入中间件答辩时不加分反而增加解释成本。第 4 步捕获DuplicateKeyException的位置有讲究Transactional默认只对RuntimeException回滚而这个异常本身就是运行时异常捕到之后转成自定义的BizException继续往上抛事务状态标记为回滚不会出现「提示成功但实际没写进去」的情况。如果把它吞掉改成返回 false 而不抛异常事务就会正常提交虽然没插入数据但如果方法里还有其他写操作那些写操作就留下了。3.3 Controller 层与越权防护登录态里的学生 ID 绝不能从请求体取。选课接口如果接受前端传来的yonghuId任何一个学生改一下参数就能替别人选课这是毕设系统里最容易被答辩老师问到的一处。RestController RequestMapping(/api/xuanke) public class XuanKeController { Autowired private XuanKeService xuanKeService; PostMapping(/add) public Result add(RequestBody XuanKeForm form) { // 学生身份从登录态解析不信任请求体里的任何用户标识 Integer yonghuId UserContext.getYonghuId(); xuanKeService.xuanKe(yonghuId, form.getKechengId()); return Result.ok(); } ExceptionHandler(BizException.class) public Result handleBiz(BizException e) { // 业务异常统一转成 code500 可读文案前端直接弹 message return Result.fail(e.getMessage()); } }接口方法关键参数失败场景与返回文案/api/xuanke/addPOSTkechengId课程不存在 / 不在选课时间 / 超出学分上限 / 已选过/api/xuanke/deletePOSTid退选时校验是否已出成绩已出成绩不允许退/api/xuanke/myGET无取登录态返回已选列表供课表渲染/api/paike/listGETxueqiTypes、xingqiTypes按周筛选课表假删记录不返回4. Vue 前端选课页的状态管理与前后端联调4.1 vue.config.js 代理与 axios 拦截前后端分离部署时前端跑在 8081SpringBoot 内嵌 Tomcat 跑在 8080浏览器的同源策略会直接拦掉请求。开发阶段用 devServer 代理最省事不用在后端加CrossOrigin也不会把跨域配置带到生产环境。// vue.config.js module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, // 指向 SpringBoot 内嵌 Tomcat changeOrigin: true // 后端 Controller 已声明 /api 前缀这里不做 pathRewrite } } } }axios 的响应拦截器负责把「业务失败」和「网络失败」分开处理。选课接口返回 HTTP 200 但code500时属于业务失败应该弹可读文案链接断开、超时这类才是网络失败。两种都混在一起处理学生看到的就是一堆英文异常。import axios from axios const request axios.create({ baseURL: /api, timeout: 8000 }) request.interceptors.response.use( res { if (res.data.code ! 200) { // 学分超限、重复选课等业务失败直接把 msg 抛给调用处 return Promise.reject(new Error(res.data.msg || 操作失败)) } return res.data }, err Promise.reject(new Error(网络异常请稍后重试)) ) export default request4.2 选课按钮的状态机与重复提交唯一索引能让数据库层不产生重复记录但学生的体验是「点了一下没反应又点了一下然后弹一次成功一次失败」。所以按钮层面必须做本地节流用submitting标志把请求锁住成功后再刷新已选列表。export default { data() { return { submitting: false } }, methods: { async handleXuanKe(row) { if (this.submitting) return // 本地节流挡住连点产生的并发请求 this.submitting true try { await request.post(/xuanke/add, { kechengId: row.id }) this.$message.success(选课成功) await this.loadMyCourses() // 成功后刷新已选列表与剩余学分 } catch (e) { this.$message.error(e.message) } finally { this.submitting false // 无论成败都要解锁 } } } }finally里的解锁不能省否则一次失败之后按钮就永久失效只能刷新页面。这段逻辑和 3.2 节的DuplicateKeyException处理是配套的前端挡住大部分连点漏过去的那部分由唯一索引和异常翻译兜住两层都不做就会在压测时暴露。4.3 课表渲染与假删数据过滤课表按周次和节次排布前端拿到/api/paike/list返回的扁平数组后按xingqiTypes分行、jiekeTypes分列渲染即可。这里有个容易被忽略的点前端渲染课表用的数据来自排课表而排课表里的paike_delete是假删字段后端查询必须过滤掉已删除的行前端不要再做二次过滤——前端过滤一旦和后端规则不一致就会出现「列表里有、点进去没有」的诡异现象。已选学分和上限的展示同理直接调后端统计接口拿值不要在前端用已选列表自己加总。前端的列表可能是分页的、可能漏了某门课的学分字段自己加出来的数字和后端校验用的数字对不上学生看到的提示就会自相矛盾。5. 抢课压测用 ab 复现超选并逐层定位功能测试靠手点发现不了并发问题。论文第 6 章只做了登录功能测试和测试方法说明真正该补的是抢课场景。准备一个 JSON 请求体文件用 ab 打同一个学生账号的选课接口# xuanke.json 内容 {kechengId: 1} # -n 总请求数-c 并发数-p 请求体文件-T 内容类型 ab -n 1000 -c 200 -p xuanke.json -T application/json \ -H Authorization: Bearer 登录后拿到的token \ http://localhost:8080/api/xuanke/add跑完先看Non-2xx responses这一行它应该等于 9991000 次请求里只有 1 次真正插入成功再回数据库执行SELECT COUNT(*) FROM xuanke WHERE kecheng_id 1 AND yonghu_id 123结果必须是 1。如果大于 1说明uk_xuanke_ke_yonghu没建或者建错了字段顺序这是最先要确认的一件事。Failed requests里面还会混着连接超时把-c降到 50 再跑一遍能把「索引失效」和「连接池不够」两种原因区分开。排错顺序按表 5-1 走比逐个类打断点快得多现象先看哪里常见原因提示已选但列表里没有xuanke 表的唯一索引定义之前假删的记录仍在表里唯一索引照样生效时间窗过期还能提交selectCurrent 的 SQL限制表有多条记录漏了 ORDER BY id DESC LIMIT 1学分上限算错sumCreditByYonghu漏 join 课程表或没带 kecheng_delete 0压测中高频出现重复提交提示前端按钮状态 / 后端异常处理按钮没置灰或 DuplicateKeyException 被吞掉没抛压到 200 并发开始大量超时application.yml 的 HikariCP 配置默认连接池 10需要调 maximum-pool-size 并缩短事务假删字段和唯一索引的冲突值得单独说一句。管理员把一条选课记录假删delete 1之后学生重新选同一门课会直接撞唯一索引。两种处理方式唯一索引里带上删除标记组成三元组代价是同一门课可能存在多条历史记录统计学分时要额外聚合或者在假删时把kecheng_id改写成负值做归档。毕设场景下前者改动更小只要把统计 SQL 的 WHERE 条件改对其余查询不受影响。最后留一个验证用的细节把DuplicateKeyException的日志级别调到 DEBUG压测时观察它的抛出次数这个数字减去成功次数就是被唯一索引拦下来的并发请求量。这个差值直接说明索引确实在干活而不是仅仅存在于建表语句里。本文还有配套的精品资源点击获取 SpringBoot选课系统避坑：MySQL唯一索引与事务边界实战
简介这份资源是面向高校计算机相关专业学生与毕业设计写作者的完整论文文档题目为基于SpringBoot的学生网上选课系统设计与实现适合需要参考选题结构、撰写毕业论文或进行同类系统开发的读者使用。压缩包内共1个文件为一份doc格式的毕业论文约1.29MB可直接查阅章节排版与写作范式。论文围绕选课管理的信息化需求展开涵盖绪论与选题动因、开发环境与技术选型、系统分析、系统设计与实现、系统测试、结论与展望等完整章节。技术层面以SpringBoot为核心框架结合Eclipse开发环境与Mysql数据库功能模块包含用户管理、新闻公告、课程管理、选课操作与数据统计并给出用户表、课程表、选课表等数据库表设计思路同时涉及需求收集、业务流程分析和可行性研究等内容可帮助读者理解从需求到落地的论文写作脉络与系统搭建方法。目前已有92人学习适合作为毕业设计选题与论文框架的参考材料。1. 选课系统真正的难点不在增删改查拿到这类资源包的人第一反应通常是数页面登录、课程管理、排课管理、公告管理、成绩管理一套 CRUD 下来功能表就填满了。可真跑到几十个人同时点「选课」的时候问题全冒出来同一门课被选了两次、学分上限形同虚设、选课时间过了还能提交。论文里那张「选课限制表」业务字段只有数量、开始时间、结束时间三个看着最不起眼它却是整套学生网上选课系统的规则中枢。这份资源是一份完整毕业论文正文覆盖了技术选型Eclipse MySQL Tomcat Vue SpringBoot、系统分析、8 张实体表的物理设计和功能测试章节。它适合两类人拿它当毕设底稿的同学需要把论文里的表格文字落成能跑的代码以及想找一个业务规则足够明确的小项目练 SpringBoot 事务边界、MySQL 唯一索引和前后端分离联调的人。下面按「库表 → 后端 → 前端 → 压测排错」推进每一步都给到可直接抄的语句。2. 从论文实体属性图还原一套能跑的 MySQL 库2.1 论文给的是表结构说明不是可执行 DDL论文 4.3.2 把学生表、教师表、课程信息表、排课信息表、选课信息表、选课限制表、学生成绩表、公告信息表加一张字典表列成了表格。列名全是拼音yonghu_name、kecheng_types、jiaoshi_delete这种。这个命名习惯在毕设里很常见好处是和实体名一一对应答辩时讲得清坏处是类型全写成 String / Integer / Date 这种泛化说法落到 MySQL 里必须自己翻译一遍。几个必须翻译对的点表格里的 String 对应varchar长度按业务给姓名 50、课程详情 2000、图片路径 255表格里的 Date 对应datetime而不是date因为排课表里shangke_time要精确到节次*_delete字段论文标注「假删」Integer 类型约定 1 为已删除、0 为正常所有查询都要带上这个条件否则删过的课程还会出现在选课列表里。字典表dic_code / dic_name / code_index / super_id这套结构实质是用一张表承载所有下拉选项kecheng_types、xueqi_types、jieke_types全部指过去。表 2-1 先理清各表职责避免后面写 SQL 时把paike和kecheng的字段记混表名论文中的实体关键业务字段主要写入方yonghu学生yonghu_uuid_number 学号、yonghu_name管理员jiaoshi教师jiaoshi_uuid_number 工号、banji_types 班级管理员kecheng课程信息kecheng_uuid_number 课程编号、xuenfen_number 学分管理员paike排课信息kecheng_id、xingqi_types 周次、jieke_types 第几节管理员xuanke选课信息kecheng_id、yonghu_id、insert_time学生xuankexianzhi选课限制xuankexianzhi_number 数量、kaishi_time、jieshu_time管理员chengji学生成绩chengji_types 成绩类型、xuenfen_number 成绩教师news / dictionary公告 / 字典news_types、dic_code管理员2.2 课程、排课、选课三张主表的建表语句论文里最核心的三张表是课程、排课、选课其余表都是围绕它们做人员归属和权限。下面的 DDL 直接可执行字段名保留论文的拼音命名方便对照论文图表答辩时一一指认。-- 课程信息表学分字段是后续所有上限校验的依据 CREATE TABLE kecheng ( id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 主键, kecheng_uuid_number VARCHAR(32) NOT NULL COMMENT 课程编号业务上唯一, kecheng_name VARCHAR(100) NOT NULL COMMENT 课程名称, kecheng_types INT NOT NULL DEFAULT 0 COMMENT 课程类型对应 dictionary.code_index, xuenfen_number INT NOT NULL DEFAULT 0 COMMENT 学分用于选课上限校验, kecheng_content VARCHAR(2000) DEFAULT NULL COMMENT 课程详情, kecheng_delete INT NOT NULL DEFAULT 0 COMMENT 假删0 正常 1 删除, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, PRIMARY KEY (id), UNIQUE KEY uk_kecheng_uuid (kecheng_uuid_number), KEY idx_kecheng_types (kecheng_types) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT课程信息表; -- 排课信息表一行代表某个学期、某一周、第几节的一次上课安排 CREATE TABLE paike ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, kecheng_id INT UNSIGNED NOT NULL COMMENT 关联 kecheng.id, shangke_time DATETIME NOT NULL COMMENT 上课时间, xiake_time DATETIME NOT NULL COMMENT 结束时间, jieke_types INT NOT NULL COMMENT 第几节对应字典, xueqi_types INT NOT NULL COMMENT 学期, xingqi_types INT NOT NULL COMMENT 周次第几周, paike_address VARCHAR(120) DEFAULT NULL COMMENT 上课地点, jiaoshi_id INT UNSIGNED NOT NULL COMMENT 授课教师关联 jiaoshi.id, paike_delete INT NOT NULL DEFAULT 0 COMMENT 假删标记, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_paike_kecheng (kecheng_id), KEY idx_paike_teacher (jiaoshi_id), -- 同一教师同一时间的排课不能重复防止排课页面重复提交 UNIQUE KEY uk_paike_conflict (jiaoshi_id, xingqi_types, jieke_types, xueqi_types) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT排课信息表; -- 选课信息表学生与课程的多对多关系表 CREATE TABLE xuanke ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, kecheng_id INT UNSIGNED NOT NULL COMMENT 所选课程, yonghu_id INT UNSIGNED NOT NULL COMMENT 选课学生, insert_time DATETIME NOT NULL COMMENT 选课时间用于时间窗内外的判断留痕, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), -- 关键同一个学生对同一门课只能有一条记录 UNIQUE KEY uk_xuanke_ke_yonghu (kecheng_id, yonghu_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT选课信息表;uk_paike_conflict和uk_xuanke_ke_yonghu这两个唯一索引不是可选项。排课那条把教师、周次、节次、学期组合起来约束住管理员在页面上连点两次保存只会失败一次不会产生两条冲突排课选课那条是防重复选课的底线无论前端有没有置灰按钮、后端有没有判重最终都靠它拦住。2.3 选课限制表的查询方式决定校验是否生效选课限制表在论文里只列了xuankexianzhi_number选课数量、kaishi_time、jieshu_time三个业务字段。这套设计的隐含语义是「管理员配置一条当前生效的规则」所以代码里不能假设表里只有一行而要靠时间条件筛出当前那条。学分上限和已选学分的两条统计 SQL 是选课校验的全部分支来源-- 1) 取当前生效的选课限制条件必须同时包含时间窗并按 id 倒序取最新 SELECT id, xuankexianzhi_number, kaishi_time, jieshu_time FROM xuankexianzhi WHERE kaishi_time NOW() AND jieshu_time NOW() ORDER BY id DESC LIMIT 1; -- 2) 统计某学生已选总学分必须 join 课程表并排除已下架课程 SELECT IFNULL(SUM(k.xuenfen_number), 0) AS total_credit FROM xuanke x JOIN kecheng k ON k.id x.kecheng_id AND k.kecheng_delete 0 WHERE x.yonghu_id 123; -- 3) 学生课表选课记录 join 排课再 join 课程拿名称 SELECT k.kecheng_name, p.xingqi_types, p.jieke_types, p.paike_address FROM xuanke x JOIN kecheng k ON k.id x.kecheng_id JOIN paike p ON p.kecheng_id k.id AND p.paike_delete 0 WHERE x.yonghu_id 123 AND k.kecheng_delete 0 ORDER BY p.xingqi_types, p.jieke_types;第 2 条 SQL 里最容易漏的是kecheng_delete 0。漏掉之后管理员把某门课假删了学生已选学分的统计里仍然包含它结果就是明明还有额度却提示超限。第 1 条的ORDER BY id DESC LIMIT 1同样不能省限制表在测试阶段通常会被插进好几条记录没有排序取最新就会随机命中一条历史规则。提示xuenfen_number在课程表里是「学分」在成绩表里论文也用了同名字段表示「成绩」。两张表分开看没问题写多表 join 时一定要带表别名否则字段撞名报Column xuenfen_number in field list is ambiguous。3. SpringBoot 后端选课接口的事务边界与索引兜底3.1 依赖配置为什么能省掉一堆 XML论文 2.4 节专门讲了 SpringBoot 的两点价值配置损耗和依赖管理。这句话翻译到工程上就是两个注解的功劳。SpringBootApplication内部组合了EnableAutoConfiguration启动时按约定加载自动配置类类路径下有 HikariCP 和 MySQL 驱动DataSourceAutoConfiguration就顺手把数据源建好有 MyBatis 的 starterMybatisAutoConfiguration就去扫Mapper。所以对一个选课系统来说application.yml写十来行就能跑起来不用再手写DispatcherServlet、事务管理器和 Mapper 扫描器这三段传统 XML。server: port: 8080 # 内嵌 Tomcat 端口前端 devServer 代理指向这里 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/xuanke?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: root password: root jackson: date-format: yyyy-MM-dd HH:mm:ss # 排课时间直接按可读格式返回前端 mybatis: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true # yonghu_id 自动映射 yonghuIdmap-underscore-to-camel-case这一行能省掉大量resultMap但要注意它只负责下划线转驼峰像kecheng_uuid_number这种带多段下划线的字段实体属性写成kechengUuidNumber才能对上。JDK 版本这里有个常见坑老版本 SpringBoot 要求 JDK 8新版本要求 JDK 17 起步用低版本 JDK 去创建项目会直接在依赖解析阶段失败选版本时先看本机java -version。3.2 选课 Service 的事务边界选课这个方法有四步校验和一次写入任何一步失败都不能留下脏数据所以Transactional是必需的。但要说清楚它能管什么本地事务只能保证「插入选课记录」和「后续统计更新」要么都成、要么都不成它挡不住并发超选——两个线程同时读到已选学分 24各自算出 243 没超 30然后都去插入。真正兜住重复提交的是第 2 章建的唯一索引。Service public class XuanKeServiceImpl implements XuanKeService { Autowired private XuanKeMapper xuanKeMapper; Autowired private KeChengMapper keChengMapper; Autowired private XuanKeXianZhiMapper xianZhiMapper; Override Transactional(rollbackFor Exception.class) public void xuanKe(Integer yonghuId, Integer kechengId) { // 1) 课程必须存在且未被假删 KeCheng kc keChengMapper.selectByIdNotDeleted(kechengId); if (kc null) { throw new BizException(课程不存在或已下架); } // 2) 当前是否处于选课时间窗内取最新一条生效规则 XuanKeXianZhi xz xianZhiMapper.selectCurrent(); if (xz null) { throw new BizException(当前不在选课开放时间内); } // 3) 学分上限已选学分 本门学分不得超过限制数量 int used xuanKeMapper.sumCreditByYonghu(yonghuId); if (used kc.getXuenfenNumber() xz.getXuanKeXianZhiNumber()) { throw new BizException(已超出选课学分上限); } // 4) 写入靠 uk_xuanke_ke_yonghu 兜住并发下的重复提交 try { xuanKeMapper.insert(yonghuId, kechengId, new Date()); } catch (DuplicateKeyException e) { throw new BizException(该课程已选请勿重复提交); } } }第 3 步的读-算-写是典型的检查后执行并发下必然有窗口。如果压测中出现超选常见做法有三种把校验改成条件更新UPDATE xuankexianzhi SET ... WHERE这类带条件的原子操作用SELECT ... FOR UPDATE锁住该学生的统计行或者在入口加一层 Redis 预扣减扣成功再落库。前两种改动小适合毕设环境的单机部署第三种要引入中间件答辩时不加分反而增加解释成本。第 4 步捕获DuplicateKeyException的位置有讲究Transactional默认只对RuntimeException回滚而这个异常本身就是运行时异常捕到之后转成自定义的BizException继续往上抛事务状态标记为回滚不会出现「提示成功但实际没写进去」的情况。如果把它吞掉改成返回 false 而不抛异常事务就会正常提交虽然没插入数据但如果方法里还有其他写操作那些写操作就留下了。3.3 Controller 层与越权防护登录态里的学生 ID 绝不能从请求体取。选课接口如果接受前端传来的yonghuId任何一个学生改一下参数就能替别人选课这是毕设系统里最容易被答辩老师问到的一处。RestController RequestMapping(/api/xuanke) public class XuanKeController { Autowired private XuanKeService xuanKeService; PostMapping(/add) public Result add(RequestBody XuanKeForm form) { // 学生身份从登录态解析不信任请求体里的任何用户标识 Integer yonghuId UserContext.getYonghuId(); xuanKeService.xuanKe(yonghuId, form.getKechengId()); return Result.ok(); } ExceptionHandler(BizException.class) public Result handleBiz(BizException e) { // 业务异常统一转成 code500 可读文案前端直接弹 message return Result.fail(e.getMessage()); } }接口方法关键参数失败场景与返回文案/api/xuanke/addPOSTkechengId课程不存在 / 不在选课时间 / 超出学分上限 / 已选过/api/xuanke/deletePOSTid退选时校验是否已出成绩已出成绩不允许退/api/xuanke/myGET无取登录态返回已选列表供课表渲染/api/paike/listGETxueqiTypes、xingqiTypes按周筛选课表假删记录不返回4. Vue 前端选课页的状态管理与前后端联调4.1 vue.config.js 代理与 axios 拦截前后端分离部署时前端跑在 8081SpringBoot 内嵌 Tomcat 跑在 8080浏览器的同源策略会直接拦掉请求。开发阶段用 devServer 代理最省事不用在后端加CrossOrigin也不会把跨域配置带到生产环境。// vue.config.js module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, // 指向 SpringBoot 内嵌 Tomcat changeOrigin: true // 后端 Controller 已声明 /api 前缀这里不做 pathRewrite } } } }axios 的响应拦截器负责把「业务失败」和「网络失败」分开处理。选课接口返回 HTTP 200 但code500时属于业务失败应该弹可读文案链接断开、超时这类才是网络失败。两种都混在一起处理学生看到的就是一堆英文异常。import axios from axios const request axios.create({ baseURL: /api, timeout: 8000 }) request.interceptors.response.use( res { if (res.data.code ! 200) { // 学分超限、重复选课等业务失败直接把 msg 抛给调用处 return Promise.reject(new Error(res.data.msg || 操作失败)) } return res.data }, err Promise.reject(new Error(网络异常请稍后重试)) ) export default request4.2 选课按钮的状态机与重复提交唯一索引能让数据库层不产生重复记录但学生的体验是「点了一下没反应又点了一下然后弹一次成功一次失败」。所以按钮层面必须做本地节流用submitting标志把请求锁住成功后再刷新已选列表。export default { data() { return { submitting: false } }, methods: { async handleXuanKe(row) { if (this.submitting) return // 本地节流挡住连点产生的并发请求 this.submitting true try { await request.post(/xuanke/add, { kechengId: row.id }) this.$message.success(选课成功) await this.loadMyCourses() // 成功后刷新已选列表与剩余学分 } catch (e) { this.$message.error(e.message) } finally { this.submitting false // 无论成败都要解锁 } } } }finally里的解锁不能省否则一次失败之后按钮就永久失效只能刷新页面。这段逻辑和 3.2 节的DuplicateKeyException处理是配套的前端挡住大部分连点漏过去的那部分由唯一索引和异常翻译兜住两层都不做就会在压测时暴露。4.3 课表渲染与假删数据过滤课表按周次和节次排布前端拿到/api/paike/list返回的扁平数组后按xingqiTypes分行、jiekeTypes分列渲染即可。这里有个容易被忽略的点前端渲染课表用的数据来自排课表而排课表里的paike_delete是假删字段后端查询必须过滤掉已删除的行前端不要再做二次过滤——前端过滤一旦和后端规则不一致就会出现「列表里有、点进去没有」的诡异现象。已选学分和上限的展示同理直接调后端统计接口拿值不要在前端用已选列表自己加总。前端的列表可能是分页的、可能漏了某门课的学分字段自己加出来的数字和后端校验用的数字对不上学生看到的提示就会自相矛盾。5. 抢课压测用 ab 复现超选并逐层定位功能测试靠手点发现不了并发问题。论文第 6 章只做了登录功能测试和测试方法说明真正该补的是抢课场景。准备一个 JSON 请求体文件用 ab 打同一个学生账号的选课接口# xuanke.json 内容 {kechengId: 1} # -n 总请求数-c 并发数-p 请求体文件-T 内容类型 ab -n 1000 -c 200 -p xuanke.json -T application/json \ -H Authorization: Bearer 登录后拿到的token \ http://localhost:8080/api/xuanke/add跑完先看Non-2xx responses这一行它应该等于 9991000 次请求里只有 1 次真正插入成功再回数据库执行SELECT COUNT(*) FROM xuanke WHERE kecheng_id 1 AND yonghu_id 123结果必须是 1。如果大于 1说明uk_xuanke_ke_yonghu没建或者建错了字段顺序这是最先要确认的一件事。Failed requests里面还会混着连接超时把-c降到 50 再跑一遍能把「索引失效」和「连接池不够」两种原因区分开。排错顺序按表 5-1 走比逐个类打断点快得多现象先看哪里常见原因提示已选但列表里没有xuanke 表的唯一索引定义之前假删的记录仍在表里唯一索引照样生效时间窗过期还能提交selectCurrent 的 SQL限制表有多条记录漏了 ORDER BY id DESC LIMIT 1学分上限算错sumCreditByYonghu漏 join 课程表或没带 kecheng_delete 0压测中高频出现重复提交提示前端按钮状态 / 后端异常处理按钮没置灰或 DuplicateKeyException 被吞掉没抛压到 200 并发开始大量超时application.yml 的 HikariCP 配置默认连接池 10需要调 maximum-pool-size 并缩短事务假删字段和唯一索引的冲突值得单独说一句。管理员把一条选课记录假删delete 1之后学生重新选同一门课会直接撞唯一索引。两种处理方式唯一索引里带上删除标记组成三元组代价是同一门课可能存在多条历史记录统计学分时要额外聚合或者在假删时把kecheng_id改写成负值做归档。毕设场景下前者改动更小只要把统计 SQL 的 WHERE 条件改对其余查询不受影响。最后留一个验证用的细节把DuplicateKeyException的日志级别调到 DEBUG压测时观察它的抛出次数这个数字减去成功次数就是被唯一索引拦下来的并发请求量。这个差值直接说明索引确实在干活而不是仅仅存在于建表语句里。本文还有配套的精品资源点击获取