选课系统这个题目在Java毕设里属于典型的“看着简单做起来全是坑”的项目。很多同学拿到“SpringBootVue大学生选修选课系统”这类题目后第一反应是到处找源码找到后却不知道怎么跑起来更不知道怎么在答辩时把系统的亮点讲清楚。结合我自己做过的一版选课系统把从设计到实现、从跑通到优化的完整经验整理出来给准备做这类题目或者正在改别人源码的同学一个参考。1. 选题思路与整体规划1.1 为什么选课系统是Java Web毕设的经典选题选课系统之所以被无数高校作为Java Web毕业设计题目不是因为简单而是因为它“麻雀虽小五脏俱全”。一个稍微完整的选课平台至少要覆盖三种角色学生、教师、管理员。学生要能浏览课程、选课退课、查看个人课表教师要能开课、管理选课学生名单、录入成绩管理员要管用户、管课程池、管选课轮次和时间窗口。单是角色权限这一层就能拉开很多差距。从技术角度看选课系统天然适合拆分前、后端。前端需要多页面交互登录页、课程列表页、我的课表页、后台管理页后端需要接口支撑、权限校验、事务处理再加上数据库设计里的多对多关系学生和课程几乎把Java Web开发的核心知识点都覆盖了。所以导师们乐意用这个题目考核学生的综合能力企业面试官看到也能快速判断你的项目设计水平。1.2 需求拆解不要一上来就写代码我见过太多人拿到题目后直接建SpringBoot工程结果写了一周发现要返工。正确的做法是先做需求拆解哪怕只写在纸上也能帮你把工作量估算出来。以一个常见的选课系统为例最小功能集可以划分为学生端注册/登录、浏览选修课程、选课判断容量、判断时间冲突、退课、查看已选课程列表、查看个人课表、修改密码。教师端查看自己开设的课程、设置课程容量/学分/上课时间、查看选课学生列表、结课录入成绩。管理端管理教师和学生账号增删改查、重置密码、维护课程信息新增/下架、查看选课统计每门课报名人数、管理选课轮次开放选课/关闭选课。把需求拆到每个角色之后再去设计数据库和接口思路就清晰得多。很多做毕设的同学卡住不是不会写代码而是需求边界不清楚做着做着又加功能前端的页面也跟着改最后哪里都是半成品。我建议做一个固定功能清单标出“必须完成项”和“有余力再完成项”先保底再优化。1.3 技术选型要与需求匹配选课系统这种中等规模的后台管理系统SpringBoot Vue的组合确实合适。SpringBoot负责提供RESTful API、事务管理、权限拦截Vue负责交互界面和状态管理。有一个常见误区是“既然是毕设用JSP SpringMVC就够了”但从前端体验和答辩展示效果来看前后端分离的方案明显更占优势——你可以额外展示接口文档、跨域配置这些本身都是加分项。我的选型建议如下后端SpringBoot 2.7.x MyBatis-Plus 3.5.x MySQL 8.0 JWT认证。不推荐用Spring Security因为如果你不熟悉它的过滤器链机制调试起来会被“哪里拦截了”逼疯。自己实现一个JWT拦截器更直观答辩时也能讲清楚原理。前端Vue 2 Element UI。Vue 3也能做但Element UI只支持Vue 2Element Plus在Vue 3下需要用自动导入配置如果只是想省事Vue 2 Element UI的组合更稳定。别在这上面追求“新”稳定出活才是王道。数据访问MyBatis-Plus代码生成器可以快速生成基础CRUD把时间花在选课业务逻辑上。2. 数据库设计核心ER模型与关键表结构2.1 核心表与关系拆解选课系统的数据库设计核心在于理清“用户”“课程”“选课记录”三者之间的关系用ER图表示很简单用户与课程之间是多对多关系通过中间表“选课记录”来关联。为了简化权限逻辑通常把用户表拆成学生表student和教师表teacher或者统一放在一张user表里用角色字段区分。我采用的是统一用户表方案字段如下id主键username登录账号学号/工号password加密后的密码BCryptrole角色1学生、2教师、3管理员name真实姓名department院系/专业课程表course是另一个核心表设计时要考虑选课业务的约束条件id主键course_no课程编号业务编号区别于主键course_name课程名称teacher_id开课教师IDcredit学分用于统计毕业学分capacity课程容量选课人数达到上限就停止选课selected_count当前已选人数这个字段可以冗余存储避免每次都count中间表class_time上课时间建议用“星期几第几节”编码存储例如 “1-3,5”表示星期一第三大节的5-6节class_room上课地点status课程状态1可选、0已关闭选课记录表student_course是关联表记录学生选课行为idstudent_idcourse_idselected_time选课时间便于后续统计score成绩教师端录入可以为空2.2 容量控制数据库层面不能只靠逻辑判断容量控制是选课系统的核心业务规则也是毕设答辩时老师大概率会追问的点。最多见的简单实现是选课时先查一下当前已选人数如果小于容量就执行插入。这个逻辑单独跑没有任何问题但并发情况下会翻车——两个用户同时选最后一门课的名额可能同时查到“还剩1人”然后都插入成功超员。解决思路有两个方向。第一是在course表上使用版本号字段通过乐观锁控制更新第二是先执行一个原子性的更新操作把selected_count加1然后根据受影响行数判断是成功还是失败。我实际用的是第二种UPDATE course SET selected_count selected_count 1 WHERE id ? AND selected_count capacity;这行SQL是关键。它把容量校验和数量更新合并成了一个原子操作。如果返回受影响行数为1说明占座成功再插入选课记录如果返回0说明课程已经满了直接提示“课程已选满”。这个方案我在答辩时讲得很细因为它是体现数据库功底的重要细节。注意加上事务后如果插入选课记录失败需要回滚更新保证数据一致。2.3 时间冲突检测两张表的数据都要查时间冲突是另一个必须处理的业务规则。同一学生在同一时段只能上一门课设计时要注意不能只看课程表course里的时间去重还要检查已选课程集合是否有时间重叠。我的实现思路是这样的查询该学生所有已选课的时间字段class_time与当前课程的时间进行段位比较。比较时先把“星期几”和“节次区间”拆出来判断星期是否有交集再判断节次区间是否有重叠。这里有一个常见坑如果你用字符串存“1-3,5”SQL里用like进行匹配效率不高而且逻辑容易出错。我建议把class_time拆成两个字段week_day星期几1~7和period节次数字或位掩码比如节次用整型位掩码表示1-2节值1、3-4节值2等通过位运算快速判断重叠。if (selectedDay targetDay (selectedPeriod targetPeriod) ! 0) { // 时间冲突 }按位掩码的好处是一次逻辑运算就能判断是否有重叠节次而且查询速度不受like的影响。但要说明的是这种方式在数据库可读性上差点意思适合有一定编码能力的同学。如果觉得麻烦也可以用存“星期几”“开始节次结束节次”的方式用区间比较判断理解起来更容易写起来的SQL也更直观。示例如下SELECT COUNT(*) FROM student_course sc JOIN course c ON sc.course_id c.id WHERE sc.student_id ? AND c.week_day ? AND NOT (c.end_period ? OR c.start_period ?);查到大于0就说明存在冲突代码层直接返回提示信息。这种方式在数据量少的高校场景下完全够用。2.4 角色权限表与接口怎么协同数据库设计好之后角色的差异化其实更多体现在接口层。学生表和教师表如果分开前端请求不同的表数据即可如果统一在一张用户表里就需要通过角色字段区分。我建议在user表里加一个role字段学生和教师信息用单独的资料表去补充。比如学生需要“学号”“班级”教师需要“工号”“职称”这些扩展字段不宜全部堆在user表里应该按角色拆分扩展表。这样的好处是权限拦截器只需要解析JWT里的role字段再决定某个接口是否放行。比如“选课”接口只允许role1的学生访问“录入成绩”只允许role2的教师访问而管理员能访问用户管理接口。这些限制在接口层写好比在前端隐藏按钮要安全得多。3. 后端核心模块实现接口设计、鉴权与业务细节3.1 统一响应格式前端联调的第一道保障前后端分离项目最忌讳的就是响应格式不统一。有些接口返回{code: 200}有些接口直接返回一个布尔值前端写axios拦截器时会很痛苦。我统一用一个Result对象封装所有接口响应public class ResultT { private Integer code; // 200成功400业务失败500异常 private String message; private T data; }所有Controller方法的返回值都是Result成功时调用Result.success(data)业务失败时调用Result.fail(课程已满)。这样做的好处是前端可以在axios响应拦截器里统一处理code不等于200就弹出message等于200时才走业务逻辑。我用一个示例说明前后端节约的沟通成本。后端选课接口返回{ code: 400, message: 该时段已有课程换一门课吧, data: null }前端拦截器发现code400直接Message.error(res.message)完全不用在页面里写判断。整套交互下来业务代码清爽很多。3.2 JWT鉴权拦截器 注解双保险毕设项目用Session做登录也不是不行但前后端分离部署时跨域比较麻烦。我选了JWT方案用户在登录接口提交账号密码校验成功后返回一个包含用户身份信息的token字符串前端把token存在localStorage里后续每个请求都在Headers里带上Authorization: Bearer token。在SpringBoot里实现鉴权最常规的思路是写一个HandlerInterceptor。拦截器里做三件事从请求头取token、解析token得到userId和role、把用户信息放到ThreadLocal或request attribute里供后续使用。然后通过WebMvcConfigurer注册拦截器并配置放行路径registry.addInterceptor(jwtInterceptor) .addPathPatterns(/**) .excludePathPatterns(/api/auth/login, /api/user/register);放行路径必须把登录注册排除掉否则用户还没登录就被拦下来了。有一个坑是引入了拦截器后静态资源的访问也可能被拦比如前端部署在同一个服务下时/img/**等路径也要排除。这个细节不处理好本地跑的时候页面样式全丢排查半天还以为是静态资源路径写错了。3.3 选课接口事务、锁与SQL的配合选课接口是整个系统业务逻辑最复杂的地方也是答辩时最容易被追问的地方。完整流程可以这么设计参数校验用户角色必须是学生、课程状态必须是可选。查重校验判断该学生是否已经选过这堂课student_course表唯一约束或查询判断。时间冲突校验按上面的方式查询已选课程是否有时间重叠。原子占座执行UPDATE course SET selected_count selected_count 1 WHERE id ? AND selected_count capacity。插入选课记录。提交事务。这个流程用Transactional标注在方法上原理是保证这5步要么全部成功、要么全部回滚。这里有个容易忽略的点事务范围内的查询和更新要注意锁的粒度。我见过有人在整个方法上加了悲观锁select for update结果并发差、还可能因为锁时间过长导致死锁。如果你按我上面写的“原子update”方式来做一般不需要额外加悲观锁。退课接口恰好反过来删除选课记录后执行UPDATE course SET selected_count selected_count - 1 WHERE id ?两个操作同样需要事务。有一个小经验退课操作通常不会失败但万一删除记录成功、更新课程表失败事务回滚后会出现“记录没删掉、但selected_count没减”以外的另一种数据不一致。所以两个操作必须放在同一事务里。3.4 成绩录入与统计查询MyBatis-Plus的SQL扩展教师端录入成绩本质上就是对student_course表做update操作。数据表里score字段是浮点型录入时要校验范围避免出现负分或大于100分这些只是很小的细节但能看出一个人是否考虑过数据的完整性边界。说道统计查询经典的SQL写法可以根据课程ID统计选课人数、根据学生ID统计已选学分再计算绩点。这些查询如果纯靠MyBatis-Plus自带的Wrapper有时比较绕我建议直接自定义SQL。例如统计每门课的选课人数就是一个分组聚合SELECT course_id, COUNT(*) AS cnt FROM student_course GROUP BY course_id;这类统计接口往往会在系统首页做个“数据看板”展示总课程数、总学生数、总选课记录数。我的做法是把统计SQL都放在Mapper里用Select注解写原生SQL然后由Service层组装返回前端拿到后渲染成卡片或简单图表。这部分如果做好了美观度和完成度都很加分。3.5 后端分层与代码结构很多毕设代码给人的印象是“一把梭”Controller里直接写业务逻辑数据库操作散落在各处。这种代码跑起来没问题但如果你之后想加个单元测试、或者想讲清楚模块关系会被部分细节制约。我采用经典三层结构Controller层只做参数接收和结果响应不在里面写业务判断。Service层负责全部业务逻辑事务注解加在实现类方法上。Mapper层接口化数据库操作复杂SQL写在XML或注解里。三个模块之间单向依赖结构清晰。实际开发中有一个常见问题是大家往往在Service层把所有逻辑写得很长几百行一个方法。如果代码膨胀建议拆分比如选课逻辑中涉及校验的部分抽成checkSelectCourse方法涉及占座的抽成updateSelectedCount让主方法像讲故事一样读下来。这种代码风格在答辩时非常讨巧因为老师看代码的第一印象就是“这个人有工程素养”。4. 前端Vue实现要点组件、路由与交互4.1 前端工程结构按业务拆模块Vue端不宜把所有页面都塞在同一个目录下否则维护起来很痛苦。我按角色拆分视图目录views/common登录、注册、修改密码views/student课程列表、课程详情、我的课表、选课记录views/teacher开课管理、选课名单、成绩录入views/admin用户管理、课程管理、数据看板路由配置与视图目录对应用懒加载方式引入组件。需要注意的一点是路由守卫必须写在main.js或router目录里统一检查每次跳转时本地是否存在token不存在则重定向到登录页。如果在每个页面组件再去判断登录状态就是重复劳动也容易出现漏判。4.2 课程列表页的动态渲染与交互课程列表页是学生端的核心页面需要展示课程名称、学分、容量、教师、时间地点和选课状态。用Element UI的Table组件可以做得很规整。状态字段建议由后端计算好返回例如已选该学生已经选了这门课可选课程有名额且学生没选过已满容量已满冲突该时段与已选课程时间重叠后端一次返回这四种状态前端根据状态渲染按钮可以极大地简化页面逻辑。很多同学容易把“是否已选”“是否满员”的判断拆分到前端来做还需要额外请求已选课程接口来比对不仅多一次网络请求而且代码复杂。我在后端就把状态算好前端只做展示接口数据结构如下{ id: 12, courseName: 人工智能导论, credit: 2, teacherName: 张老师, classTime: 周一3-4节, selectedCount: 10, capacity: 40, selectStatus: SELECTED }选课按钮点击后因为涉及异步请求需要防止用户连点导致重复提交。我的做法是在请求前把按钮设为loading状态并禁用按钮请求结束后无论成功失败都恢复。这个小技巧能避免很多脏数据。4.3 Vuex状态管理存储用户信息和权限登录成功后后端返回token和用户基本信息id、name、role。前端把token放进localStorage是为了刷新页面不丢登录态用户信息则建议存到Vuex中用于控制侧边栏菜单和按钮的显示。例如教师登录后不显示“数据看板”菜单、学生登录后不显示“成绩录入”入口。vuex里持久化的处理很常见页面刷新时Vuex会重置所以需要在mutations里初始化一个动作从localStorage读token并调接口重新拉取用户信息。这里有一个值得注意的坑如果你把用户信息也存到localStorage里会有被人从开发者工具里篡改的风险比如把一个学生用户信息改成管理员角色。虽然毕设系统安全要求不高但答辩老师如果问起来会比较尴尬。保险的做法是本地只存token用户信息通过token再查询一次接口获取。4.4 axios封装与拦截器axios拦截器在前端工程里是必不可少的具体做两件事请求拦截器给每个请求的Header加上Authorization。响应拦截器统一处理Result响应。code为200时直接返回datacode为400时提示messageHTTP状态码为401未登录或token过期时清空token并跳回登录页。我实际开发中还遇到一个情况后端异常时返回500的HTTP状态码响应拦截器会把axios instance的reject回调触发而业务错误400时HTTP状态码仍是200因为后端正常返回。所以前端要区分处理否则后端一报错前端就弹一个莫名其妙的状态码错误。这个细节说难不难但不提前统一约定联调时会花很多时间在排查“为什么接口文档明明写了前端却拿不到数据”上。4.5 选课页的“按周视图”课表设计学生端最直观的需求是“我的课表”用周视图展示横向是节次1-12节纵向是星期周一至周日。这个界面用CSS Grid布局就能实现根据后端返回的已选课程列表动态生成占位格子把课程名填进去。这个功能实现的关键其实是让后端返回的数据结构便于前端生成课表。我让后端返回一个二维数组timetable[weekDay][periodSection]直接存放课程名节点。前端拿到后直接遍历渲染不用再做复杂的字符串解析。这种“后端帮你把前端算好的事做了”的思路在前端页面复杂时可以大幅简化联调成本值得推广使用。5. 接口文档与联调从规范到细节5.1 接口文档怎么组织才实用接口文档对于毕设项目不只是答辩材料更是你开发时自己参考的依据。网上能找到的选课系统源码有些自带的接口文档格式混乱参数写不清楚README里的说明又不完整。我的习惯是先用表格把接口清单列出来再逐个写细节。一个描述接口的表格至少要包含以下信息接口名称与用途比如“选课接口”请求方式与路径POST /api/student/course/select请求参数字段名、类型、是否必填、说明响应格式成功、失败分别长什么样权限说明学生角色可访问以选课接口为例请求参数就是courseId响应成功时返回{code:200, message:选课成功}失败时返回{code:400, message:课程已满}。把这些信息写清楚不仅答辩时老师翻阅方便自己也少踩很多“接口调用不对”的坑。5.2 接口版本与统一前缀后端接口路径建议统一添加前缀/api例如/api/auth/login、/api/student/course/list。好处是前端配置代理时只需要代理/api路径跨域处理更简单同时项目的接口风格看起来也更规范。如果以后系统要做接口版本管理可以再加/v1前缀但现在做毕设没必要硬加。5.3 跨域问题开发环境的处理方案前后端分离开发时最常见的联调问题就是跨域。生产环境可以靠Nginx反向代理解决但开发环境我们一般通过Vue CLI的proxy配置把/api开头的请求转发到后端端口如下所示// vue.config.js devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }这种方式可以绕开浏览器的同源策略。如果你选择在后端直接配置CrossOrigin或CorsFilter也要注意允许的来源不能写*否则某些带Cookie的请求会出问题。虽然JWT方案对Cookie依赖不大但规范起见还是建议配置允许的具体来源。5.4 接口文档和代码同步的经验开发过程中接口经常改写文档是一件容易被拖延的事。我的经验是每写完一个后端接口马上在文档里记录不要等全部写完再补。否则到项目后期你可能已经忘了某个接口的返回结构是怎么变的。也可以用Swagger自动生成但它生成的文档比较笼统对字段含义的描述不够人性化我倾向于用Markdown手工维护。直到答辩前招架得住的不是文档多精美而是能讲清楚设计思路和修改原因。6. 完整项目运行从零到跑通6.1 环境准备与启动顺序如果你拿到的是一个已经完成的项目源码首要任务是把它成功跑起来。先确认本地环境符合要求JDK版本一般是JDK 8或11、Maven版本、Node.js版本、MySQL版本。很多项目跑不起来不是代码有问题而是版本不匹配比如SpringBoot 2.7对JDK 17也支持但项目里用了一些旧依赖时可能冲突。启动顺序我是这样的先启动MySQL创建数据库并执行项目自带的SQL脚本注意SQL脚本的字符集设置避免中文乱码。修改后端配置文件application.yml改对数据库账号密码如果需要改端口就一并修改。后端用Maven打包或直接idea启动确认控制台无报错端口正常监听。前端在项目根目录执行npm install安装依赖再npm run serve启动开发服务器。浏览器访问前端地址通常是localhost:8081查看能否正常登录。如果登录时提示验证码错误或接口404优先排查前端代理是否配置正确、后端是否真的启动成功、接口路径是否完全一致。6.2 SQL脚本的坑建表顺序与数据初始化选课系统的SQL脚本往往包含多个表的创建和初始数据。因外键约束的存在建表顺序有讲究先建基础表user、course再建关联表student_course。如果脚本里带了外键删除时也要先删除关联表的数据否则会报外键约束错误。初始化数据通常包括一个管理员账号和若干测试学生、课程。我的建议是管理员账号一定要用BCrypt加密后的密文写进SQL脚本不要用明文密码。因为在登录逻辑里你一定是按密文去校验的密码不一致你连管理员都登录不进去会误以为项目有bug。这个坑我踩过一次最后是用一个临时跑通的登录接口做对比才发现问题。6.3 源码阅读顺序建议拿到一个陌生项目的源码我建议的阅读顺序是先看README和文档了解项目结构然后看数据库脚本理解数据模型接着看后端的Controller层快速知道有哪些接口再看Service核心逻辑重点看选课、退课、权限这三块最后看前端页面和接口调用情况。不要从头到尾去读每一个文件尤其是mybatis-plus生成的代码很多是自动生成的模板代码一眼扫过就够了。把精力放在理解业务核心类和关键SQL上才能在答辩时对答如流。7. 常见问题与排查实战7.1 选课并发导致超员条件两个学生同时选修同一门还剩一个名额的课程最终结果出现超员。原因传统代码是“先查再插”两个请求都查到了剩余名额为1然后都执行插入。数据库在无约束、无锁的情况下两条插入都成功。排查方式查看选课接口代码看是否有原子更新SQL看course表有没有唯一约束或版本号。解决方式把容量校验和数量更新合并为一条UPDATE ... WHERE selected_count capacity在事务中执行。这个方案我在前文已经详细说明。7.2 前端登录后获取不到用户信息条件登录成功token也存下来了但刷新页面后用户信息变为空。原因用户信息只存在Vuex内存中刷新后Vuex重置没做token持久化和用户信息重新拉取。排查方式在浏览器的Application面板里看localStorage是否还有tokenNetwork面板看刷新时是否发了获取用户信息的请求。解决方式在Vuex的actions中初始化一个方法读取localStorage中的token后请求/api/user/info把返回结果重新填入state。在App组件挂载时调用这个方法。7.3 接口报404但明明写了对应Controller条件前端调用某个接口发现404后端的Controller方法也写了对应路径。排查思路大概率是前端代理没生效或者后端路径没写对也可能是重启后Controller没被扫描到。我遇到的最隐蔽的情况是因为在类上写了RequestMapping(/api/student)方法上又写了PostMapping(/course/select)实际请求路径是/api/student/course/select和文档里写的/api/student/course/select完全一致但文档里漏了某个“/”。由于接口文档是用Markdown手工维护的路径写错一两个字母很容易。排查时直接用Postman按接口文档测一次看后端实际是否能正确返回就能定位问题出在前端还是后端。7.4 数据中文乱码条件从SQL脚本导入的课程数据中文显示为问号或乱码。原因MySQL数据库编码不是utf8mb4或者SQL脚本文件本身编码不对。解决方式建库语句指定DEFAULT CHARACTER SET utf8mb4SQL脚本文件另存为utf-8格式JDBC连接串加上useUnicodetruecharacterEncodingutf8。做完这三步一般乱码问题都能解决。7.5 选课时间冲突判断失效条件明明选了周一3-4节又去选另一门周一5-6节的课系统却提示冲突。原因时间冲突判断用了字符串的like匹配比如class_time存成“周一3-4节”用like去匹配“5-6节”时匹配失败。解决方式把时间拆成结构化字段week_day startPeriod endPeriod用区间判断。这是我在前文提到的做法虽然要改表但能一步到位。7.6 端口占用导致服务启动失败条件后端启动时控制台提示端口被占用。解决方式在application.yml里换一个端口比如从8080换成8089同时前端代理的target也要同步修改。排查时通过netstat -ano | findstr 8080可以看到是哪个进程占用了端口。8. 答辩展示与经验总结毕设项目拿到源码只是第一步真正拉开差距的是你能不能讲清楚系统背后的设计取舍。答辩老师大概率会问你这样几个问题为什么用JWT而不用Session选课并发时如何防止超员时间冲突是怎么判断的如果让你扩展成“多轮选课”或“摇号选课”你会怎么做第一个问题你可以答“前后端分离部署场景下JWT无状态扩展性好”第二个问题答案就是事务与原子更新SQL第三个问题按结构化时间字段做区间判断第四个问题可以在业务逻辑里加一个“选课轮次表”配置每轮开始结束时间并在选课前轮空校验。这样的回答既有深度又有落地方案比背概念好得多。我个人在实际操作中的体会是选课系统真正难的部分不是看懂代码而是理解“数据一致性”为什么重要。容量、冲突、权限每一个约束条件背后都是真实业务场景的取舍。你多想一想“如果我是选课系统管理员我担心什么问题”代码的架构自然就清晰了。最后再分享一个小技巧如果你准备把选课系统作为毕设项目或面试项目一定要自己动手重写一遍选课接口和退课接口不要直接拿现成源码去背代码。你可以先读完源码关上它自己试着实现选课逻辑再回头对比差距。这个方法虽然费时间但效果远好于抱着源码读三遍。等你真正吃透了这套逻辑不管是答辩还是面试提起选课系统你都会有底气。