企业官网建设流程全解析

本子，也就是毕业设计，最怕的不是不会写代码，而是不知道这个系统到底在解决什么问题。所谓“程序设计在线学习平台”，听起来像把慕课搬到网上，但真正做起来你会发现，它要解决的核心矛盾有三个：一是学生自学没人管，二是老师布置练习缺乏自动批改手段，三是学习过程没有数据可追踪。这三个痛点拆透了，系统要做成什么样，心里就有底了。再配合Spring Boot这个比传统SSH清爽太多、生态又成熟的框架，整个工期可以控制在两到三个月内，这也是为什么我在带学生做毕设时特别推荐这个选题。

这篇内容就围绕这个系统的完整开发过程来写，覆盖需求拆解、技术选型、数据库设计、核心业务实现、自动判题方案和真实的踩坑记录。不管是准备做这个题目的在校生，还是想系统梳理Spring Boot项目落地经验的开发者，都能从中直接拿走上手。

1. 选定这个项目的理由：它踩准了哪些真实需求

先别急着打开IDE，把需求想清楚，后面能少走一半弯路。

1.1 学习者的真实困境催生的产品逻辑

所谓程序设计在线学习平台，服务对象通常是三拨人：学生、教师、系统管理员。学生要的是“能学、能练、能收到反馈”，教师要的是“好布置、好批改、好统计”，管理员要的是“用户能管、内容能审、日志能看”。这三类角色其实映射出一个普遍存在的场景：非全日制学生、跨专业转码的初学者，很难获得体系化的训练机会。而传统教学里，老师心力有限，几百份作业不可能逐行点评。

所以这个平台的设计逻辑不是“录播课播放器”，而是“自学-练习-检验”的闭环。就拿程序设计这类课程来说，纯看视频最容易产生“眼会了手废了”的状态，于是我在项目里把视频讲解、课件文档、代码示例、在线编程题四个学习载体组合到一起，学生每学完一小节，就要做几道练习题。练习题系统自动判，判完立刻给反馈，学生改完提交再判。这个闭环一旦跑通，老师的负担会大幅降低，学生的学习效率也会明显提升。

1.2 为什么Spring Boot是比SSM、Django更合适的选择

很多学校的毕设选题列表里，最后实现的框架五花八门。从我这几年带项目的经验来看，Spring Boot在毕设场景里有几个不可替代的优势。

第一，配置极简。SSM时代光是一个Spring配置文件、MyBatis映射配置、事务配置就能折腾掉三到五天，Spring Boot通过自动配置把大部分工作收敛成了application.yml里的几行参数。第二，社区生态成熟。像MyBatis-Plus、Spring Security、Redis、WebSocket这些常用组件，都有非常丰富的中文文档和现成Demo，遇到问题基本一搜就有答案。第三，部署友好。打一个可执行Jar包就能跑，对毕设演示和写“系统运行演示”文档来说非常方便。

如果你非要问“那用Django或者Node.js行不行”，当然行，但考虑到毕设答辩时的技术要求深度、文献丰富度以及指导老师的熟悉度，Spring Boot确实是最不容易出幺蛾子的牌。特别是热搜词里“Spring Boot 2.3.x 2.6.x”这种版本差异问题，选择成熟稳定的2.7.x或者直接用3.x，认准官方维护的版本停靠点，能避免大量环境层面的麻烦。

2. 技术选型与工程骨架搭建

这一节把整个后端工程的成长期讲清楚，从目录结构到核心依赖，直接照着搭即可。

2.1 核心依赖的确定与版本注意事项

我一般建议用Maven管理项目，JDK版本根据Spring Boot版本去选。如果用的是Spring Boot 2.7.x，JDK 8或者11都跑得很稳；如果决定上Spring Boot 3.x，那JDK必须17起步。对于毕设场景，我推荐Spring Boot 2.7.x配JDK 8/11的组合，理由很简单：兼容性最好，网上能搜到的踩坑记录最多，即便遇到奇葩问题也大概率有人替你趟过。

核心依赖清单如下：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> </parent> <dependencies> <!-- WEB 层 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- 权限认证 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency> <!-- 持久层框架 --> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <!-- MySQL 驱动 --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <!-- Redis：缓存与分布式会话 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <!-- WebSocket：在线讨论与课堂互动 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-websocket</artifactId> </dependency> <!-- JWT 令牌 --> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.1</version> </dependency> <!-- 常用工具类 --> <dependency> <groupId>cn.hutool</groupId> <artifactId>hutool-all</artifactId> <version>5.8.20</version> </dependency> <!-- Lombok，减少样板代码 --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>

有几个网上讨论比较多的坑值得提前说。第一，jjwt的0.9.x版本依赖JAXB，JDK 9以后要手动引入jaxb-api，不然生成Token的时候会直接抛ClassNotFoundException；解决方法是加一行<dependency>javax.xml.bind:jaxb-api:2.3.1</dependency>，或者干脆换用io.jsonwebtoken:jjwt-api:0.11.5配合jjwt-impl和jjwt-jackson。第二，MyBatis-Plus的3.5.x版本与Spring Boot 3.x搭配时要使用mybatis-plus-spring-boot3-starter这个新坐标，很多人在这里撞了墙。

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/coding_learn?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 database: 0 servlet: multipart: max-file-size: 50MB max-request-size: 100MB mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0 jwt: secret: your-secret-key-please-change-in-production expire: 86400000

这里有两个设计要点。逻辑删除字段是很多项目里被我反复强调的：用户表、课程表这类核心数据，千万别物理删除，否则后续统计、关联查询都会有历史数据缺失的麻烦。deleted字段配好后，MyBatis-Plus所有查询都会自动追加WHERE deleted = 0，逻辑上的“删”只是一个更新操作。另外，secret不要写死在代码里，放到配置文件里，答辩时你可以理直气壮地说“这是密钥外置设计，避免源码泄露直接暴露签名密钥”。

2.2 工程目录结构与模块划分经验

Spring Boot工程怎么做分包，直接决定后期血压。常见的错误是把所有Controller堆在controller包里，Service不分层，后面牵一发动全身。这里给出一个我实测很顺手的结构：

com.example.codinglearn ├── CodingLearnApplication.java ├── config │ ├── WebMvcConfig.java // 拦截器注册、静态资源映射 │ ├── SecurityConfig.java // Spring Security 配置 │ ├── WebSocketConfig.java // WebSocket 端点注册 │ └── RedisConfig.java ├── common │ ├── Result.java // 统一响应体 │ ├── ResultCode.java // 状态码枚举 │ ├── BusinessException.java // 自定义业务异常 │ └── GlobalExceptionHandler.java // 全局异常拦截 ├── interceptor │ └── JwtInterceptor.java ├── entity │ ├── User.java │ ├── Course.java │ ├── Chapter.java │ ├── Lesson.java │ ├── Question.java │ └── Submission.java ├── mapper │ ├── UserMapper.java │ ├── CourseMapper.java │ └── ...... ├── service │ ├── UserService.java │ ├── CourseService.java │ └── impl │ ├── UserServiceImpl.java │ └── ...... ├── controller │ ├── AuthController.java │ ├── CourseController.java │ ├── LessonController.java │ ├── JudgeController.java │ └── ...... └── dto ├── LoginDTO.java ├── RegisterDTO.java └── SubmissionDTO.java

很多初学Spring Boot的人会把Controller直接当成业务处理中心，把大量逻辑塞进去，这是大忌。Controller只负责收参数、调Service、返回Result，业务规则全部下沉到Service。这样做的直接收益是：你的Service可以被单元测试，拦截器、安全校验、事务控制都能干净地作用到Service层，万一后面要出接口文档，Controller的职责边界也会更清晰。

3. 把需求拆成看得见的功能：三类角色的权限与操作矩阵

毕设答辩时老师最爱问的问题之一就是“你的用户角色是怎么划分的，权限边界在哪”，这一节把这个讲透。

3.1 学生端、教师端、管理员端的功能闭环

我建议将平台按角色拆成三个独立的视角，每个视角对应一组可用操作。画用例图时也会特别清楚：

学生端很容易做成一堆CRUD，但建议一定要加入“学习轨迹”的概念。比如学生每看完一节课，后台记录一条学习记录；每做对一道题，更新一次知识点掌握度。这些细节做出来后，答辩时讲“数据的价值”就有材料可讲了，而不是只停留在“登录注册增删改查”的层面。

3.2 将“程序设计练习”落成可执行的规则引擎

“程序设计在线学习”最有技术看点的部分，不是视频播放，而是编程题的执行与判定。简单地说，系统要能接收学生提交的源代码，在服务器上编译运行，然后用预设的测试用例比对输出结果，最后返回“通过”或“不通过”，并附上错误信息。

这件事听着简单，实现起来有相当多细节。第一，编译运行必须设置时间限制和内存限制，避免死循环代码把服务器拖垮。第二，不能直接用Runtime.exec()执行用户代码后就算完事，标准输出、异常输出、退出码要分开捕获。第三，测试用例不能只跑一组，一般一个题目会内置5到10组输入输出对，跑完全部才算通过。

我在项目里采用的是“隔离执行”方案：每个提交任务由判题模块生成一个临时工作目录，写入源代码文件，执行编译指令，然后构造一个带超时控制的任务去跑测试用例。整个过程用Java的ProcessBuilder来实现，核心代码如下：

public JudgeResult runSingleTestCase(String sourceCode, String className, String input) { JudgeResult result = new JudgeResult(); // 1. 写入源文件 File workDir = new File(tempDir); File sourceFile = new File(workDir, className + ".java"); FileUtil.writeString(sourceCode, sourceFile, StandardCharsets.UTF_8); // 2. 编译 ProcessBuilder compilePb = new ProcessBuilder("javac", sourceFile.getAbsolutePath()); compilePb.directory(workDir); Process compileProcess = compilePb.start(); boolean compiled = compileProcess.waitFor(10, TimeUnit.SECONDS); if (!compiled || compileProcess.exitValue() != 0) { result.setStatus("COMPILE_ERROR"); result.setMessage(IOUtil.toString(compileProcess.getErrorStream(), StandardCharsets.UTF_8)); return result; } // 3. 运行，并设置超时 ProcessBuilder runPb = new ProcessBuilder("java", "-cp", workDir.getAbsolutePath(), className); runPb.directory(workDir); Process runProcess = runPb.start(); runProcess.getOutputStream().write(input.getBytes(StandardCharsets.UTF_8)); runProcess.getOutputStream().close(); if (!runProcess.waitFor(5, TimeUnit.SECONDS)) { runProcess.destroyForcibly(); result.setStatus("TIME_LIMIT_EXCEEDED"); return result; } String actualOutput = IOUtil.toString(runProcess.getInputStream(), StandardCharsets.UTF_8); // 4. 输出比对 if (actualOutput.trim().equals(expectedOutput.trim())) { result.setStatus("ACCEPTED"); } else { result.setStatus("WRONG_ANSWER"); } return result; }

这个方案的关键点是每一步都要设置超时，编译最长给10秒，运行最长给5秒。有同学问我：不用沙箱安全吗？说实话，在真实的生产系统里光靠ProcessBuilder做隔离是不够的，还需要容器或者更底层的系统调用隔离工具。但如果没有此类工具、又想让平台具备在线实践能力，一定要把风险控制在一个可控范围，即只允许在临时目录执行、限制资源使用上限、线程结束后清理临时目录。在毕设场景中这样做是可以解释得通的——不是不想上容器，而是在单机部署的限制下，用进程级隔离、超时控制和目录清理组合出一个“够用但不过度”的方案。答辩时你把这个取舍逻辑讲清楚，比单纯吹“我用了Docker”更有说服力。

4. 数据库模型设计：一张图看懂十二张表怎么串起来

数据库表设计的好坏，直接决定整个系统后期写Mapper的痛快程度。这个项目的核心表有十二张左右，我按业务域分三组来讲。

4.1 用户域与权限域：用户表、角色表、用户角色关联表

用户表设计时会纠结“要不要单独建角色表”。我的建议是建，因为角色的扩展性远远大于业务的变化速度。表结构不复杂，但有一个字段很容易被忽略：status。用户被封禁、注销、正常三种状态，这直接关系到登录逻辑里的校验顺序。

CREATE TABLE `user` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `username` VARCHAR(50) NOT NULL UNIQUE, `password` VARCHAR(100) NOT NULL, `nickname` VARCHAR(50) DEFAULT '', `email` VARCHAR(100), `avatar` VARCHAR(255), `role` TINYINT NOT NULL DEFAULT 0 COMMENT '0-学生 1-教师 2-管理员', `status` TINYINT NOT NULL DEFAULT 1 COMMENT '0-禁用 1-正常', `created_at` DATETIME DEFAULT CURRENT_TIMESTAMP, `updated_at` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `deleted` TINYINT DEFAULT 0 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

密码字段我用的BCrypt加密存储，登录校验时用BCryptPasswordEncoder.matches(rawPassword, encodedPassword)做比对，别再用MD5了。现在只要答辩提到密码存储，老师大概率会追问加密算法，能讲清BCrypt的盐机制、不可逆特性，是很明显的加分点。

4.2 课程域：课程、章节、课时、资源四层结构

课程内容的组织方式，基本可以照搬“慕课”模型：课程下面有章，章下面有时，时下面是资源。资源可以是视频、附件、富文本。表设计时注意“时”的排序字段，没有排序字段就会出现显示错乱。

还有一个容易被忽视的设计点：“章节解锁规则”。很多学习平台会让前面章节完成之后才能学下一章，这样能保证学习顺序。我设计了一个lesson_progress表，学生每完成一个课时记录一行，同时存completed标志位。教师端统计时直接用聚合查询，非常舒服。

CREATE TABLE `lesson_progress` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `user_id` BIGINT NOT NULL, `lesson_id` BIGINT NOT NULL, `completed` TINYINT DEFAULT 0, `last_position` INT DEFAULT 0 COMMENT '视频进度，秒', `finished_time` DATETIME, UNIQUE KEY `uk_user_lesson` (`user_id`, `lesson_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这个表设计的妙处在于unique key(user_id, lesson_id)，天然防止重复学习记录。学生重看视频时只更新last_position，不会产生杂数据。后面你要写“我的学习进度饼图”之类的统计接口，围绕这张表写SQL就行，非常顺手。

4.3 练习域：题目表、提交表、测试用例表

判题功能至少需要三张表。题目表存题干、难度、类型、输入输出示例；测试用例表存多组标准输入输出；提交表记录谁在什么时候提交了什么代码、判题结果如何。

这里有一个要提前想清楚的问题：题目表里的“参考答案”要不要存？我建议分开存。题目的输入输出示例是给学生看的，而标准测试用例是判题用的，两者不能混在一张表里。示例可以放进题干字段，测试用例放独立的表。这样教师端管理题库时逻辑清晰，判题服务执行时也只需要读测试用例表，不用捞出整个题目对象再做字符串解析。

5. 核心业务的实现细节：选课、学习解锁与自动判题

从设计到实现这里跨度最大，挑三个真正的“难点”详细说说。

5.1 选课与学习解锁的时序逻辑

选课操作只有一个动作，但它牵扯的事务不少：要把课程加入用户课程列表，要给该学生的所有课时生成初始进度记录，如果目标课程有前置门槛比如需要先完成某个基础课程，还要做资格校验。

这段逻辑用事务控制在Service层完成，伪代码如下：

@Transactional(rollbackFor = Exception.class) public void enrollCourse(Long userId, Long courseId) { Course course = courseMapper.selectById(courseId); if (course == null || course.getStatus() != 1) { throw new BusinessException("课程不存在或未上架"); } // 校验是否已选 Integer count = userCourseMapper.countByUserAndCourse(userId, courseId); if (count > 0) { throw new BusinessException("请勿重复选课"); } // 插入选课记录 UserCourse userCourse = new UserCourse(); userCourse.setUserId(userId); userCourse.setCourseId(courseId); userCourseMapper.insert(userCourse); // 初始化所有课时的学习记录 List<Lesson> lessons = lessonMapper.selectByCourseId(courseId); for (Lesson lesson : lessons) { lessonProgressMapper.insertIfAbsent(userId, lesson.getId()); } }

选课事务写完后，我建议顺手写一个“退课”接口，但退课时不要删除学习记录，只标记状态为退课。数据保留永远比删除有价值，这也是大数据与统计思维在毕设中的体现。

5.2 学习进度接口设计：接口越细，前端越好做

学习进度接口往往是老师和学生使用频率最高的接口，建议至少提供三个：获取课程总进度、获取课时详情、上报课时完成状态。上报完成状态这里有一个细节：判断完成的条件是什么？视频类课时可以按“播放进度超过90%”判定，文档类课时可以在页面底部放一个“我学完了”按钮。识别到客观条件无法统一判断时，可以设计两种完成机制并存，前端根据资源类型自己决定调用哪个接口。

5.3 判题服务与主业务解耦

判题是重IO、重CPU的操作，最好的方式是跟主业务拆开。不需要单独部署微服务，但至少在工程里把judge相关包完全独立，并通过一个异步任务机制去处理。我在项目里用Spring自带的@Async，把判题请求放到独立线程池，前端提交后立刻返回“判题中”，轮询结果接口拿到最终状态。

“提交题目”这个核心接口，我在实现过程中反复调了两版才稳定下来。一开始图省事，把判题逻辑直接同步写在JudgeController里，本地跑一个小样例就几秒，没觉得有问题。结果换了一台配置较弱的机器后，几个学生同时提交编程题，接口响应直接飙到十几秒，前端超时，把数据库连接池也拖垮了。后来把“接收提交”和“执行判题”拆开，接收后立刻记录提交状态为PENDING并返回，真实评测放进异步线程，进度靠Redis里的键实时刷新，才算稳下来。这算是这个项目里最值得讲的一段优化经历，也算一个经典的“看起来没问题，压测就露馅”的教训。

反馈结果的结构大致是：

{ "status": "ACCEPTED", "execTime": 128, "memory": 20480, "detail": [ { "caseNo": 1, "result": "ACCEPTED", "output": "...", "expected": "..." }, { "caseNo": 2, "result": "WRONG_ANSWER", "output": "...", "expected": "..." } ] }

测试用例逐条返回结果，比只给一个大状态要友好太多。学生能看到自己错在第几个用例，输出和期望输出对比一目了然。这也是我在用户反馈里收到好评最多的体验设计之一。

6. 工程中有必要重视的几个附加能力：WebSocket、扣减并发与接口安全

如果时间有富余，强烈建议给系统加上实时能力与安全加固，这会让项目在同类毕设中直接拉开一个档位。

6.1 WebSocket搭建课程讨论室

热搜词里关于Spring Boot集成WebSocket的yml配置被搜得很高频，这里直接给结论。Spring Boot的WebSocket有两种使用方式：直接使用@ServerEndpoint类，或者使用Spring封装的TextWebSocketHandler。我推荐后者，因为它天然绑定Spring容器，拦截器也能复用。

@Override public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) { registry.addHandler(chatHandler, "/ws/chat/{courseId}") .addInterceptors(new HttpSessionHandshakeInterceptor()) .setAllowedOrigins("*"); }

setAllowedOrigins("*")注意别在生产环境这样写，本地调试可以。WebSocket房间里发的聊天记录写入消息表，还是那句老话，聊天记录不能只靠内存，刷新页面谁还记得刚聊了什么。实时性是锦上添花，持久化才是保底。

6.2 解决“抢课”场景下的超卖问题

课程有名额限制时，并发选课会出现两个人同时选中最后一个名额的经典并发问题。有些课容量设定为40人，但高峰期会有上百个请求同时涌进来。解决办法也很直接：选课时对user_course表的唯一约束加一层兜底，另外在事务里对课程行做SELECT ... FOR UPDATE悲观锁，保证扣减名额的判断-改库过程是原子的。

@Mapper public interface CourseMapper { @Select("SELECT * FROM course WHERE id = #{courseId} FOR UPDATE") Course selectByIdForUpdate(Long courseId); }

在Service层做：

Course course = courseMapper.selectByIdForUpdate(courseId); if (course.getSelectedCount() >= course.getCapacity()) { throw new BusinessException("课程名额已满"); } course.setSelectedCount(course.getSelectedCount() + 1); courseMapper.updateById(course);

这套“先锁再查再改”的事务顺序，是数据库并发控制的正统做法。答辩时老师问“你怎么处理并发”，你能把行锁、事务边界讲清楚，基本就是压住了。

6.3 JWT拦截器与接口鉴权

登录成功后会生成一个Token，后续请求带着Authorization: Bearer <token>访问接口。JwtInterceptor里校验Token合法性、解析用户角色，再写入ThreadLocal或请求头供后续Service获取当前用户。

@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (!(handler instanceof HandlerMethod)) { return true; // 放行静态资源 } String token = request.getHeader("Authorization"); if (StrUtil.isBlank(token) || !token.startsWith("Bearer ")) { throw new BusinessException("未登录或登录已过期"); } Claims claims = JwtUtil.parseToken(token.replace("Bearer ", "")); request.setAttribute("currentUserId", claims.get("userId")); request.setAttribute("currentUserRole", claims.get("role")); return true; } }

拦截器注册时注意排除登录注册接口，以及在线判题的查询接口可能也要对未登录用户开放一部分。合理设定拦截规则，是接口安全的另一个镜头。

7. 从零到一跑通项目的真实经验、常见坑与调试技巧

前面讲的是“怎么做”，这一节单独列几个我实际做下来觉得最值得反复强调的坑，每个都是拿真实调试时间换来的。

7.1 数据库字符集与JSON格式化乱码问题

全表建库时一定要用utf8mb4，因为utf8在某些MySQL版本中无法存储emoji与特殊符号，标题里一个特殊符号把整条记录截断的事情我真遇到过。另一个坑是接口返回JSON时中文乱码，多半是因为Spring Boot内置的Jackson默认编码和响应头没有对齐，在application.yml中显式声明server.servlet.encoding.force: true并统一为UTF-8是最稳妥的。

7.2 IntelliJ IDEA社区版开发Spring Boot：完全可以但注意三处

很多学生用的IDEA是社区版，担心不能用Spring Initializr。这里明确说：社区版能正常开发Spring Boot项目，只是没有Spring插件内置的启动器面板。第一，创建Maven工程后手动加spring-boot-starter-parent和spring-boot-starter-web依赖即可。第二，社区版没有内置HTTP客户端工具，测试接口时用Postman或者直接在浏览器里访问GET请求即可，POST请求用Postman或者Apifox。第三，比如Lombok插件在社区版同样可用，在插件市场安装即可，不会因为社区版而受限。整体来说，IDEA社区版对Spring Boot开发的支持完全够用，关键是找对使用习惯。

7.3 判题模块最容易踩的隐形坑

这个必须单独讲，因为自动判题是整个平台技术上最亮眼但也最容易翻车的地方。

第一个坑是Windows开发环境下的路径处理与Linux部署不一致。Windows下File.separator是\，Linux下是/，写死了就会出现本地跑得好好的，部署到云服务器就各种找不到路径。解决方式是构造路径时统一用Paths.get()或File的separator拼接，别用"\\"字符串硬拼。

第二个坑是超时进程清理不彻底。Java的Process.waitFor(timeout)超时后，子进程可能还没死透，必须调用destroyForcibly()，否则会残留僵尸进程，慢慢耗尽系统资源。核心代码前面已经给出了，这里再强调一点：判题临时目录在用完后要整个递归删除，包括编译生成的class文件、用户写出的临时文件。

第三个坑是测试用例的数据格式。题目的输入可能由多行组成，判题比对时不能直接按“完全相同”的标准，必须做末尾换行符与空白的归一化处理。先trim()，再统一把\r\n换为\n，这样能把“格式不对但逻辑正确”的游戏冤枉率降到最低。

7.4 前端联调时的接口设计经验

前端很多时候是Vue或者React+后端分离的写法。接口设计上，统一响应体Result很关键，避免前端每次判断业务成功失败都要查不同字段。我的Result长这样：

@Data public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("success"); result.setData(data); return result; } public static <T> Result<T> fail(Integer code, String message) { Result<T> result = new Result<>(); result.setCode(code); result.setMessage(message); return result; } }

前端拿到任何响应，先看code是否为200，不是就直接弹message，不用在后端再拼装乱七八糟的报错信息。另外分页接口统一返回page、size、total、records四个字段，前端分页组件几乎零成本对接。

7.5 关于项目演示与答辩准备的额外提醒

系统做完了不等于万事大吉。在我看过的很多项目答辩中，代码水平差不多的两组，最终分数拉开差距的主要原因在于演示流程缜密不缜密。演示时一定要有一条“教学故事线”：注册一个学生账号，选一门课，看一节课，做一道题，一次错了再看提示，改正后通过，然后切教师账号看统计数据，最后切管理员封个用户。整个流程一气呵成，数据之间环环相扣，评委印象分会非常不一样。

还有一个细节：提前准备几个预置数据。演示前的数据库里必须有一套看起来“真实”的数据，比如有二十个学生、三门课程、每门课程下有评价和几百条代码提交记录。千万不要拿着空表上台，空表演示的效果会让所有功能失去说服力。

8. 项目的可扩展方向：从毕业设计走向真实平台的三个思路

如果做完基础的在线学习平台后还有余力，有超值的后续方向可以添加。

第一个方向是引入推荐算法。当题库积累到一定量后，可以根据学生的历史提交记录和正确率，推荐适配难度区间的题目。这个方向上不需要从零写协同过滤，先做一个“简单规则推荐”：老师设定规则“答对A类题超过5道，解锁B类题”，在现有表结构上增加规则配置表和推荐表即可落地。

第二个方向是接入在线评测系统更成熟的架构。前文提到判题隔离方案，受限于单机环境，属于“可演示但不够生产级”。如果想把平台做成真正可上线的产品，可以把判题服务抽离成独立服务，用Docker容器去做代码执行沙箱，每个提交任务启动一个短暂容器，从镜像层面隔离文件系统和进程网络。这个改造方向在新兴的编程教育公司中已经是非常标准的技术路线，值得在项目文档中写明“当前方案与生产级方案的差距及演进路径”。

第三个方向是内容质量的闭环。多数学习平台只注重“让学生学”，但不注重“课程好不好”。可以给课程增加评分、点评、投诉举报机制，教师端根据评价反馈修改课程内容。学生学完一门课之后可以给课程打星，平台管理员定期下架低分课程，形成内容生态自净机制。

我自己的体会是，做这类系统最忌讳的就是把自己定位成“写CRUD的”，而是要想清楚每个功能点解决的是教学过程中的哪个具体问题。哪怕只是一个小小的一键导出班级成绩功功能，背后也是“教师不想花时间汇总Excel”的痛点。抱着这个思路去做设计和写代码，你的项目答辩材料自然会比旁人厚实很多。

如果时间允许，建议项目的开发节奏做一个倒排期：第一周把数据库建好，第二周把用户认证打通，第三周到第四周完成课程学习主链路，第五周做判题模块，第六周转入接口联调和测试，预留一周打答辩素材与预演演示流程。写作这一步，技术实现前一定要留出花几个晚上把毕设论文里的需求分析、MySQL表结构图、核心时序图画清楚的时间——这些图不只是在写文档，更是在检验你有没有把逻辑想透。

最后再分享一个我一直在用的土办法：把系统当成一个真实产品来打磨，每天自己用一遍学生端、教师端，就像在用自己的应用一样。哪个按钮用着别扭、哪个环节多了一步，改掉它。经得起自己日常使用的系统，答辩时自然就不会发虚。