企业官网建设流程全解析

前后端分离的大学生选修选课系统，用SpringBoot+Vue+MyBatis+MySQL这一套组合来做，是很多同学在课程设计和毕业设计里绕不开的方向。这个项目标题里的“完整源码+部署教程”看着像一句宣传语，但对我来说，它更像是一个真实的工程挑战：一个选课系统要真正可用，不是把页面画出来就行，它得处理登录鉴权、角色权限、课程审核、选课容量、时间冲突、成绩回写、部署上线这一整条链路。这篇文章我会把从需求分析到数据库设计，再到并发选课接口、前端联调、服务器部署的完整过程都写一遍，包括我实际踩过的坑和压测数据。适合正在做课设或毕设的在校生，也适合Java后端刚入门想找个综合项目练手的朋友。

1. 项目解读：这个选课系统到底做了什么

1.1 它不是一个简单的课程表管理工具

很多管理系统做出来，本质上是把Excel搬到了浏览器上，课程列表、学生列表、成绩列表，换了一层皮而已。这个选课系统真正值得做的点在于，它有一个相对完整的业务闭环。“选修”这两个字决定了它和普通CRUD系统的差别：学生有选择权，课程有容量限制，选课有开放时间段，结束后数据锁死不能随意改动，成绩要回写到学生档案。

我把这个闭环拆成三个角色来理解：

• 学生端：浏览本学期开设的选修课程，看课程容量和已选人数，选课与退课，查看自己的课时安排，查询成绩。
• 教师端：申请开设新课程，维护教学班容量，录入学生成绩。
• 管理端：审核教师开课申请，管理学生账号，控制选课窗口的开放和关闭。

有了这个闭环，项目才算一个真正能跑的业务系统，而不是页面演示。我在做需求分析的时候，把这几个角色各自的用例全部列出来，再对着表格逐一核对，后面写接口和设计表结构时基本没做大的返工。

1.2 我为什么坚持把系统拆成前后端分离

说实话，用模板引擎直接渲染页面也能做选课系统，我早期做的几个项目就是这么干的。选课列表、表单、错误提示全在后端拼好返回，听起来也够用，但是一旦业务规则变复杂，比如选课按钮要根据容量、时间冲突、选课轮次三个条件同时变化状态，模板渲染的写法就非常难受，前端交互逻辑和后端页面拼接逻辑缠在一起。

前后端分离之后，前端只需要关心页面展示和用户操作，后端只需要暴露业务接口。两边独立开发、独立部署，联调时有一份接口文档就可以并行推进。实际流量进来时，静态资源完全由Nginx托管，后端只处理API请求，压力小很多。对选课这种“瞬时高并发”场景，静态资源和动态接口分离之后，Nginx本身就能挡掉一大半静态资源请求，后端只需要面对真正打进来的选课接口调用。

1.3 六个核心模块的划分

从模块维度看，整个系统分成六块：

这六个模块加起来，基本覆盖了“选修”场景下的所有动作。如果目标是做一个能交差并且能讲清楚的项目，我个人建议不要盲目加功能，比如消息推送、在线支付、论坛讨论，这些都和选课核心流程无关，加了只会分散你讲项目的精力。

2. 技术选型的底层逻辑：为什么是SpringBoot+Vue+MyBatis+MySQL

2.1 后端：SpringBoot把繁琐留给框架

SpringBoot的核心价值在于自动配置和约定优于配置。我算过一笔账，这种规模的项目，真正要写的核心业务代码大概也就两三千行，如果用传统的Spring XML配置，光组织数据源、事务管理器、Bean扫描就能耗掉大半天。SpringBoot里一个启动类加一份application.yml就完成了大部分工作，剩下的精力全部留给业务本身。

这倒不是说不建议用Spring全家桶的深入知识，而是说在选课系统这种典型的中小业务里，SpringBoot是最贴合场景的选择。它对新手最大的好处是：你能把注意力放在“业务逻辑怎么写”上，而不是“容器怎么配”上。企业生产环境里SpringBoot也是绝对主流，从这个项目入手不亏。

2.2 持久层：MyBatis的灵活与控制感

选MyBatis不选JPA，主要原因是复杂查询场景下我希望能完全掌控SQL。选课系统里有大量统计和判断需求：某个学生已选学分是否超限、某门课程不同教学班的时间是否冲突、某个教学班当前的已选人数是多少，这些用MyBatis动态SQL写起来非常直观，出问题也容易对照原生SQL去理解。

MyBatis的XML映射方式虽然啰嗦一点，但胜在思路和数据库课里学的SQL是一致的，学习成本低。配合上map-underscore-to-camel-case配置，数据库下划线字段和Java驼峰属性自动映射，连写ResultMap都省了。

2.3 前端：Vue生态下的务实选择

Vue最吸引人的地方就是响应式加组件化。配合Vue Router做路由、axios做请求，三件套就够了。组件库推荐直接用Element Plus，表格、表单、对话框、消息提示都封装好了，把精力集中在业务逻辑上。

Vue和Element Plus对中文开发者太友好了，几乎你遇到的每个报错都能在社区找到现成答案。这一点对正在学习阶段的人特别重要，很多时候卡住不是因为思路不对，而是某个组件的API记错了，搜一下就能解决。

2.4 数据库：MySQL在小规模场景里的标准答案

MySQL有各种高可用方案的讨论，但选课系统这个体量，单实例配MySQL 8完全够用。它提供的事务、行锁、唯一约束、索引，正好是选课业务最需要的底层能力。后面我会贴出一组实际压测数据，几百并发下代码事务加数据库唯一约束这套方案非常稳。

有人会问为什么不用PostgreSQL，其实用什么都行，这套业务逻辑和数据库选型关系不大。但MySQL的资料多、教程多、部署资料多，对学生项目来说，这个隐性优势比技术特性本身更重要。

2.5 刻意不引入Redis，同样是一种选型

很多人一听说并发就开始往项目里塞Redis，其实如果单体项目选课人数在几千以内，Redis不是必需品。我选择的是更传统的方案：数据库事务 + 条件更新 + 唯一索引，原因有三点：

1. 系统组件少一个，部署排障简单一半。
2. 数据一致性不需要双写补偿，选课记录和课程容量在同一个数据库事务里完成。
3. 在这个量级下，数据库方案的表现已经足够，压测结果也证实了这一点。

如果以后要做全校范围的在线抢课，再接入Redis做预扣库存和分布式锁也不难。先把基础方案跑通，比一上来就堆技术更有价值。

3. 数据库设计：六张核心表如何撑起选课业务

3.1 用户表、课程表、教学班表、选课记录表

数据库设计是整个项目里我最重视的部分，因为它决定后面所有接口好不好写。核心表一共六张：用户表、课程表、教学班表、选课记录表、成绩表、选课轮次表。

用户表sys_user存放学生、教师、系统管理员的公共字段，用role字段区分身份：

CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(32) NOT NULL UNIQUE, password VARCHAR(64) NOT NULL, real_name VARCHAR(32) NOT NULL, role TINYINT NOT NULL COMMENT '1学生 2教师 3管理员', status TINYINT DEFAULT 1 COMMENT '1正常 0禁用', create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

课程表course和教学班表course_schedule分开设计。一门通识选修课可能开了多个教学班，课程表存放课程编号、名称、学分、考核方式等公共属性，教学班表存放某位老师在哪个时间、哪个地点开的班，以及这个班的容量。这种设计的好处是方便复用课程信息，开多个班时不用重复录入课程属性。

CREATE TABLE course_schedule ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_id BIGINT NOT NULL, teacher_id BIGINT NOT NULL, weekday TINYINT NOT NULL COMMENT '1-7代表周一至周日', start_section INT NOT NULL COMMENT '开始节次', end_section INT NOT NULL COMMENT '结束节次', location VARCHAR(64), capacity INT NOT NULL DEFAULT 60, selected_count INT NOT NULL DEFAULT 0, status TINYINT DEFAULT 1 COMMENT '1审核通过 0待审核', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_course_id (course_id) );

3.2 选课记录表：最重要的一条唯一约束

选课记录表存放学生和教学班的多对多关系，这是选课动作真正产生数据的地方。这张表里有一条我认为是整个项目最重要的约束：

CREATE TABLE student_course ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id BIGINT NOT NULL, schedule_id BIGINT NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_student_schedule (student_id, schedule_id) );

这条唯一约束的意思是：同一个学生不能在同一教学班上产生第二条选课记录。它是防止重复选课的物理底线。哪怕应用层因为并发问题判断漏了，数据库也会挡住。我在压测时故意不加这个约束跑过一次，结果并发下真的出现了同一个学生的多条重复记录，加回去之后问题立刻消失。应用层的重复判断可以有各种方案，但这条约束必须在建表时就加上。

3.3 上课时间字段的规范化设计

很多同学喜欢把上课时间设计成“周一 3-4节”这种字符串，看着直观，实际上冲突检测非常难写，得做字符串解析。我的做法是把星期和节次拆成三个字段：weekday存1到7，start_section和end_section存节次范围。

这种设计的好处是冲突检测变成一个数学判断：两门课的星期相同，且开始节次和结束节次区间有重叠。比如一门课是周一3-4节，另一门是周一4-5节，那么start_section(3) <= end_section(5)并且start_section(4) <= end_section(4)，重叠成立，冲突。这个判断在SQL和Java里都很容易写，也方便做索引。

3.4 已选人数到底要不要冗余存储

我在课程容量这个字段上犯过一个经典错误。最开始的方案是不冗余存储，每次统计都实时查count，这样数据一定准确。结果列表页每次加载都要扫描几千条选课记录做聚合，响应时间直接到了一秒多，完全不可接受。

后来我在course_schedule表里加了selected_count冗余字段，用事务保证它和插入选课记录的操作原子性。查询变成直接读一个整数，列表页回到几十毫秒。核心逻辑是：每一次选课都在同一个事务里先更新selected_count，再插入student_course记录，任何一步失败整体回滚。这样冗余值和实际记录数始终一致。

3.5 初始化脚本要处理好

部署时除了建表，还要写好初始化数据脚本。我准备了这些内容：创建管理员账号，密码用BCrypt加密；创建测试学生账号和教师账号；插入几门带教学班的测试课程；设置一个默认的选课轮次。脚本要保证幂等，重复执行不会报错，这样在服务器上初始化或者重置数据时都很方便。

4. 后端核心逻辑：把选课接口写稳的完整方案

4.1 分层结构与统一返回格式

后端代码我按controller、service、mapper、entity、common分层来组织。controller只做参数接收和响应封装，service写业务逻辑，mapper对应SQL。common里放统一返回结果、异常处理、JWT工具类。

统一返回结构用最经典的Result类：

public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> r = new Result<>(); r.code = 200; r.message = "success"; r.data = data; return r; } public static <T> Result<T> error(String message) { Result<T> r = new Result<>(); r.code = 500; r.message = message; return r; } }

前端axios拦截器看到code不是200就统一弹出错误消息，不用每个接口都写错误处理逻辑。

4.2 JWT登录鉴权的实现

登录流程比较老套但实用：用户提交账号密码，后端校验通过后生成JWT返回，前端存到localStorage，每次请求由axios拦截器把token加到请求头。后端用一个拦截器解析token，把用户信息放进ThreadLocal，业务代码里直接取当前用户。

JWT依赖选用jjwt 0.11系列，版本兼容性比较好：

Key key = Keys.hmacShaKeyFor(SECRET_KEY.getBytes(StandardCharsets.UTF_8)); String token = Jwts.builder() .setSubject(String.valueOf(user.getId())) .claim("role", user.getRole()) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + 2 * 60 * 60 * 1000)) .signWith(key, SignatureAlgorithm.HS256) .compact();

SECRET_KEY不能写得太短，至少32个字符。我在拦截器里解析token后，还要手动判断用户状态是否正常，防止被禁用的人继续用旧token访问。

4.3 选课接口的事务串联

学生点击选课，后端服务实际做的事情比想象中多：校验角色是学生、检查选课轮次是否开放、检查教学班是否存在并且审核通过、检查是否已经选过同一教学班、检查时间是否冲突、检查学分是否超限、更新selected_count、插入选课记录。这串动作必须放在一个事务里，任何一个环节报错都回滚到最初状态。

@Transactional(rollbackFor = Exception.class) public void selectCourse(Long studentId, Long scheduleId) { CourseSchedule schedule = scheduleMapper.selectById(scheduleId); if (schedule == null || schedule.getStatus() != 1) { throw new BizException("教学班不存在或未开放"); } // 检查是否重复选课 int count = studentCourseMapper.countByStudentAndSchedule(studentId, scheduleId); if (count > 0) { throw new BizException("你已经选过这门课"); } // 检查时间冲突 List<CourseSchedule> selectedSchedules = studentCourseMapper.selectSchedulesByStudent(studentId); boolean conflict = selectedSchedules.stream().anyMatch(s -> s.getWeekday().equals(schedule.getWeekday()) && s.getStartSection() <= schedule.getEndSection() && schedule.getStartSection() <= s.getEndSection() ); if (conflict) { throw new BizException("上课时间与其他课程冲突"); } // 容量判断：条件更新 int rows = scheduleMapper.updateSelectedCount(scheduleId); if (rows == 0) { throw new BizException("课程已选满"); } studentCourseMapper.insert(studentId, scheduleId); }

这段代码的关键在于容量判断。调用这行更新语句：

UPDATE course_schedule SET selected_count = selected_count + 1 WHERE id = #{scheduleId} AND selected_count < capacity

如果返回的影响行数是0，说明名额已经满。这里其实不是传统意义的乐观锁，它依靠数据库行锁和where条件共同保证不会超卖。同一时间多个事务更新同一行时，InnoDB会给这行加锁，后面的更新要等前面的提交后才执行，所以最终会把容量用尽但绝不会超卖。

4.4 防止超选的三种方案对比

防超选是选课系统最核心的技术问题，我梳理过三种方案：

我最终选择条件更新，因为它的实现成本和复杂度最低，压测结果在几百并发下完全够用。如果真要做全校抢课，再升级到Redis预扣也不迟。

4.5 ThreadLocal的正确清理

用户信息放进ThreadLocal之后，有个非常经典的坑：项目使用线程池处理请求时，线程是复用的。如果不清理ThreadLocal，下一个请求可能拿到上一个请求的用户信息，造成“串号”问题，严重点就是学生A退课结果操作的是学生B的账号。

我一直在拦截器的afterCompletion方法里做清理：

@Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { UserContext.clear(); }

这个细节我在代码审查时发现很多初学者会忽略，但它实际上是个线上事故级别的隐患。

5. 前端Vue侧实现：页面组件、请求封装与权限控制

5.1 页面与组件的划分思路

前端开发我习惯先画页面再拆组件。学生端的核心页面是课程列表页、我的课表页、成绩页；教师端是课程管理页、成绩录入页；管理端是审核页、学生管理页。共用部分比如课程信息卡片、分页组件、状态标签都抽成公共组件。

路由使用懒加载，按需加载页面组件，减小首屏体积：

const router = createRouter({ history: createWebHashHistory(), routes: [ { path: '/course-list', component: () => import('@/views/student/CourseList.vue') } ] })

注意我这里用的是hash模式，而不是history模式。hash模式在部署时不需要额外的Nginx配置，刷新也不会404。如果非要用history模式让链接更好看，就必须在Nginx里配置try_files，这部分后面部署章节会讲。

5.2 axios封装与请求拦截

所有请求都统一走封装好的request实例，好处是拦截器里可以统一处理token注入和错误提示。开发环境下baseURL配置成/api，通过Vite代理转发到后端，生产环境由Nginx做反向代理，前端代码不用区分环境。

import axios from 'axios' const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = 'Bearer ' + token } return config }) request.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.message) return Promise.reject(new Error(res.message)) } return res.data }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') router.push('/login') } ElMessage.error('网络异常，请稍后重试') return Promise.reject(error) } )

5.3 路由守卫与菜单权限

前端权限控制的核心思路是：根据登录返回的role字段，渲染不同的菜单，并在路由守卫里拦截无权访问的页面。

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.path === '/login') { next() return } if (!token) { next('/login') return } const role = localStorage.getItem('role') if (to.meta.roles && !to.meta.roles.includes(role)) { next('/403') return } next() })

这里有一个经验之谈：菜单权限在前端做就够了，不要做成后端动态下发的复杂方案。这个项目里前端写死三套菜单，根据角色切换，最简单也最可靠。后端的接口层仍然要校验角色，双保险，前端权限只是体验层面的控制，真正的安全边界在后端。

5.4 选课按钮的交互细节

选课页面最容易出现的交互问题就是按钮状态和数据库不一致。我最开始图省事，在localStorage里记录已选课程，结果换个浏览器或者换台电脑就显示错乱。

后来改成进入课程列表页时重新拉取“我的选课记录”，再结合课程容量和选课轮次这三个数据共同决定按钮状态。具体逻辑是：已经选过的显示“已选”并禁用；容量已满显示“已满”并禁用；选课轮次未开放显示“未开始”；正常情况显示“选课”。这个逻辑看起来简单，但三种状态叠加在一起时，前端必须有一个统一的状态计算方法，否则很容易出现“短时间内重复点击导致重复提交”的问题。

5.5 跨域问题的两种处理方式

开发环境用Vite代理：

export default defineConfig({ server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } })

生产环境用Nginx反向代理。这两种方式统一的效果是：前端代码里请求的都是相对路径，避免了浏览器层面的跨域。生产环境配置后面讲部署时再展开。

6. 从本地到服务器：一次完整的部署实战记录

6.1 环境准备与版本匹配

部署我建议直接用纯净的Linux服务器。需要安装JDK、MySQL、Nginx。版本选择上有个容易踩的坑：SpringBoot 2.x对应javax.servlet包，SpringBoot 3.x对应jakarta.servlet包，代码里的导入路径不一样。

我这次项目用的是SpringBoot 2.7.18，JDK用8，因为兼容性最好，网上资料最多。如果用SpringBoot 3就不要照抄2.x的代码了。MySQL用8.0，驱动是com.mysql.cj.jdbc.Driver，mybatis-spring-boot-starter版本用2.3.1，这些都是稳定组合。

6.2 后端打包与进程管理

本地执行：

mvn clean package -DskipTests

生成的jar在target目录下。上传到服务器的/app目录后，用nohup启动是最简单的方案，但更好的做法是用systemd管理进程，这样进程崩溃后会自动拉起：

[Unit] Description=Course Select System After=network.target [Service] ExecStart=/usr/bin/java -jar /app/course-system-0.0.1-SNAPSHOT.jar --spring.profiles.active=prod Restart=always RestartSec=5 [Install] WantedBy=multi-user.target

配置文件application-prod.yml里放生产环境的数据库连接信息，不要放在代码仓库里，单独编辑。

6.3 前端构建与静态资源托管

前端构建命令：

npm run build

生成dist文件夹，上传到服务器后，我习惯放在/usr/share/nginx/html/course目录。如果部署在域名根路径下，Vite的base配置保持默认的/就行；如果部署在子路径，比如/course，就要把base改成/course/，否则静态资源会404。

Nginx配置如下：

server { listen 80; server_name yourdomain.com; location / { root /usr/share/nginx/html/course; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

6.4 部署过程中值得记录的三个坑

第一个坑是proxy_pass的末尾斜杠。如果写成：

proxy_pass http://127.0.0.1:8080;

那么请求/api/course/list会被原样转发成/api/course/list，后端找不到这个路由，404。加上末尾斜杠写成http://127.0.0.1:8080/后，/api前缀会被替换掉，转发成/course/list，这就是后端Controller里RequestMapping的路径。这个细节我排查了很久。

第二个坑是Vue Router history模式刷新404。如果路由用的是history模式，用户点击进入某页后刷新，Nginx会拿着这个路径去文件系统找，找不到就返回404。try_files配置就是为了解决这个：找不到对应的实际文件时，统一回退到index.html，由前端路由接管。

第三个坑是MySQL时区。连接串一定要加上serverTimezone=Asia/Shanghai，否则Java连接MySQL 8时可能会出现时间偏移八小时的问题。同样，创建数据库时要指定utf8mb4字符集，不然中文容易乱码。

6.5 上线后的基础检查清单

部署完成后，我按照一个固定顺序做检查：先访问后端健康检查接口，确认进程和数据库连接正常；再访问前端首页，确认静态资源加载没有404；接着登录一个测试账号，确认JWT签发和校验链路通畅；最后选一门课，确认数据库里选课记录和容量字段同步变化。这一套流程跑完，系统才算真正上线。

7. 并发压测结果与那些让我意外的细节

7.1 为什么要对选课接口做压测

整个项目写完后，我最不放心的一件事就是选课接口在并发情况下到底会不会超卖。平时浏览器里点来点去都是单请求，看不出问题。我决定用JMeter做一个简单压测，把并发问题提前暴露出来。

测试场景很简单：模拟1500个学生账号同时对同一门容量为300的课程发起选课请求。这个场景相当于真实选课时大家同时抢同一门热门课，是最极限的状态。

7.2 测试结果

最终结果让我松了一口气：数据库里的选课记录恰好300条，失败请求全部返回“课程已选满”的提示，没有出现一条超卖记录。平均响应时间在450毫秒左右，数据库CPU负载在60%附近，对于课程设计项目来说这个表现已经足够。

这个结果的关键其实就两处：一是update语句的where条件在数据库层挡掉了超卖，二是student_course表上的唯一约束挡掉了重复选课。如果你把这两层去掉，单纯在应用层做判断，压测时大概率会出现库存超卖和重复选课。这是我在这个项目里最想分享的一句话：数据库的约束和事务边界，才是数据安全的最后一道防线。

7.3 并发压测暴露出来的连接池问题

压测还暴露了一个课堂之外学不到的问题：数据库连接池默认配置下，长时间空闲后连接会失效，压测一开始出现了大量的“Connection is not available, request timed out”报错。原因是连接池把空闲连接回收了，但应用不知道连接已断开，拿到失效连接后报错。

解决方案是在HikariCP配置里加上：

spring: datasource: hikari: minimum-idle: 5 maximum-pool-size: 20 connection-test-query: SELECT 1 idle-timeout: 60000

minimum-idle保证至少保留5个空闲连接，connection-test-query让连接池每次拿出来之前先测活性。这个问题在低并发开发环境几乎不会暴露，但真实部署后很快就会被遇到。

7.4 如果并发再往上走该怎么办

坦白说，这套方案的天花板是存在的。如果要做数千甚至上万人的同时抢课，单体数据库的更新操作会成为瓶颈，接口入口限流、Redis预扣库存、异步写入选课流水这些架构手段就需要上了。但对这个项目标题描述的场景——大学生选修选课系统课程设计或毕业设计——当前方案已经堆满了亮点：事务、并发控制、唯一约束、安全鉴权，每一个点都值得在答辩时展开讲。

我个人的体会是，做完这个项目最大的收获不是会写几个接口，而是理解了“数据一致性靠什么保证”这件事。从需求分析到数据库建模，从接口事务到并发压测，再到部署上线的Nginx配置和连接池调优，这条路走一遍之后，再看到类似的业务系统，你会很清楚它的数据是怎么流转的，瓶颈会出现在哪里。最后分享一个小建议：如果你也在做同样的系统，一定要在开发早期就把数据库唯一约束加上，把事务边界划清楚，不要等项目写完再回头补。这两件事做扎实了，选课系统最核心的部分就稳了。