课程设计选题这件事经历过的人都知道有多费劲。每次一到学期中段办公室里全是学生发来的老师XX题目还有名额吗的消息微信群消息滚动堪比秒杀现场Excel表格传来传去改得乱七八糟。我见过不止一个老师用先到先得手工登记结果总有学生说我明明先发的消息你怎么没看到。学生选题全靠抢、教师审核全靠催、管理员统计全靠手动汇总这就是传统流程的真实写照。所以才有了这套基于SpringBoot后端Vue前端MySQL的课程设计选题管理信息管理系统把选题、审核、统计整个过程线上化谁选了哪个题、状态是否通过打开页面一目了然。这篇文章从需求分析、后端设计、前端协作、数据库建模到实际运行踩坑完整复盘这套系统的方方面面适合正在做课程设计、想参考成熟Web项目源码、或者准备自己动手写一个选题系统的同学。1. 先聊聊课程设计选题这件事痛点比你想的深课程设计是高校教学里几乎每学期都有的环节但选题环节长期处于一种原始社会的状态。别小看这个看似简单的管理需求真正做起来才发现里面的规则细节远比想象多。1.1 手工选题的混乱现场我最早接触这个需求是因为看到某位老师用Excel登记学生选题。表格里有课题名称、学生姓名、学号、联系方式几个字段开放给全班同学自己填。听起来没问题实际上操作起来全是坑一个课题被多个学生同时填上到底算谁的老师只能按填表时间先后判断但Excel没有时间戳学生各说各话。更麻烦的是老师改一次表格就要重新发一次文件每个学生手里的版本都不一样最后汇总时数据对不上得从头核对聊天记录。微信群的抢答式选题就更乱了。老师在群里发题目清单学生在下面回复我要3号题。高峰期消息刷得飞快老师翻记录翻到眼花。而且这种模式下信息公开程度完全取决于学生是否在群里、是否刷到了消息晚来的学生根本不知道哪些题目还有名额只能挨个私聊老师碰运气。原本应该是学生根据自己的兴趣和能力选择合适的课题硬生生变成了拼手速、拼网速、拼人脉。还有一类问题是选题之后的变更。学生选完题过两周想换题或者老师发现某个课题方向不适合某位学生需要撤销重选。手工模式下这种变更几乎没有留痕谁改过、什么时候改的、改成什么了全靠记忆出了问题说不清楚。1.2 系统要解决的三个核心问题手动流程混乱的本质其实可以归纳成三件事名额归属不明确、状态信息不透明、操作记录不完整。这套选题管理系统就是围绕这三件事设计的。名额归属问题说白了就是一个课题能被多少人选、被谁选。系统里每个课题都可以设置可选人数上限学生提交选题后进入待审核状态教师审核通过才算真正占用名额。如果审核不通过名额自动释放其他学生可以继续选。这样就避免了谁先抢到算谁的这种规则不透明的情况。状态信息不透明指的是选题做到哪一步了。学生视角需要知道我选的题目老师审核了没有要不要重新选教师视角需要知道我的课题被哪些学生选了哪些还没人选哪些审核通过了管理员视角需要知道全局还有多少学生没选上题、哪些课题没人选、每个老师的指导学生数是多少。这些状态在系统里通过可选、待审核、已通过、已驳回等几个明确状态表达谁看都不会产生歧义。操作记录不完整对应的是系统的日志能力。谁在什么时间选了哪个题、谁在什么时间审核了什么操作都能在后台查到。这个特性平时不起眼但一旦出现学生说我没选过这个题老师说我没审核过这个学生之类的争议记录就是最有力的依据。我在设计的时候特意把关键操作都写入了操作日志表实测下来非常有必要。2. 功能拆解三种角色、两条主流程、一组状态机做管理系统最忌讳一上来就写代码。角色—流程—状态这套骨架不梳理清楚写出来的功能大概率是乱的。这套选题系统在动手前我先把业务规则理了一遍。2.1 管理员、教师、学生的权限边界整个系统只有三种角色权限边界划分得非常清晰。管理员是超级管理者负责基础数据的维护。学生的批量导入、教师的账号创建、课程的学期设置、系统的运行参数都归管理员管。管理员一般不直接参与选题业务但拥有查看所有数据的权限便于统计和排查问题。教师是课题的提供者和审核者。教师登录后可以发布新课题、修改课题描述、设置课题可选人数、查看自己课题的被选情况也可以对学生提交的选题申请进行通过或驳回操作。教师的权限范围限定在自己的课题上看不到其他老师的课题详情但系统提供了按老师维度汇总的统计页面方便系里掌握整体情况。学生是选题的主体。学生登录后可以浏览当前学期所有可选课题列表按课题名称、教师姓名、关键词进行搜索查看课题的剩余名额和当前状态然后提交选题申请。每个学生同时只能有一个有效的选题记录——所谓有效是指待审核或已通过状态。被驳回后可以重新选择其他课题但一旦审核通过就不能再改了除非教师手动撤销。这个一人一题的约束是整个系统的核心业务规则后面会在数据库层面和代码层面双重实现防止绕过前端直接调接口的情况。2.2 选题与审核的状态流转整个系统的主流程其实只有两条一条是学生的选题流程一条是教师的审核流程。两条流程通过选题记录的状态字段串在一起。学生提交选题申请后系统生成一条选题记录状态为待审核。此时课题的已选人数不增加防止审核不通过后还需要额外操作释放名额。教师看到待审核记录后可以选择通过或驳回。通过后状态变为已通过课题已选人数加一驳回后状态变为已驳回学生可以重新选择其他课题。这里有个细节值得展开说为什么不在学生提交时就直接占用名额而是等教师审核我最初设计的版本确实是提交即占用但实际使用中发现一个问题——有学生一股脑把热门题都选一遍占着名额等审核导致真正想选的学生选不了最后审核不通过才释放浪费了时间窗口。改成提交待审核、通过才占额之后虽然教师的审核压力变大了但名额分配更公平。这也算是一次真实业务反馈倒逼设计的调整。除此之外系统还有一条撤销逻辑教师可以在审核通过之后因故撤销某位学生的选题资格将课题名额释放学生重新变为未选题状态。这个操作用于处理中途换题、学生退课等特殊情况同时在日志中记录原因。2.3 核心流程的边界条件设计梳理流程时最容易漏掉的就是边界条件我做了一个完整的清单逐一处理学生提交选题时如果已经有一条待审核或已通过的记录系统直接拦截提示当前已有在审或通过的选题。课题可选人数为1时只要有学生审核通过课题自动变为已满员状态不再出现在可选列表中。学生只能看到当前学期、状态为可选或已满员的课题历史课题和未开放课题一律不可见。教师只能审核自己名下的课题选题记录接口层面做了归属校验防止越权。学期切换时上一学期的所有选题记录自动归档学生在新学期重新选题。这些边界条件看似琐碎但正是它们决定了系统是否可用。我见过不少功能完好的演示系统一到真实使用场景就崩绝大多数都是栽在边界条件上。所以这一部分花费的时间比重绝不小于写业务代码。3. SpringBoot后端的关键实现状态管理、并发控制与登录鉴权后端是整个系统的数据中枢。我选择SpringBoot是因为它在课程设计类项目里生态最成熟Spring MVC处理请求、Spring Data JPA或MyBatis操作数据库、Spring Security管理安全一套组合拳下来几乎不需要额外造轮子。当然不同版本的选型有讲究后面细说。3.1 分层结构与请求处理链路这个项目的后端采用经典的四层结构Controller层接收HTTP请求并做参数校验Service层实现业务逻辑Mapper/Repository层访问数据库实体类负责数据映射。层与层之间严格单向依赖Controller不直接操作数据库Service不直接处理HTTP细节这样后续排查问题时可以快速定位是接口问题还是逻辑问题还是数据问题。举个例子学生提交选题的接口请求路径大概长这样POST /api/selection请求体里包含课题ID。Controller层拿到课题ID后先做基础校验——课题是否存在、当前学期是否开放——然后交给Service层。Service层首先查询学生当前的选题记录判断是否已有待审核或已通过状态接着查询课题信息判断是否还有剩余名额全部通过后开启事务插入一条选题记录状态设为待审核。如果中途任何一步校验失败直接抛出业务异常由全局异常处理器统一转换为JSON错误信息返回给前端。这套链路的优点是职责单一、便于测试。我习惯在每个Service方法里先写注释标明业务规则再写代码这样过两周回来看还能快速想起当初的意图。3.2 并发选题防超抢的落地方案选题系统有一个绕不开的技术问题并发。几十个学生同一时间都点提交选题如果恰好都是同一个热门课题怎么保证名额不超前端按钮禁用、提示正在提交这类手段只能防君子挡不住恶意请求和网络重放。我的做法是在数据库层面加双保险。第一道保险是选题记录表的唯一索引UNIQUE KEY uk_student_current (student_id, status_valid_flag)。但这里有个技术细节——MySQL的唯一索引不允许同一字段出现多个NULL值不对MySQL的InnoDB引擎中唯一索引允许多个NULL值所以不能用status字段直接做唯一索引因为一个学生会有多条历史记录。实际方案有两种一是加一个当前有效标记字段有效为1历史为0对(student_id, valid_flag)建唯一索引二是单独维护一张学生当前选题表每个学生最多一条记录天然强制唯一。这两种方案我都实现过第二种更干净也更容易理解。第二道保险是事务内的行锁。提交选题时无论先查课题表还是先插记录都要保证判断名额和增加计数在同一个事务里原子执行。关键操作是对课题表记录加行锁SELECT ... FOR UPDATE锁住课题行之后再判断当前已选人数是否小于上限满足则更新人数、插入选题记录。这样两个并发事务同时进来时第二个事务会被阻塞等第一个提交后再读取最新人数自然也就不会超卖。实测下来这两种机制叠加之后即使用脚本同时发几十个请求抢同一个课题最终也只有设定数量的学生能成功其余全部收到课题名额不足的提示。这也算是一道经典的秒杀练习放到选题场景里同样适用。3.3 基于JWT的角色鉴权与拦截器系统虽然不算复杂但三种角色的权限差异很明显安全设计不能只是摆设。我采用的是JWTJSON Web Token无状态鉴权方案用户登录成功后后端签发一个包含用户ID、用户名、角色信息的Token前端每次请求在请求头里携带后端通过拦截器解析校验。实际实现时我在SpringBoot里写了一个AuthInterceptor注册到WebMvcConfigurer中。拦截器负责两件事一是解析请求头中的Token验签并判断是否过期二是根据Token中的角色信息校验当前请求URL是否有访问权限。对于不需要登录就能访问的接口比如登录接口本身用白名单方式排除。这里有个容易被忽略的细节Token中不要放敏感信息。有些同学直接把用户密码放进Token里这等于把密码明文写在了每次请求头上一旦Token被截获密码就泄露了。我的做法是Token里只放用户ID、用户名和角色密码等敏感字段任何时候都从数据库查询。另外前端存Token也有讲究。放在localStorage里最简单但有XSS风险放HttpOnly Cookie里更安全但要注意跨域时Cookie的SameSite设置可能影响携带。这个项目里我采用localStorage存储配合前端路由守卫判断登录态对于课程设计场景来说够用但如果你做生产级系统建议升级为Cookie方案。4. Vue前端怎么搭页面组织、API封装与角色区分的实操记录前端部分我选的是Vue搭配Element UI组件库。这套组合在课程设计项目中非常流行组件齐全、文档完善、社区案例多遇到问题搜一下基本都有答案。整个前端工程结构按照页面—组件—API—路由四层组织。4.1 路由与菜单如何按角色区分前端先按登录状态做了第一层分流未登录用户访问任何页面都会被路由守卫重定向到登录页。登录成功后根据用户角色动态生成菜单和路由。管理员看数据统计和用户管理页教师看课题管理和审核页学生看选题页和我的选题页。具体做法是登录接口返回用户信息和角色后前端根据角色从路由配置里筛选出可访问的路由表动态添加到Vue Router中同时渲染对应的侧边栏菜单。这里有个实操经验路由表一定要区分静态路由和动态路由。登录页、404页属于静态路由业务页面全部属于动态路由刷新页面时要重新加载动态路由否则一刷新就白屏。我最初没处理刷新问题结果每次刷新都跳回登录页一度以为是登录态丢失排查了半天才发现是动态路由没恢复。后来在全局前置守卫里加了一步如果本地有Token但路由表中没有业务路由就先调用一次获取用户信息接口重新生成路由表再放行。这样刷新问题就彻底解决了。4.2 axios封装与接口对接约定前端所有HTTP请求统一走一个封装好的axios实例。封装的核心有三块请求拦截器在每次请求前把Token加到请求头响应拦截器统一处理业务错误码和HTTP错误以及集中处理401未授权跳转登录页。接口地址统一以/api开头后端Controller用RequestMapping(/api/...)对应。前后端接口字段名约定使用小驼峰后端返回的数据结构统一为{ code, message, data }。这套约定一旦定下来前后端联调时就不需要反复对字段。我也见过一些项目前后端各写各的字段名一个用student_name一个用studentName联调时天天对着文档发愁纯粹是自找麻烦。封装好之后页面里调用接口就非常清爽。比如学生提交选题只需在Vue组件里调用this.$api.selection.submit(topicId)剩下的Token注入、错误提示、Loading状态都由封装层处理。代码可读性高维护成本也低。4.3 联调过程中最容易出问题的地方前后端联调时踩得最多的坑有三个我挨个说。第一个是跨域。前端开发服务器默认跑在8081端口后端是8080浏览器会拦截跨域请求。我的解决方案是在Vue的vue.config.js里配置devServer代理将/api开头的请求转发到http://localhost:8080这样前端看起来就是同源请求不需要后端额外开启CORS。如果你选择在后端用CrossOrigin注解开启跨域也可以但注意要把allowCredentials配置对否则携带Token的请求会出问题。第二个是日期格式。后端返回的时间字段如果序列化成时间戳前端需要自己转换如果返回的是带T的ISO格式字符串JSON解析后也容易跟预期不一致。我的做法是在后端统一配置Jackson的日期格式为yyyy-MM-dd HH:mm:ss前端直接展示即可省掉一批转换工具函数。第三个是参数校验的一致性。前端做了必填校验后端也必须做绝对不能依赖前端校验。恶意用户可以绕过前端直接构造请求后端如果不在Controller或Service层校验参数非法数据就会写进数据库。这个项目里后端用javax.validation注解对请求实体做了非空、长度等校验校验失败会返回明确的错误信息。5. MySQL表结构与数据关系几张表撑起整个业务数据库设计是选题系统的地基。这套系统虽然功能面不少但核心表其实就那么几张把表之间的关系理清楚业务逻辑也就通了一半。5.1 用户、课题、选题记录三张核心表第一张是用户表。包含用户ID、用户名、密码BCrypt加密存储、真实姓名、角色管理员/教师/学生、所属班级学生、所属院系教师、创建时间等字段。用户表和角色是简单的一对一关系没有单独拆角色表因为这套系统角色固定且不会扩展拆表反而增加联查成本。第二张是课题表。字段包括课题ID、课题名称、课题描述、所属教师ID、所属课程/学期、可选人数上限、已选人数、状态开放/关闭/满员、创建时间、更新时间。课题表通过教师ID关联用户表体现每个课题归属一个教师的关系。已选人数这个字段是冗余字段可以由选题记录统计得到但保留它可以在列表页快速显示剩余名额避免每次都汇总计算。这个冗余是经过权衡的数据一致性靠事务保证。第三张是选题记录表。这条表是整个业务的核心字段包括记录ID、学生ID、课题ID、状态待审核/已通过/已驳回/已撤销、提交时间、审核时间、审核意见、审核教师ID。每条记录代表某位学生某一次选题申请同一个学生对同一个课题可以有历史记录比如被驳回后再选但同一时刻只能存在一条有效记录。除了这三张主表还有一张操作日志表记录关键操作的行为人、时间、操作类型和操作详情。它不是业务必需但一旦出现纠纷就是铁证强烈建议保留。5.2 唯一索引与事务的配合使用表结构设计里最关键的约束不在字段类型而在索引和事务。学生一人一题的约束我采用前面提到的学生当前选题表方案这张表只有两个核心字段学生ID主键、当前选题记录ID外键关联选题记录表。每个学生最多一行从数据结构上就杜绝了一个学生同时拥有两个有效选题的可能。课程表的名额控制则依赖事务和行锁。我曾在一开始只用先查询再更新的逻辑实现名额扣减结果在高并发下超卖了三次。后来改成在事务里先SELECT ... FOR UPDATE锁定课题行再更新已选人数问题才彻底解决。这里还想谈一个设计取舍是否使用外键约束。这个项目里我保留了逻辑外键但没有在表上建物理外键原因有二物理外键会增加删除数据的成本调试数据时很麻烦很多团队在数据量上来后会改用分库分表物理外键会变成阻碍。用逻辑外键配合Service层校验既保证业务正确性又给后期留了灵活度。对于学习项目你甚至可以建上物理外键看到数据库自动拒绝非法关联理解会更直观。5.3 演示数据与真实数据的处理源码包里通常附带topic_manage.sql初始化脚本里面除了建表语句还包含一批演示数据一个管理员账号、三五个教师账号、二十个学生账号、每个教师几个到十几个课题。这些数据的用途是让你跑起来就能看到效果不用从零开始造数。但要注意演示数据千万别直接用在真实环境。我在实际部署时遇到过有人忘了改初始密码被学生猜中管理员密码的尴尬情况。所以拿到源码后第一件事应该是登录管理员账号修改默认密码或者直接删除演示账号通过管理员的批量导入功能重新录入真实师生数据。批量导入功能我实现的是Excel模板上传后端用EasyExcel解析逐行校验后插入错误行会返回具体报错原因比如学号重复手机号格式错误。6. 拿到源码后的一小时本地运行全流程实操记录标题说可直接运行这句话不能白说。我把从零开始跑通这套系统的最短路径完整记录一下按照这个顺序操作预计一个小时以内可以让前后端同时运行起来。6.1 环境准备JDK、Node、MySQL版本搭配后端要求JDK 1.8及以上推荐JDK 1.8或JDK 11不要直接上JDK 21某些旧版本的依赖可能不兼容。Maven建议3.6以上。前端要求Node.js 16或更高版本建议用LTS版本。MySQL推荐5.7或8.0源码的初始化脚本兼容这两个版本但连接配置略有差异后面说。先把本机已有环境检查一遍。命令行里分别执行java -version、mvn -v、node -v、npm -v、mysql --version确认都存在且版本达标。环境不齐的话按对应官网下载安装即可这个环节最花时间的是下载安装本身很快。数据库方面启动MySQL服务后用客户端工具Navicat、DataGrip、命令行都行执行初始化脚本。脚本文件名一般是topic_manage.sql里面自动包含建库语句CREATE DATABASE IF NOT EXISTS topic_manage你只需要选择执行脚本或直接source导入库和表都会自动创建好。导入完成后验证一下USE topic_manage; SHOW TABLES;看到用户表、课题表、选题记录表等就说明成功了。6.2 导入数据库与修改后端配置数据库导入成功后打开后端源码目录找到src/main/resources/application.yml。这里面需要修改的核心配置有三个数据库地址、用户名、密码。默认为jdbc:mysql://localhost:3306/topic_manage、用户root、密码123456。如果你的MySQL密码不是这个必须修改否则启动时会在连接数据库环节直接报错。这里有一个MySQL 8.0专属的坑。8.0默认的认证插件是caching_sha2_password老版本的驱动连不上报错信息看起来像Public Key Retrieval is not allowed。解决方法是在JDBC连接串上追加参数allowPublicKeyRetrievaltrueuseSSLfalseserverTimezoneAsia/Shanghai。另外5.7版本不需要allowPublicKeyRetrieval这个参数所以初始化脚本和配置文件最好和你的MySQL版本对应。如果启动时报时区相关的错误十有八九是serverTimezone没配或配错了。修改完成后在源码根目录执行mvn spring-boot:run或者用IDE打开项目直接运行主类。看到Spring Boot的启动日志刷完最后一行是Started ... in xx seconds说明后端启动成功默认端口8080。这时可以先用浏览器访问http://localhost:8080/api/health之类的健康检查接口或者直接开始启动前端。6.3 前端启动与前后端联调验证进入前端源码目录这个目录下应该有一个package.json文件。执行npm install安装依赖这一步在网速一般的情况下可能需要几分钟到十几分钟。安装完成后执行npm run serve开发服务器启动默认端口通常为8081。控制台会打印访问地址浏览器打开即可看到登录页面。为什么开发服务器的默认端口不是8080因为后端占了8080。Vue CLI的默认端口是8080但项目配置里改成了8081并且设置了代理所有/api请求转发到http://localhost:8080。如果你发现后端端口改了这里也要对应修改代理目标否则前端请求会全部失败表现为接口报错、页面没有数据。启动完成后用初始化脚本里的演示账号登录。管理员账号登录后应该能看到用户管理和数据统计页面教师账号能看到课题管理页面学生账号能看到课题列表。分别测试一遍完整的流程管理员导入学生、教师发布课题、学生选题、教师审核通过这样整个系统就跑通了。实测下来最顺畅的验证顺序是先以管理员身份创建两个学生再用教师身份发布一个课题并设置人数上限为1然后两个学生分别登录尝试选同一个课题第二个学生应当收到名额不足的提示。这样一测核心业务逻辑是否正常就一目了然了。7. 运行期常见故障与排查思路我踩过的那些坑最后这部分跟大家分享一些实际运行中大概率会遇到的故障和排查方法。这些问题我在开发调试阶段几乎都踩过一遍整理成清单能帮你少走不少弯路。7.1 跨域问题的完整排查链路前端启动后页面能打开但列表数据加载不出来打开浏览器开发者工具Console里报错类似CORS policy: No Access-Control-Allow-Origin header或者Network里看到请求状态是(failed)net::ERR_FAILED。这基本就是跨域问题。排查思路分三步。第一步确认前端代理是否生效。看vue.config.js里的devServer.proxy配置确认/api前缀和代理目标地址正确。如果你修改过后端端口这里的target也要同步修改。第二步确认代理是否把请求真的转发到了后端。看后端控制台有没有打印出对应的请求日志如果后端完全没反应说明代理没配上或者前端请求路径本身就错了。第三步如果你绕开代理直接走后端CORS那么检查后端是否配置了CorsFilter或CrossOrigin并且allowedOrigins里是否包含前端地址。我看过很多初学同学在跨域上卡了一两天其实大多数时候都是代理配置里少写了一个changeOrigin: true或者后端CORS配置里allowedOrigins写成了*导致和携带Token冲突。这两个点优先检查。7.2 数据库连接中的编码与时区坑数据库问题往往比业务代码问题更隐蔽。最常见的两个症状第一个是中文乱码。页面或后台能看到中文课题名称变成???. 原因多半是数据库或表的字符集不是utf8mb4。在MySQL 8.0里建库时可以显式指定CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci初始化脚本里其实已经带上了但如果你手动建库很容易用默认的latin1。检查方法很简单SHOW CREATE DATABASE topic_manage;看字符集是不是utf8mb4。如果不是改库字符集或重建。第二个是时区导致的日期错乱。日期字段会比本地时间晚8小时或者直接插入失败。根源在于JDBC连接串里缺了serverTimezoneAsia/Shanghai。有些同学会用serverTimezoneGMT%2B8这也可以但推荐直接用数据库名时区直观且不容易错。7.3 修改配置后最常见的连锁反应我最后聊一个更隐蔽的坑你以为只改了一个配置结果引发了另一个地方的问题。典型场景是前端端口被占用你把前端开发服务器端口从8081改成了8082结果页面能打开了接口却全部报错。为什么因为vue.config.js里的代理配置写死了target: http://localhost:8080这没问题但你忘了代理配置中有一行pathRewrite或其他设置或者你把后端端口也一起改了导致代理目标失效。修改任何端口、地址类配置前先全局搜索一下有没有其他地方引用了旧值这个习惯可以省掉大量排查时间。还有一个场景是MySQL从电脑A迁移到电脑B数据文件直接拷贝过去但B机器的MySQL版本和A不一致导致驱动认证方式不匹配。如果启动时报Unable to load authentication plugin caching_sha2_password优先检查MySQL版本是否8.0再检查驱动版本是否8.x驱动和数据库版本对不上是这类问题最常见的根因。最后一个建议每一次修改配置后后端要重启前端如果配置了热更新可能会有延迟必要时手动重启前端开发服务器。很多改了没生效的案例实际上只是进程没重启并不是配置写错了。这套系统从业务梳理到技术实现再到调试上线我前前后后跑了三轮迭代。最深的体会是课程设计选题管理这种看似小的系统恰恰是锻炼完整Web开发流程的好项目——有明确的多角色权限、有状态流转、有并发冲突、有前后端协作麻雀虽小五脏俱全。如果你拿到源码准备自己改造二次开发建议优先在选题冲突处理和数据统计报表两个方向上做增强前者是业务核心后者是真实使用中最高频的需求。我个人建议的扩展点是在现有选题记录表基础上增加一个选题志愿机制允许学生按优先级提交多个志愿由系统按志愿顺序自动分配——这块做深了就是选课系统的雏形了。