做毕设选题目很多人第一眼看“师生交流系统”会觉得这不就是个普通论坛吗登录、发帖、回帖好像没什么技术含量。可真要动手把这个题目做成一个提得出、跑得动、答得上来的完整系统你很快会发现它一头连着用户权限一头连着课程业务中间还夹着文件上传、状态流转、消息通知这些绕不开的环节。这几年我帮不少准备毕业设计的同学捋过这个题目的实现路线今天就把“基于SpringBoot的师生互动教学平台”从需求拆解、技术选型、数据库设计到核心功能实现和常见坑位的完整过程整理出来给你一份可以直接照着走的实操参考。这个项目适合正在选毕设题目的同学也适合想做一套业务闭环Demo的Java开发者看完你至少能少走两个星期弯路。1. 系统定位先想清楚要解决什么问题1.1 从业务闭环倒推功能清单师生交流系统如果只做“聊天”那本质就是一个即时通讯Demo放到毕业答辩上很难讲出深度。我建议把它定义成一个“线上互动教学平台”把学校里真实的师生互动场景抽象出来。最常见的教学闭环是这样的教师创建课程学生加入课程学生在课程里提问教师解答教师布置作业学生提交作业教师批阅反馈系统在关键节点自动生成通知。一条线走下来既能覆盖CRUD、鉴权、文件上传这些基础技术点又能体现你对业务流程的理解。功能清单最少要包含三个视角管理员负责用户管理和内容审核教师负责课程、作业、答疑学生负责查看课程、提问和交作业。我遇到过一些同学一开始想把在线考试、直播、积分商城、数据大屏全塞进系统里结果做到最后连核心登录都还没稳定这基本上就是给自己挖坑。1.2 角色权限的划分方式我用“用户表 角色表 用户角色关联表”的经典模型来控制权限。用户表只存账号密码和基本信息角色表定义教师、学生、管理员三种角色关联表把用户和角色对应起来。这样做的好处是将来要扩展比如“助教”这种角色时只需要加一行角色数据再给用户分配关联关系完全不用动业务表的结构。注意很多同学图省事直接在用户表里加 isTeacher、isAdmin 两个布尔字段。当时看着方便后面加一个角色就要加一个字段业务代码里到处都是 if(user.isAdmin()) 的判断维护成本直接翻倍。权限断言方面我采用的是“角色即权限”的粗粒度方案。比如“创建课程”只需要校验当前用户是否属于教师角色“删除问题”则要校验问题是否属于当前用户。这种两层判断配合Shiro注解使用在答辩时可以很清晰地画出权限模型。1.3 为什么坚持做“简单但完整”的系统毕设项目最怕功能堆砌。如果一个系统同时塞了在线考试、视频直播、社交论坛、消息中心你可能直到答辩前还在改Bug连完整的演示流程都跑不通。我更推荐只围绕“课程-答疑-作业-通知”这四个模块做出深度每张表的字段设计要合理每个核心接口要有异常处理每个状态流转要有明确规则。功能越少你越有精力处理边界情况答辩老师问“连续操作会怎样”时你也能给出经得起推敲的回答。2. 技术选型与工程搭建2.1 为什么是SpringBoot和MyBatis-PlusSpring Boot 2.x是毕业设计这个场景下的稳妥选择。它内置Tomcat、提供起步依赖、自动配置大部分组件能把“配置繁琐”这个项目落地最大的坑提前填平。你只需要在pom文件里引入需要的starter写一个启动类项目就能跑起来后续精力可以全部放在业务代码上。MyBatis-Plus则是在MyBatis基础上封装了常用单表CRUD。BaseMapper里面已经提供了insert、selectById、updateById这些方法对于课程、作业、评论这类单表操作比较多的业务DAO层代码量能压缩到原来的三分之一。更关键的是它有条件构造器比如查某个课程下的所有作业直接LambdaQueryWrapper查即可不用手写XML。如果是做毕业设计我不太建议自己从头写底层框架也不建议引入太重的中台框架。你论文里要论证的不是“我会写框架”而是“我能用合适的工具把业务问题解决好”。SpringBoot加上MyBatis-Plus刚好是当前非常常见的企业开发组合将来写实习简历也用得上。2.2 权限框架这个项目我推荐ShiroShiro和Spring Security都是优秀的权限框架但就这门毕设课而言我推荐Shiro。原因很具体Shiro的核心概念更少就三个。Subject代表当前登录用户SecurityManager是安全管理器Realm负责从数据库查询用户和权限然后交给安全管理器。画图时就是一条链请求进入Shiro根据当前登录凭证找到SubjectSubject把认证和授权委托给SecurityManagerSecurityManager再从自定义Realm里取数据。Spring Security功能更多但对应的概念也更复杂。如果你之前没接触过光是把过滤器链和认证流程整明白就得花不少时间。Shiro的文档和示例相对好读出现问题时排查路径也更短。依赖方面Spring Boot对应版本用 shiro-spring-boot-web-starter 即可我实测下来配置量明显少于Spring Security。2.3 前端渲染方案怎么选前后端分离和服务端渲染都可以做关键看你的能力边界。我的建议是如果你会用Vue就选择前后端分离方案用Vue Element Plus搭一套后台管理界面接口驱动开发代码层次非常清楚答辩演示时还能讲一讲接口联调的过程。这里唯一要小心的就是跨域配置后面我会专门讲。如果你前端基础相对薄弱用Thymeleaf做服务端渲染也能把系统完整做出来。Spring Boot对Thymeleaf的集成度很高视图层直接用模型数据填充不需要处理跨域。缺点是页面交互做复杂后维护起来比较吃力。两种方案的最终效果都能满足毕设要求但前后端分离显然更接近企业开发模式能让面试官看出来你见过真实的项目是怎么组织的。3. 数据库设计表结构画清楚后面能少返一半工3.1 数据模型整体规划表结构要跟着业务实体走不要一开始就想着把所有字段堆进一张大表。我按功能模块把数据模型拆成四个部分用户权限域、课程域、答疑域、作业域。用户权限域包括用户表、角色表、用户角色关联表。课程域有课程表和学生选课关联表。答疑域有问题表和回复表。作业域有作业表和提交记录表。最后加一张通知表接收方、业务类型、是否已读都在这里记录。这么拆的核心原因是职责单一。比如删除一个用户时你只需要在关联表里清理角色和选课关系如果所有东西都混在一张大表里任何一次改动都会引爆一堆外围数据问题。数据库的字段名、表名还是建议统一风格所有表都用t_前缀所有关联表都叫mid_开头这样答辩翻库的时候看起来非常整齐。3.2 核心表结构与建表语句用户表是最基础的一张表关键点在于密码要存密文不能用明文。我用varchar(100)存BCrypt加密后的密码串用户名加唯一索引查询效率高逻辑上也保证了账号不重复。CREATE TABLE t_user ( id bigint NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL COMMENT 登录账号, password varchar(100) NOT NULL COMMENT 密码密文, real_name varchar(50) DEFAULT NULL COMMENT 真实姓名, email varchar(100) DEFAULT NULL, status tinyint NOT NULL DEFAULT 1 COMMENT 1正常 0禁用, create_time datetime NOT NULL, update_time datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;课程表主要用于存课程基础信息比如课程名称、简介、授课教师ID。要注意教师ID这里只做逻辑外键关系不建物理外键。为什么因为物理外键会给删除操作带来很多麻烦。比如你要删除一条课程记录如果还有学生在选课表里引用它物理外键会直接阻止删除而业务上可能只是需要“下线课程”而不是“删干净”。用逻辑外键加索引应用层控制数据关系才是更贴近真实项目的处理方式。答疑问题表是这个业务域里比较有代表性的一张表关键在于状态字段和最佳答案字段的设计CREATE TABLE t_question ( id bigint NOT NULL AUTO_INCREMENT, course_id bigint NOT NULL COMMENT 所属课程, student_id bigint NOT NULL COMMENT 提问学生, title varchar(200) NOT NULL COMMENT 问题标题, content text COMMENT 问题内容, status tinyint NOT NULL DEFAULT 0 COMMENT 0待解决 1已解决, answer_id bigint DEFAULT NULL COMMENT 最佳答案id, create_time datetime NOT NULL, update_time datetime NOT NULL, PRIMARY KEY (id), KEY idx_course (course_id), KEY idx_student (student_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT答疑问题表;status字段标记是否已解决answer_id记录采纳的最佳答案。这样设计的好处是列表页可以直接 select where status 0 查到待解决的问题点进详情时再通过answer_id把对应回复取出来。不需要用“删帖”这种不优雅的操作去改变业务状态。作业表和提交记录表是另一组核心关系。作业表存课程ID、作业标题、要求描述、截止时间。提交记录表存作业ID、学生ID、提交文件路径、提交时间、评分、评语。为了支持学生重复提交我给提交记录按 student_id 和 assignment_id 加了唯一索引重复提交时先删旧记录再插入新记录或者直接用 on duplicate key update 更新。3.3 建表时容易踩的几个坑第一个坑是字段名用了保留字或关键字。比如给课程表增加一个“description”没问题但用“order”想表达排序SQL就报错了。这类问题非常隐蔽排查时很浪费时间。我的习惯是建表之前先过一遍MySQL保留字列表拿不准的字段都加上别的前缀。第二个坑是时间字段类型。建议直接用 datetime 而不是 timestamp避免2038年问题和各种时区转换的麻烦。配合LocalDateTime使用Java代码里体验很好。第三个坑是字符集。所有表统一用utf8mb4原因很简单utf8mb4能存表情符号和扫码登录等等现代化功能适配性更好还能避免学生提交内容里出现特殊字符时报“Incorrect string value”错误。4. 核心功能实现一条链路四个模块的落地4.1 登录认证与当前用户上下文登录模块是整个系统的入口也是答辩时最容易被追问的地方。我用Shiro加JWT的思路实现无状态登录。用户输入账号密码后端先构造一个UsernamePasswordToken交给SecurityUtils.getSubject()去登录登录成功后生成一个JWT字符串返回给前端。前端把JWT放在请求头的Authorization字段里后端每次请求通过自定义过滤器解析JWT恢复登录状态。PostMapping(/login) public Result login(RequestBody LoginDTO dto) { UsernamePasswordToken token new UsernamePasswordToken(dto.getUsername(), dto.getPassword()); Subject subject SecurityUtils.getSubject(); subject.login(token); UserDO user (UserDO) subject.getPrincipal(); String jwt JwtUtil.createToken(user.getId(), user.getUsername()); return Result.success(jwt); }为什么密码加密用BCrypt而不是MD5因为MD5是摘要算法虽然不可逆但查表碰撞成本很低同样的密码总能算出同样的MD5值非常容易被彩虹表攻击。BCrypt则会在原始密码后面拼接随机盐同一密码每次加密后的密文都不一样安全性高一个量级。在毕设论文里写出“使用BCrypt加盐散列”这个理由比笼统写“用MD5加密”要认真得多。4.2 答疑模块的设计要点答疑模块的核心是三个动作提问、回复、采纳答案。提问时后端要校验三点当前用户已登录、课程ID真实存在、当前用户已经是该课程的学生。提问完成后往问题表插入一条记录状态是0待解决。回复动作要注意“谁能回复”这个问题。我的规则是登录用户可以回复任何公开课程下的问题但如果是未结课状态才允许提问和回复。这个规则不复杂但体现了业务细节。答辩时老师问“你这个系统允许游客逛课程吗”你得明确回答课程是校内教学空间游客不参与互动只允许登录用户查看。采纳答案这个动作很多人会理解成“教师采纳”但实际业务里答案是学生选出来的。问题归属学生所以只有提问学生本人能调用采纳接口。后端实现也简单PostMapping(/question/accept) public Result accept(RequestBody AcceptDTO dto) { QuestionDO question questionMapper.selectById(dto.getQuestionId()); if (question null) { return Result.error(问题不存在); } if (!question.getStudentId().equals(currentUserId())) { return Result.error(只有提问者可以采纳答案); } AnswerDO answer answerMapper.selectById(dto.getAnswerId()); if (answer null || !answer.getQuestionId().equals(question.getId())) { return Result.error(答案不存在或不属于该问题); } question.setStatus(1); question.setAnswerId(answer.getId()); questionMapper.updateById(question); return Result.success(); }这段逻辑有三层校验第一层查问题第二层判断操作人第三层校验答案属于该问题。答辩时你可以把这段代码拆开讲老师会觉得考虑得很全面。4.3 作业提交与截止时间校验作业领域最容易粗心的点是截止时间。学生提交作业时后端必须当前时间与作业表的deadline做对比。注意这里不能用前端传的时间因为前端时间可以被篡改必须拿服务器时间来判断。DateTime now DateTime.now(); if (now.isAfter(assignment.getDeadline())) { return Result.error(作业已截止无法提交); }文件存储方面毕业设计不建议引入对象存储服务本地磁盘方案就足够。使用upload目录加日期子目录组织文件文件名存UUID避免中文文件名在服务器上出现编码问题。提交记录除了存文件路径外还要把文件原始文件名一并存下来否则学生下载时看到一堆uuid体验太差。你可以使用一个文件名映射字段来保存源文件名。4.4 通知机制不引入消息队列也能实现通知模块不需要上MQ。你就设计一张通知表字段包含接收人ID、触发业务类型、关联业务ID、内容摘要、是否已读、创建时间。关键是如何选择合适的触发时机。学生提交作业成功后往通知表插入一条给该课程教师的通知说明“某学生提交了作业”。教师回复问题后插入一条给学生提问者的通知说明“你的问题有新回复”。用户登录后查询通知表里 read 0 的记录总数展示在导航栏的小红点上。就是这么简单。答辩如果被问“性能怎么办”你可以诚实回答当前数据量下同步插入通知完全够用如果以后用户量上来了可以把通知写入改造成异步队列但这种设计是后续优化方向不影响当前功能正确性。这比盲目引入RocketMQ然后自己都讲不清原理要高明得多。5. 实测中反复踩到的坑代码能跑不等于没问题5.1 MyBatis-Plus分页查询不生效这是我见过发生频率最高的问题。很多同学按文档引入了依赖前端也传了page和size但查回来的数据一直是全量。原因基本都一致只引入了依赖没有把分页插件注册到MyBatis-Plus的拦截器里。Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }没有这个PaginationInnerInterceptorPage对象根本不会在SQL末尾拼接limit自然分不了页。这个坑不算难解但排查时容易盯着前端代码看半天白白浪费时间。建议在项目初始化阶段就先把分页插件配好。5.2 跨域和登录态丢失前后端分离开发时前端跑3000端口后端跑8080端口axios请求默认会被浏览器的同源策略拦下来。你得在后端配置CORS过滤器允许指定前端来源访问。这里有三个细节要注意。第一allowedOriginPatterns不要写*而是要明确列出前端地址比如http://localhost:3000。第二如果使用了Cookie或认证头必须把allowCredentials设为true这时allowedOrigin就不能是*否则会被浏览器拒绝。第三如果是JWT方案前端每次请求都要在axios拦截器里加上Authorization头。很多同学登录能成功但下一个接口报401其实就是token没被带上。Configuration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(http://localhost:3000); config.setAllowCredentials(true); config.addAllowedHeader(*); config.addAllowedMethod(*); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }5.3 事务注解无声失效Transactional在毕设项目里出现频率很高但失效的场景也不少。最典型的是同类内部方法调用。比如你写了一个submit方法它内部调用了同一个类里的另一个加事务的方法。由于Spring事务是通过代理实现的类内部this.方法()走的是原始对象不会经过代理事务自然不生效。第二个常见问题是异常被吞掉。事务默认只在RuntimeException和Error时回滚如果你在方法里try-catch把异常捕获了没有重新抛出Spring根本感知不到异常事务就不会回滚。处理方式是遇到错误要么重新抛出要么在catch块里手动调用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。第三个问题是自调用。有效规避方法是把涉及多个写操作的方法拆分到不同的Service里通过注入调用这样代理才生效。5.4 文件上传大小限制Spring Boot默认单文件大小上限是1MB很多同学上传作业附件一直报错还以为是前端组件的问题。其实只需要在application.yml里调大配置spring: servlet: multipart: max-file-size: 50MB max-request-size: 50MB需要注意除了这个配置还要确认后端服务器的请求体大小限制没有被网关或代理层拦截。本地开发一般不涉及但如果你做了前后端分离部署到服务器就要检查Nginx的client_max_body_size。5.5 时间字段的神秘时差JVM默认时区如果和数据库不一致存进去的datetime会和本地时间差8小时。解决办法是JDBC连接串加上serverTimezoneAsia/Shanghai并且在实体类里统一使用LocalDateTime类型。同时建议在Spring Boot配置里固定Jackson的时区保证返回给前端的JSON时间也是东八区。spring: jackson: time-zone: Asia/Shanghai date-format: yyyy-MM-dd HH:mm:ss这个问题很隐蔽因为本地调试时可能正常部署到服务器后才发现时间全乱了。答辩前一定要把服务器时区、数据库时区、应用时区三者对齐。6. 答辩演示前的准备清单6.1 准备一套完整的演示数据答辩演示最忌讳打开页面全是空列表。你至少要准备一组能讲故事的数据一个教师账号、一个学生账号、一门课程、两个提问帖子一个待解决、一个已解决、一条已提交作业、一条未提交作业、两条未读通知。演示时按业务闭环走登录教师账号查看待解决问题回复一次切换学生账号查看通知确认问题已解决再提交一次作业回到教师端看批阅界面。完整流程跑下来比单纯点菜单有说服力得多。6.2 论文与技术方案的对应关系论文结构不用太纠结常规的五章结构就好。需求分析对应第一章的系统概述和功能需求系统设计对应技术架构和功能模块划分数据库设计放E-R图和表结构说明功能实现章节把登录认证、答疑、作业、通知这几个模块的流程图和关键代码讲清楚测试章节放功能测试用例和结论。你越能把论文里的图和Demo里的操作对应上答辩越稳。6.3 时间安排建议总体按8周来排比较稳妥。前两周定需求和技术方案把表结构画出来第三四周完成项目搭建、登录权限、课程模块第五六周做完答疑、作业、通知和前端页面第七周集中修Bug、补测试数据、录制演示视频第八周写论文和准备PPT。不要把写论文留到最后三天通宵出来的论文质量很难保证。这个题目做下来我的体会是整个项目看下来最难的不是某一个技术点而是把所有模块串成一个完整故事的能力。只要你能把登录、权限、课程、问答、作业、通知这条链路在演示时一气呵成走通答辩基本上就稳了。等你做完这个项目你会发现自己对Java Web开发从前端请求到后端处理再到数据库落地的整个链路建立起特别具体的认知这是跟着视频敲任何Demo都换不来的经验。
做毕设选题目很多人第一眼看“师生交流系统”会觉得这不就是个普通论坛吗登录、发帖、回帖好像没什么技术含量。可真要动手把这个题目做成一个提得出、跑得动、答得上来的完整系统你很快会发现它一头连着用户权限一头连着课程业务中间还夹着文件上传、状态流转、消息通知这些绕不开的环节。这几年我帮不少准备毕业设计的同学捋过这个题目的实现路线今天就把“基于SpringBoot的师生互动教学平台”从需求拆解、技术选型、数据库设计到核心功能实现和常见坑位的完整过程整理出来给你一份可以直接照着走的实操参考。这个项目适合正在选毕设题目的同学也适合想做一套业务闭环Demo的Java开发者看完你至少能少走两个星期弯路。1. 系统定位先想清楚要解决什么问题1.1 从业务闭环倒推功能清单师生交流系统如果只做“聊天”那本质就是一个即时通讯Demo放到毕业答辩上很难讲出深度。我建议把它定义成一个“线上互动教学平台”把学校里真实的师生互动场景抽象出来。最常见的教学闭环是这样的教师创建课程学生加入课程学生在课程里提问教师解答教师布置作业学生提交作业教师批阅反馈系统在关键节点自动生成通知。一条线走下来既能覆盖CRUD、鉴权、文件上传这些基础技术点又能体现你对业务流程的理解。功能清单最少要包含三个视角管理员负责用户管理和内容审核教师负责课程、作业、答疑学生负责查看课程、提问和交作业。我遇到过一些同学一开始想把在线考试、直播、积分商城、数据大屏全塞进系统里结果做到最后连核心登录都还没稳定这基本上就是给自己挖坑。1.2 角色权限的划分方式我用“用户表 角色表 用户角色关联表”的经典模型来控制权限。用户表只存账号密码和基本信息角色表定义教师、学生、管理员三种角色关联表把用户和角色对应起来。这样做的好处是将来要扩展比如“助教”这种角色时只需要加一行角色数据再给用户分配关联关系完全不用动业务表的结构。注意很多同学图省事直接在用户表里加 isTeacher、isAdmin 两个布尔字段。当时看着方便后面加一个角色就要加一个字段业务代码里到处都是 if(user.isAdmin()) 的判断维护成本直接翻倍。权限断言方面我采用的是“角色即权限”的粗粒度方案。比如“创建课程”只需要校验当前用户是否属于教师角色“删除问题”则要校验问题是否属于当前用户。这种两层判断配合Shiro注解使用在答辩时可以很清晰地画出权限模型。1.3 为什么坚持做“简单但完整”的系统毕设项目最怕功能堆砌。如果一个系统同时塞了在线考试、视频直播、社交论坛、消息中心你可能直到答辩前还在改Bug连完整的演示流程都跑不通。我更推荐只围绕“课程-答疑-作业-通知”这四个模块做出深度每张表的字段设计要合理每个核心接口要有异常处理每个状态流转要有明确规则。功能越少你越有精力处理边界情况答辩老师问“连续操作会怎样”时你也能给出经得起推敲的回答。2. 技术选型与工程搭建2.1 为什么是SpringBoot和MyBatis-PlusSpring Boot 2.x是毕业设计这个场景下的稳妥选择。它内置Tomcat、提供起步依赖、自动配置大部分组件能把“配置繁琐”这个项目落地最大的坑提前填平。你只需要在pom文件里引入需要的starter写一个启动类项目就能跑起来后续精力可以全部放在业务代码上。MyBatis-Plus则是在MyBatis基础上封装了常用单表CRUD。BaseMapper里面已经提供了insert、selectById、updateById这些方法对于课程、作业、评论这类单表操作比较多的业务DAO层代码量能压缩到原来的三分之一。更关键的是它有条件构造器比如查某个课程下的所有作业直接LambdaQueryWrapper查即可不用手写XML。如果是做毕业设计我不太建议自己从头写底层框架也不建议引入太重的中台框架。你论文里要论证的不是“我会写框架”而是“我能用合适的工具把业务问题解决好”。SpringBoot加上MyBatis-Plus刚好是当前非常常见的企业开发组合将来写实习简历也用得上。2.2 权限框架这个项目我推荐ShiroShiro和Spring Security都是优秀的权限框架但就这门毕设课而言我推荐Shiro。原因很具体Shiro的核心概念更少就三个。Subject代表当前登录用户SecurityManager是安全管理器Realm负责从数据库查询用户和权限然后交给安全管理器。画图时就是一条链请求进入Shiro根据当前登录凭证找到SubjectSubject把认证和授权委托给SecurityManagerSecurityManager再从自定义Realm里取数据。Spring Security功能更多但对应的概念也更复杂。如果你之前没接触过光是把过滤器链和认证流程整明白就得花不少时间。Shiro的文档和示例相对好读出现问题时排查路径也更短。依赖方面Spring Boot对应版本用 shiro-spring-boot-web-starter 即可我实测下来配置量明显少于Spring Security。2.3 前端渲染方案怎么选前后端分离和服务端渲染都可以做关键看你的能力边界。我的建议是如果你会用Vue就选择前后端分离方案用Vue Element Plus搭一套后台管理界面接口驱动开发代码层次非常清楚答辩演示时还能讲一讲接口联调的过程。这里唯一要小心的就是跨域配置后面我会专门讲。如果你前端基础相对薄弱用Thymeleaf做服务端渲染也能把系统完整做出来。Spring Boot对Thymeleaf的集成度很高视图层直接用模型数据填充不需要处理跨域。缺点是页面交互做复杂后维护起来比较吃力。两种方案的最终效果都能满足毕设要求但前后端分离显然更接近企业开发模式能让面试官看出来你见过真实的项目是怎么组织的。3. 数据库设计表结构画清楚后面能少返一半工3.1 数据模型整体规划表结构要跟着业务实体走不要一开始就想着把所有字段堆进一张大表。我按功能模块把数据模型拆成四个部分用户权限域、课程域、答疑域、作业域。用户权限域包括用户表、角色表、用户角色关联表。课程域有课程表和学生选课关联表。答疑域有问题表和回复表。作业域有作业表和提交记录表。最后加一张通知表接收方、业务类型、是否已读都在这里记录。这么拆的核心原因是职责单一。比如删除一个用户时你只需要在关联表里清理角色和选课关系如果所有东西都混在一张大表里任何一次改动都会引爆一堆外围数据问题。数据库的字段名、表名还是建议统一风格所有表都用t_前缀所有关联表都叫mid_开头这样答辩翻库的时候看起来非常整齐。3.2 核心表结构与建表语句用户表是最基础的一张表关键点在于密码要存密文不能用明文。我用varchar(100)存BCrypt加密后的密码串用户名加唯一索引查询效率高逻辑上也保证了账号不重复。CREATE TABLE t_user ( id bigint NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL COMMENT 登录账号, password varchar(100) NOT NULL COMMENT 密码密文, real_name varchar(50) DEFAULT NULL COMMENT 真实姓名, email varchar(100) DEFAULT NULL, status tinyint NOT NULL DEFAULT 1 COMMENT 1正常 0禁用, create_time datetime NOT NULL, update_time datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;课程表主要用于存课程基础信息比如课程名称、简介、授课教师ID。要注意教师ID这里只做逻辑外键关系不建物理外键。为什么因为物理外键会给删除操作带来很多麻烦。比如你要删除一条课程记录如果还有学生在选课表里引用它物理外键会直接阻止删除而业务上可能只是需要“下线课程”而不是“删干净”。用逻辑外键加索引应用层控制数据关系才是更贴近真实项目的处理方式。答疑问题表是这个业务域里比较有代表性的一张表关键在于状态字段和最佳答案字段的设计CREATE TABLE t_question ( id bigint NOT NULL AUTO_INCREMENT, course_id bigint NOT NULL COMMENT 所属课程, student_id bigint NOT NULL COMMENT 提问学生, title varchar(200) NOT NULL COMMENT 问题标题, content text COMMENT 问题内容, status tinyint NOT NULL DEFAULT 0 COMMENT 0待解决 1已解决, answer_id bigint DEFAULT NULL COMMENT 最佳答案id, create_time datetime NOT NULL, update_time datetime NOT NULL, PRIMARY KEY (id), KEY idx_course (course_id), KEY idx_student (student_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT答疑问题表;status字段标记是否已解决answer_id记录采纳的最佳答案。这样设计的好处是列表页可以直接 select where status 0 查到待解决的问题点进详情时再通过answer_id把对应回复取出来。不需要用“删帖”这种不优雅的操作去改变业务状态。作业表和提交记录表是另一组核心关系。作业表存课程ID、作业标题、要求描述、截止时间。提交记录表存作业ID、学生ID、提交文件路径、提交时间、评分、评语。为了支持学生重复提交我给提交记录按 student_id 和 assignment_id 加了唯一索引重复提交时先删旧记录再插入新记录或者直接用 on duplicate key update 更新。3.3 建表时容易踩的几个坑第一个坑是字段名用了保留字或关键字。比如给课程表增加一个“description”没问题但用“order”想表达排序SQL就报错了。这类问题非常隐蔽排查时很浪费时间。我的习惯是建表之前先过一遍MySQL保留字列表拿不准的字段都加上别的前缀。第二个坑是时间字段类型。建议直接用 datetime 而不是 timestamp避免2038年问题和各种时区转换的麻烦。配合LocalDateTime使用Java代码里体验很好。第三个坑是字符集。所有表统一用utf8mb4原因很简单utf8mb4能存表情符号和扫码登录等等现代化功能适配性更好还能避免学生提交内容里出现特殊字符时报“Incorrect string value”错误。4. 核心功能实现一条链路四个模块的落地4.1 登录认证与当前用户上下文登录模块是整个系统的入口也是答辩时最容易被追问的地方。我用Shiro加JWT的思路实现无状态登录。用户输入账号密码后端先构造一个UsernamePasswordToken交给SecurityUtils.getSubject()去登录登录成功后生成一个JWT字符串返回给前端。前端把JWT放在请求头的Authorization字段里后端每次请求通过自定义过滤器解析JWT恢复登录状态。PostMapping(/login) public Result login(RequestBody LoginDTO dto) { UsernamePasswordToken token new UsernamePasswordToken(dto.getUsername(), dto.getPassword()); Subject subject SecurityUtils.getSubject(); subject.login(token); UserDO user (UserDO) subject.getPrincipal(); String jwt JwtUtil.createToken(user.getId(), user.getUsername()); return Result.success(jwt); }为什么密码加密用BCrypt而不是MD5因为MD5是摘要算法虽然不可逆但查表碰撞成本很低同样的密码总能算出同样的MD5值非常容易被彩虹表攻击。BCrypt则会在原始密码后面拼接随机盐同一密码每次加密后的密文都不一样安全性高一个量级。在毕设论文里写出“使用BCrypt加盐散列”这个理由比笼统写“用MD5加密”要认真得多。4.2 答疑模块的设计要点答疑模块的核心是三个动作提问、回复、采纳答案。提问时后端要校验三点当前用户已登录、课程ID真实存在、当前用户已经是该课程的学生。提问完成后往问题表插入一条记录状态是0待解决。回复动作要注意“谁能回复”这个问题。我的规则是登录用户可以回复任何公开课程下的问题但如果是未结课状态才允许提问和回复。这个规则不复杂但体现了业务细节。答辩时老师问“你这个系统允许游客逛课程吗”你得明确回答课程是校内教学空间游客不参与互动只允许登录用户查看。采纳答案这个动作很多人会理解成“教师采纳”但实际业务里答案是学生选出来的。问题归属学生所以只有提问学生本人能调用采纳接口。后端实现也简单PostMapping(/question/accept) public Result accept(RequestBody AcceptDTO dto) { QuestionDO question questionMapper.selectById(dto.getQuestionId()); if (question null) { return Result.error(问题不存在); } if (!question.getStudentId().equals(currentUserId())) { return Result.error(只有提问者可以采纳答案); } AnswerDO answer answerMapper.selectById(dto.getAnswerId()); if (answer null || !answer.getQuestionId().equals(question.getId())) { return Result.error(答案不存在或不属于该问题); } question.setStatus(1); question.setAnswerId(answer.getId()); questionMapper.updateById(question); return Result.success(); }这段逻辑有三层校验第一层查问题第二层判断操作人第三层校验答案属于该问题。答辩时你可以把这段代码拆开讲老师会觉得考虑得很全面。4.3 作业提交与截止时间校验作业领域最容易粗心的点是截止时间。学生提交作业时后端必须当前时间与作业表的deadline做对比。注意这里不能用前端传的时间因为前端时间可以被篡改必须拿服务器时间来判断。DateTime now DateTime.now(); if (now.isAfter(assignment.getDeadline())) { return Result.error(作业已截止无法提交); }文件存储方面毕业设计不建议引入对象存储服务本地磁盘方案就足够。使用upload目录加日期子目录组织文件文件名存UUID避免中文文件名在服务器上出现编码问题。提交记录除了存文件路径外还要把文件原始文件名一并存下来否则学生下载时看到一堆uuid体验太差。你可以使用一个文件名映射字段来保存源文件名。4.4 通知机制不引入消息队列也能实现通知模块不需要上MQ。你就设计一张通知表字段包含接收人ID、触发业务类型、关联业务ID、内容摘要、是否已读、创建时间。关键是如何选择合适的触发时机。学生提交作业成功后往通知表插入一条给该课程教师的通知说明“某学生提交了作业”。教师回复问题后插入一条给学生提问者的通知说明“你的问题有新回复”。用户登录后查询通知表里 read 0 的记录总数展示在导航栏的小红点上。就是这么简单。答辩如果被问“性能怎么办”你可以诚实回答当前数据量下同步插入通知完全够用如果以后用户量上来了可以把通知写入改造成异步队列但这种设计是后续优化方向不影响当前功能正确性。这比盲目引入RocketMQ然后自己都讲不清原理要高明得多。5. 实测中反复踩到的坑代码能跑不等于没问题5.1 MyBatis-Plus分页查询不生效这是我见过发生频率最高的问题。很多同学按文档引入了依赖前端也传了page和size但查回来的数据一直是全量。原因基本都一致只引入了依赖没有把分页插件注册到MyBatis-Plus的拦截器里。Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }没有这个PaginationInnerInterceptorPage对象根本不会在SQL末尾拼接limit自然分不了页。这个坑不算难解但排查时容易盯着前端代码看半天白白浪费时间。建议在项目初始化阶段就先把分页插件配好。5.2 跨域和登录态丢失前后端分离开发时前端跑3000端口后端跑8080端口axios请求默认会被浏览器的同源策略拦下来。你得在后端配置CORS过滤器允许指定前端来源访问。这里有三个细节要注意。第一allowedOriginPatterns不要写*而是要明确列出前端地址比如http://localhost:3000。第二如果使用了Cookie或认证头必须把allowCredentials设为true这时allowedOrigin就不能是*否则会被浏览器拒绝。第三如果是JWT方案前端每次请求都要在axios拦截器里加上Authorization头。很多同学登录能成功但下一个接口报401其实就是token没被带上。Configuration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(http://localhost:3000); config.setAllowCredentials(true); config.addAllowedHeader(*); config.addAllowedMethod(*); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }5.3 事务注解无声失效Transactional在毕设项目里出现频率很高但失效的场景也不少。最典型的是同类内部方法调用。比如你写了一个submit方法它内部调用了同一个类里的另一个加事务的方法。由于Spring事务是通过代理实现的类内部this.方法()走的是原始对象不会经过代理事务自然不生效。第二个常见问题是异常被吞掉。事务默认只在RuntimeException和Error时回滚如果你在方法里try-catch把异常捕获了没有重新抛出Spring根本感知不到异常事务就不会回滚。处理方式是遇到错误要么重新抛出要么在catch块里手动调用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。第三个问题是自调用。有效规避方法是把涉及多个写操作的方法拆分到不同的Service里通过注入调用这样代理才生效。5.4 文件上传大小限制Spring Boot默认单文件大小上限是1MB很多同学上传作业附件一直报错还以为是前端组件的问题。其实只需要在application.yml里调大配置spring: servlet: multipart: max-file-size: 50MB max-request-size: 50MB需要注意除了这个配置还要确认后端服务器的请求体大小限制没有被网关或代理层拦截。本地开发一般不涉及但如果你做了前后端分离部署到服务器就要检查Nginx的client_max_body_size。5.5 时间字段的神秘时差JVM默认时区如果和数据库不一致存进去的datetime会和本地时间差8小时。解决办法是JDBC连接串加上serverTimezoneAsia/Shanghai并且在实体类里统一使用LocalDateTime类型。同时建议在Spring Boot配置里固定Jackson的时区保证返回给前端的JSON时间也是东八区。spring: jackson: time-zone: Asia/Shanghai date-format: yyyy-MM-dd HH:mm:ss这个问题很隐蔽因为本地调试时可能正常部署到服务器后才发现时间全乱了。答辩前一定要把服务器时区、数据库时区、应用时区三者对齐。6. 答辩演示前的准备清单6.1 准备一套完整的演示数据答辩演示最忌讳打开页面全是空列表。你至少要准备一组能讲故事的数据一个教师账号、一个学生账号、一门课程、两个提问帖子一个待解决、一个已解决、一条已提交作业、一条未提交作业、两条未读通知。演示时按业务闭环走登录教师账号查看待解决问题回复一次切换学生账号查看通知确认问题已解决再提交一次作业回到教师端看批阅界面。完整流程跑下来比单纯点菜单有说服力得多。6.2 论文与技术方案的对应关系论文结构不用太纠结常规的五章结构就好。需求分析对应第一章的系统概述和功能需求系统设计对应技术架构和功能模块划分数据库设计放E-R图和表结构说明功能实现章节把登录认证、答疑、作业、通知这几个模块的流程图和关键代码讲清楚测试章节放功能测试用例和结论。你越能把论文里的图和Demo里的操作对应上答辩越稳。6.3 时间安排建议总体按8周来排比较稳妥。前两周定需求和技术方案把表结构画出来第三四周完成项目搭建、登录权限、课程模块第五六周做完答疑、作业、通知和前端页面第七周集中修Bug、补测试数据、录制演示视频第八周写论文和准备PPT。不要把写论文留到最后三天通宵出来的论文质量很难保证。这个题目做下来我的体会是整个项目看下来最难的不是某一个技术点而是把所有模块串成一个完整故事的能力。只要你能把登录、权限、课程、问答、作业、通知这条链路在演示时一气呵成走通答辩基本上就稳了。等你做完这个项目你会发现自己对Java Web开发从前端请求到后端处理再到数据库落地的整个链路建立起特别具体的认知这是跟着视频敲任何Demo都换不来的经验。
