企业官网建设流程全解析

1. 项目整体设计与技术选型拆解

做选课系统这类管理信息系统，最怕的就是“为了技术而技术”。我见过不少项目上来就整微服务、分布式、消息队列，结果一个几百人同时用的选课系统，光是部署和运维就压垮了团队。这个基于 Spring Boot 的学生选课系统，走的是务实路线：单体应用 + 分层架构 + Spring Security 权限控制 + MySQL 事务管理，这套组合拳打下来，正好覆盖了毕业设计、课程设计和中小型教务场景的绝大多数需求。

先说说为什么选 Spring Boot 而不是其他框架。Servlet 时代写 MVC 的繁琐程度，用过的都懂——web.xml、spring-mvc.xml、数据源配置、扫描配置，每一样都要手动粘，稍微配错一个<url-pattern>整站就歇菜。Spring Boot 把这些全自动化了，内嵌 Tomcat 直接把 WAR 包部署那套流程砍成 “java -jar 启动”。对学生项目来说，你不需要理解底层 Servlet 容器怎么初始化，只要有 JDK 和 Maven 就能把项目跑起来，这本身就是最大的生产力。再者，Spring Boot 和 Spring Security、Spring Data JPA 同属一个生态，集成成本极低，对选课系统这种强权限、强事务的业务来说，这套组合的稳定性是经过无数生产环境验证过的。

再拆一下项目的核心模块。选课系统的业务边界其实很清晰，无非是：用户认证与权限、课程与选课管理、成绩与退课机制、还有最容易被忽略的数据统计。这个项目的模块划分也比较常规但合理，package 结构大致是：

• controller：接收前端请求，转发给 service 层
• service：承载核心业务逻辑，比如选课、退课、防冲突校验
• repository：数据库访问层，负责实体与表的映射
• entity：数据库表对应的实体类
• config：安全配置、跨域配置

这种分层的好处在于，每一层职责单一，出了问题你知道去哪个包里找代码，而不是两眼一抹黑地把整个项目翻个底朝天。对于后续要扩展功能的同学，比如想加一个“限选学分统计”，只需要在 service 里加一个方法，controller 暴露一个接口，完全不用动其他层的代码。

2. 数据库设计：核心实体与表结构

数据库是选课系统最不能糊弄的部分。很多同学做项目习惯先写代码，等发现数据没法存了再回过来补表，结果就是字段七零八落、外键全凭自觉、查询全靠 “select *”。我自己的经验是，项目开始第一步就把 ER 图画清楚，后面所有代码都是顺着表结构走的，效率反而最高。

这个选课系统里，核心实体就四个：用户（User）、角色（Role）、课程（Course）、选课记录（Selection）。用户和角色是多对多关系，课程和选课记录是一对多关系。实际表设计比理论更细一些，我把关键的几张表结构拆开讲：

2.1 用户表与角色表

用户表字段大概为id, username, password, real_name, email, created_time，密码存储不搞明文，用 BCrypt 加密，这是 Spring Security 内置的密码加密器，散列强度可配，防彩虹表攻击够用。角色表就是id, role_name, description，常见的角色有三种：学生、教师、管理员。用户和角色用中间表user_role关联，字段就两个外键。

为什么要设计 RBAC（基于角色的访问控制）而不用简单的role字段？因为后期如果要加一个“教学秘书”角色，只审核课程而不负责成绩管理，用 RBAC 只需要在数据库里插一行角色记录，再配一下权限，不用改代码里到处散落的if (role.equals("teacher"))判断。

2.2 课程表与选课记录表

课程表的关键字段是：course_id, course_name, teacher_id, credit, capacity, selected_count, schedule_time, classroom。注意teacher_id作为外键关联用户表，教师本身也是用户，这样设计比单独建一张教师表更简洁。capacity和selected_count是两个关键数字，一个代表最大容量，一个代表当前已选人数，选课时就要拿这两个字段做约束。

选课记录表selection更简单：selection_id, student_id, course_id, select_time, status。status 字段我用它区分“正常选课”“退课中”“已退课”，而不是一退课就物理删除记录，这样后续如果要查学生的历史选课轨迹，数据还在，不会两眼抓瞎。

这里有个设计细节我没少被坑过：选课记录表一定要给(student_id, course_id)加唯一索引。为什么？因为并发情况下一个学生可能在两个请求里同时选同一门课，如果只靠业务代码判断，容易漏掉临界情况。数据库层面的唯一约束是最后一道保险，哪怕代码写错了，数据库也会拒绝重复选课，这比在代码里写十行 if 判断都管用。

2.3 视图与索引优化

后台管理页面常需要显示“每门课已选人数占容量的比例”，如果每次实时用 count 统计，数据一多就卡顿。我建议直接在课程表字段里维护selected_count，每次选课成功就 update 一次。这样做在单机事务下没问题，因为同一行事务串行，不会出现计数不一致。再配合几个高频查询字段建索引，比如user_role表的user_id和role_id，selection表的student_id，查询速度就完全够用了。

3. 后端核心功能与关键逻辑实现

学生选课系统的后端功能不算多，但每个功能都有值得品味的细节。我按认证授权、选课退课、并发处理、异常兜底这几个维度来拆解。

3.1 登录认证与权限控制

用 Spring Security 做认证和授权，配置一个WebSecurityConfigurerAdapter（新版本是SecurityFilterChain），核心就三块：哪些 URL 放行、哪些需要认证、角色对应哪些权限。

这个项目的 URL 规则大概是：

• /api/auth/login、/api/auth/register放行
• /api/student/**需要ROLE_STUDENT权限
• /api/teacher/**需要ROLE_TEACHER权限
• /api/admin/**需要ROLE_ADMIN权限

登录后把用户 ID 和角色塞进 JWT 里返回给前端，前端每次请求都带Authorization: Bearer xxx，后端过滤器解析 JWT、加载用户信息。这个过程听起来复杂，其实就是OncePerRequestFilter里几行代码的事。

我强烈建议在这个系统里引入 JWT 而不是沿用 Session 方案。原因很简单：前后端分离状态下，Session 跨域、跨端口是一堆麻烦事，JWT 天然无状态，后端不用存会话。唯一的坑是 JWT 过期时间策略，我设的是两小时，但选课高峰期用户可能挂机很久，如果 token 突然过期，正在选的课提交不了。解决方式是前端在收到 401 时尝试静默刷新 token，刷新接口用 refresh_token 换取新 access_token，这一套跟选课系统本身一样，非常经典。

3.2 选课与退课的完整流程

选课的 Controller 层代码每个人都会写，核心逻辑在 Service 层。我在原项目基础上补全了完整的执行轨迹，大致是：

1. 验证学生身份并检查课程是否存在
2. 检查当前时间是否在选课窗口内（这是很多项目漏掉的地方，不控制选课时间，学生半夜也能选，教务老师第二天看到一堆乱数据）
3. 判断该学生是否已选过这门课（查selection表，有记录且状态为正常就直接拒绝）
4. 判断课程是否已满员（比较selected_count和capacity）
5. 校验先修课程（如果课程表有 prerequisite 字段）
6. 更新selected_count+1
7. 插入选课记录，状态设为正常
8. 提交事务，返回选课成功

这 8 步缺一不可。很多同学做到第 4 步就觉得“完美”，但先修课程和时间窗口其实是教务系统最核心的约束，少了它们，你这个系统就只是个“课表记录器”，不是“选课系统”。

退课的逻辑是选课的逆过程，唯一要注意的是状态机：只有状态为“正常”的记录才能退课，退课后状态改为“已退课”，同时selected_count-1，并且把释放出来的名额让给正在等待的学生——这部分如果做“候补排队”功能就更漂亮了，简单实现是用一个waitlist表记录待选学生，退课成功时取出下一位自动选上。

3.3 并发场景下的防超卖处理

这里绝对是选课系统最核心的考点。假如有容量为 100 的课程，120 个学生同时提交，如果你不做并发控制，selected_count最终可能会冲到 120，这就是典型的超卖问题。解决办法有几种，我对这个项目的定位是单体应用，所以优先用数据库的乐观锁方案：

在课程表里加一个版本号字段version，更新的 SQL 改成：

UPDATE course SET selected_count = selected_count + 1, version = version + 1 WHERE id = #{id} AND version = #{oldVersion}

如果执行后受影响行数为 0，说明版本号变了（说明有其他请求更新过），这时直接抛出“课程已满或已更新，请刷新页面重试”的提示即可。这个方案的好处是读操作不用加锁，并发性能比select ... for update好得多，代码也不复杂。

如果后续系统平滑升级到微服务架构，单纯乐观锁就不够用了，需要配套 Redis 分布式锁或者按课程维度加 Redisson 锁。但那是后话，对单体 Spring Boot 系统来说，数据库级别就已经是财务级的可靠了，不需要过度设计。

3.4 异常处理与统一返回结构

一个完整的后端接口不应该让异常裸奔到前端，尤其是 MySQL 唯一索引冲突这样的异常，直接返回500 Internal Server Error会让前端手足无措。我在项目里加了一个全局异常处理器@RestControllerAdvice，捕获业务异常和未知异常，统一封装返回值：

{ "code": 40001, "message": "选课冲突：该课程名额已满", "data": null }

前端拿到 code 就直接弹出 message，不用解析 Java 堆栈。同时单独处理查不到记录的情况，比如学生访问权限外的课程详情，返回 403 而不是带着空对象一路 null 下去。

4. 前端页面与交互实现

这个选课系统虽然主打后端技术栈，但前端也不能糊弄。原项目用的是 Vue + Element UI 的经典组合，页面不多但逻辑清晰。

4.1 核心页面清单

• 登录/注册页：提交到后端 JWT 登录接口，拿到 token 后存到 localStorage
• 学生首页：展示可选课程列表，支持按课程名、教师、学分筛选，一键选课按钮
• 我的课表：展示已选课程，按星期几、第几节课渲染成课表样式
• 教师工作台：发布课程、查看选课名单，手动移除异常选课记录
• 管理后台：管理用户与角色、审核课程、查看全系统选课统计

每个页面都调对应的后端 API，路由登录守卫统一拦截，未登录跳转到登录页。页面组件的代码不多，但是交互细节要比代码量更值得品味。

4.2 选课交互优化与防重提交

学生点击“选课”按钮后，前端应该立即禁用按钮并显示 loading 效果，后端响应后再恢复按钮。这不仅能提升交互体验，还能极大降低重复提交的概率。如果不加这个处理，学生手快双击一下，就可能触发两笔选课请求，哪怕后端有唯一索引兜底，前端也要先把这种低级的误操作挡掉。

课表渲染方面，用 Element UI 的el-table是最快的方案，但要做课表样式，用纯 table 就比较吃力。我改用的方案是 flexbox 网格布局，把一天的 12 节课做成 12 行，一周 7 天做成 7 列，已选课程按节次坐标直接落到对应的格子中，冲突的课程（同一时间不同教室）直接标红提示。这个 UI 细节做出来，整个系统给人的专业感立马不一样。

4.3 权限与菜单动态化

前端路由和后端权限是联动的。比如一个账户同时具备学生和教师角色，他登录后应该既看到“选课中心”又看到“我的授课”。这个系统直接把后端返回的角色列表映射成可访问路由表，动态渲染侧边栏菜单。实现方式是在路由配置里用meta.roles标记角色，然后通过 Vue Router 的router.beforeEach做跳转过滤。

这个设计有一个非常实用的小点：如果你只想给学生开放选课系统、不开放管理后台，你不需要注释任何代码，只要在数据库里不给该学生分配 admin 角色，菜单就不会显示。这就是 RBAC 的价值——安全是在数据层就锁死的，而不是靠写死在前端界面上的 iframe。

5. 常见问题与排查技巧实录

开发这类选课系统，踩坑是常态。我把自己实际遇到过的问题整理成一个速查表，按症状、原因、解法三个维度列出来，希望能帮你省下几个晚上的排查时间。

5.1 事务不生效：最容易忽略的自调用陷阱

@Transactional是 Spring AOP 代理实现的，它只能拦截通过代理对象外部进入的方法调用。如果你在一个类的methodA内部直接调用同一个类的methodB，而methodB加了事务注解，那么事务是不会生效的。这属于新手极容易踩的坑。

我见过的写法是：

public void doSelection(Long studentId, Long courseId) { checkCapacity(courseId); insertSelection(studentId, courseId); updateCourseCount(courseId); }

且不说方法拆得合理不合理，这类代码一旦并发起来，就会出大问题：如果insertSelection成功但updateCourseCount失败，两笔操作不在同一事务里，数据库里就留下一条“选课成功但课程人数没加”的脏数据。解决办法是：把整个流程放进一个服务方法里整体加@Transactional，或者把步骤拆到不同 Service 里调用（因为不同 Service 互相注入的是代理对象，事务能生效）。

5.2 密码加密与初始化数据

项目启动时通常要初始化管理员账号，如果直接在数据库 sql 文件里写死明文密码，那安全等级直接为负。正确姿势是在CommandLineRunner里调用PasswordEncoder.encode生成密码后插入，或者把 encode 后的 hash 值写好放在 SQL 里。

我自己调试时常用的命令是：

mvn spring-boot:run -Dspring-boot.run.arguments="--init.admin.password=temp12345"

这样初始密码不需要写死在代码或数据库里，部署环境可以自己指定，更安全灵活。

5.3 数据统计报表的 N+1 查询优化

课程列表接口往往要返回每个课程的已选人数。如果实现写法是“先查出课程列表，再遍历每门课调用 count”，恭喜你，恭喜你获得了一个 N+1 查询的经典案例。课程数据一多，数据库就会被砸到怀疑人生。

优化方案是两条路：

• 在课程表加冗余字段selected_count，每次选课/退课事务里更新它。查询的时候直接查字段，完全不碰子查询。
• 如果非要实时计算，用一条 group by 查询把所有课程的已选人数一次拿出来，再在内存里做映射组装，而不是一层层发 SQL。

冗余字段的方式我强烈推荐在这个项目里采用，因为对于这种高并发读写的小系统，收益是最明显的：写多一笔更新，但读少几百次查询，总体吞吐量明显提升。

5.4 系统上线前的数据配置技巧

正式部署时，我把数据库连接、Redis 地址、JWT 密钥都放到了application-prod.yml，通过环境变量传参。比如：

spring: datasource: url: ${DB_URL} username: ${DB_USERNAME} password: ${DB_PASSWORD}

这样本地调试用 application-dev.yml，部署测试用 application-prod.yml，代码仓库里不会泄露生产环境的密码。这个习惯对未来进公司做项目是直接受益的——不是会写增删改查就叫会开发，工程化意识从配置文件分离开始培养。

6. 如何基于这份源码快速进行二次开发

这个选课系统源码拿到手，我觉得最合理的阅读顺序是：先跑起来，再画 ER 图，再读 controller 到 service 的调用链，最后动手改一个功能。跑起来很简单，本地装好 JDK 11、MySQL 8.0、Maven 3.6+，执行：

mvn clean package -DskipTests java -jar target/student-course-system-1.0.0.jar

如果你想二次开发一个典型的“自动选课”需求，比如达到某个 GPA 后才能选某类课，流程是：

1. 在Student实体里加一个字段gpa
2. 在Course实体里加一个min_gpa字段
3. 在选课校验里加一段：

if (student.getGpa() == null || student.getGpa().compareTo(course.getMinGpa()) < 0) { throw new BizException(40010, "GPA 未达到该课程要求，不能选课"); }

这一步就能让系统从“通用占座系统”升级成“有业务规则的教务系统”。类似的规则还可以加：每学期限选学分、互斥课程组、先修课未通过禁止选课。每加一个规则，就对应一个字段 + 一个 if 判断 + 一个错误提示，本质上没有任何高深的东西，关键是有没有完整的数据模型支撑。

数据库文档里自带了初始 SQL 和部分测试数据，方便你直接体验整个流程。如果你要把它改造成某个高校的真实项目，只要把初始数据清空，重新导入真实课程与班级数据，把登录认证对接上统一身份认证中心（CAS/OAuth2）就行。

7. 个人经验分享：选课系统项目的几个加分项

最后聊几个我做这类项目时积累的经验，拿出来就能用的小技巧。

第一个加分项：在项目中使用 Flyway 管理数据库脚本。很多同学交付项目时给的是一个 create.sql，这种文件一旦改了就不可追溯。Flyway 的 sql 脚本有版本号，启动时自动执行未迁移的脚本，团队里任何一个人改了表结构，其他人拉代码后重启就能把库更新到最新状态，不用再到处找“我的建表语句发群里了”。这对选课系统这种长期迭代的项目极其适用。

第二个加分项：提供一个“模拟选课批量注册”的工具类。之前我在开发阶段被数据录入折磨过无数次，后来写了一个简单的DataInitializer，启动时自动生成 100 个测试学生账号和 50 门课程，角色随机分配，密码统一是初始密码。这样每一次重启后系统都有完整可测的数据，不用手动造测试数据，调试选课并发、时间窗口判断这些功能快得多。

第三个加分项：给所有接口添加简单的操作日志。用 AOP 切面拦一下 controller，记录用户 ID、操作类型、耗时，存到operation_log表。这个功能对教务管理员来说很有用——有人半夜批量退课？一查日志就知道是谁。

做学生选课系统，技术上其实没什么不可逾越的难关，真正考验人的是思路和细节。把业务规则理清、数据模型设计合理、并发控制到位、异常处理完备，这个东西自然就立住了。希望这篇文章能让你少走一些弯路。