简介这是一套面向计算机相关专业本科生的毕业设计与课程设计实战项目基于主流开源框架 Ruoyi-Vue 构建家教一体化系统解决家教服务中教师管理、学生匹配、课程预约、评价反馈等核心业务场景适用于计科、人工智能、通信工程等专业学生开展毕设、课设或大作业开发。压缩包共708个文件涵盖303个Java后端逻辑文件、113个Vue前端组件、83个JS交互脚本、36个XML配置及5个YML环境配置文件辅以SQL建表脚本、SVG图标资源与多环境启动脚本如run.bat、package.bat整体体积仅5.36MB结构清晰、模块解耦度高。已有79人下载学习项目经完整测试并成功通过答辩平均评分96分附带可运行演示地址与详细README说明。读者可直接部署体验全流程功能亦可基于现有模块快速二次开发如拓展支付集成、消息推送或数据分析看板是兼具教学性、工程性与扩展性的高质量学习范例。 带“家教一体化系统”这个标题做毕设我一开始是有点犹豫的。市面上那么多开源项目光家教管理系统少说也能搜出三四套直接拿来改改交上去老师一问细节就露馅。但如果从零手写一个Vue前端加Spring Boot后端三个月都不一定够。后来我换了个思路不跟那些“纯原生”的项目比而是把RuoYi-Vue这种成熟脚手架当底座在它上面做家教业务系统的二次开发。这样一来系统管理相关的功能不用自己造轮子我又能把全部精力放在家教业务模块的设计和实现上最终做出来的系统功能完整、权限清晰、演示效果也够好答辩时讲起来底气很足。这篇就把整个项目从选型、功能拆解、二次开发、部署演示到答辩亮点的完整链路写出来给正在做RuoYi-Vue方向毕设或者课设的同学做个参考。尤其是那些想用现成脚手架但又怕被当成“纯搬运”的人我的经验是选型不是问题关键是你在选型之上做了什么。1. 为什么拿RuoYi-Vue当毕设底座是条捷径但不是偷懒1.1 RuoYi-Vue到底是什么值不值得用它做毕设RuoYi-Vue是一套基于Spring Boot、Spring Security、MyBatis-Plus、Vue 2/3、Element UI的前后端分离开发平台社区已经帮我处理好了很多通用功能登录认证、用户管理、角色权限、菜单管理、操作日志、定时任务、代码生成、通用导入导出、系统监控等等。对毕业设计而言这些功能恰恰是老师最常看的“系统完整性”部分。说实话每个同学都会纠结“用开源框架算不算抄袭”。我的理解是毕业设计的核心是考察你分析问题、设计系统、解决实际业务问题的能力而不是逼着你在2025年不用任何工具链从零写一个权限框架。RuoYi-Vue就好比工地上的脚手架你不需要自己焊钢管搭架子但你在架子上砌砖、布线、装窗户才是真正的活。搭建出来的“建筑”是你的家教系统不是那套脚手架。另外还有一个很现实的原因RuoYi-Vue有完整的代码生成功能。业务表建好之后可以自动生成前端的列表页、表单页、后端的Controller、Service、Mapper生成出来的代码风格统一、格式规范交给老师看也挑不出大毛病。这个对毕设进度的提升是决定性的。1.2 家教业务选它有哪些优势我选RuoYi-Vue的第二个原因是家教系统的业务复杂度刚好踩在“脚手架之上、定制之下”的黄金位置。先说复杂度。家教一体化系统如果只做最简单的“家长找老师、老师被联系”那功能太单薄撑不起一个像样的毕设。但要做到平台级的完整流程比如家长发需求、老师抢单、双方约课、课时记录、课消结算、评价互评工作量又不小。RuoYi-Vue提供的用户体系、权限模型、日志审计、数据字典帮我省掉了至少30%的重复劳动剩下的70%业务开发才是我要展示的核心。再说模块划分。RuoYi-Vue的后端是模块化结构有一个ruoyi-system模块管理用户和权限还有ruoyi-quartz处理定时任务我在实践中可以新增一个ruoyi-family模块来集中放家教业务相关代码。前端也是一样src/views下新增family目录和系统自带的system目录并列结构非常清晰。答辩PPT里即使只放一张项目目录截图老师也能一眼看出你确实是做了二次开发而不是简单套壳。1.3 这套方案适合什么样的毕设/课设题目说起来家教系统只是其中一个典型场景。RuoYi-Vue做底座实际上非常适合一大类管理系统型题目社区团购平台、二手交易平台、校园跑腿系统、在线预约系统、宠物寄养平台等核心都是“多角色、有流程、有状态流转、有权限控制”。只要是这种业务你按我这篇文章的思路走把“家教”替换成你的主体对象就能复制。所以如果你是本科毕设、专科毕业设计或者课程设计需要交付一个能演示的系统这个选型很合适。但如果你是研究生课题需要推导算法、搞分布式架构、写并发设计那RuoYi-Vue只能当辅助后台论文重点还是要放到算法研究上。2. 家教一体化系统的功能边界先画出业务地图再动手2.1 三方角色和他们的核心诉求我写代码前花了将近一周时间梳理需求这一周在后来的开发中换来了巨大的效率回报。家教一体化系统我最终定义了三种角色家长、教员家教老师、系统管理员。家长端的诉求是注册登录后能发布家教需求、浏览教员列表、查看教员详情和评价、向教员发起预约申请、确认上课时间、记录孩子已上课时、核销课时包同时能对上完课的教员进行评价。教员端的诉求是接收和搜索家教需求、提交接单申请、管理自己的可上课时间、查看待上课日程、记录课时完成情况、查看收入统计、回访家长评价。管理员端的诉求是审核家长和教员的注册信息、下架违规需求、管理学科分类和年级分类、查看平台交易和课消数据、管理公告通知。这些需求听起来很常规但它们组合在一起就形成了完整业务闭环也是后面开发时划分模块的天然依据。2.2 核心业务闭环是怎么跑的我给这个系统设计的主线流程是家长发布需求 - 教员浏览并申请接单 - 家长在申请列表中选择教员 - 双方面对面或线上沟通 - 家长为教员创建课时包 - 上课后在系统中确认课时抵扣 - 课时结束触发评价入口 - 双方互评后数据进入教师评分体系。这套闭环画成流程图非常漂亮尤其适合放在毕业设计论文的“业务需求分析”那一章。关键是它把“人找课”变成了“课找老师”而且每个状态都有归属方系统在任意节点都要有状态更新和记录这就体现了“一体化”的含义。2.3 数据表设计15张业务表背后的设计逻辑家庭业务模块我最终建了15张表这里只挑核心的几张讲一下设计思路。家长需求表需求表 是业务起点包含标题、详细描述、孩子年级、学科、期望上课区域、期望时薪、状态、家长ID、发布时间。教务表必须单独建因为一个需求可能被多个老师申请。教员的申请记录表用于承接接单流程包含需求ID、教员ID、申请说明、状态。教员和孩子的关联通过课时包表关联。课时包表是重点包含家长ID、教员ID、剩余课时、总课时、有效期开始结束时间、状态。每次上课后通过课时消费详情表记录一条课时消费记录关联课时包ID和上课时间从而实现课消闭环。评价表存储家长对教员、教员对家长的双向评价评分等级1到5。这些表之间的关系我建议用一张整体ER图先画出来再同步到数据库设计文档里。开发时直接用RuoYi-Vue菜单添加业务菜单把接口挂在对应的目录下。2.4 用RuoYi自带能力覆盖通用管理功能业务模块之外系统管理层面我基本没有额外开发用的是脚手架自带的能力系统用户用于管理管理员账号角色管理用来给不同角色分配菜单权限部门管理映射平台组织的区域结构菜单管理用来配置前端路由数据字典管理学科分类和订单状态。这一块不管你是教育系统还是电商系统基本都是差不多的好处是答辩的时候你不用再从零解释用户密码怎么加密的、权限怎么鉴权的直接说“Spring Security JWT Redis”就是标准答案。不过有一点要特别提醒RuoYi自带的用户管理表在普通业务系统里通常会当成“后台用户”来用但在家教系统里家长和教员都是独立的业务主体我更推荐在业务侧建自己的家长表、教员表再和RuoYi的sys_user表通过外键关联。这样业务逻辑更清晰也不容易和系统用户的管理逻辑纠缠在一起。3. RuoYi-Vue二次开发实操从代码生成到业务接口落地3.1 环境准备和项目导入我使用的环境是JDK 1.8官方新版也可以上JDK 17但为了稳妥我还是用了8、MySQL 5.7、Redis 6.x、Node 14.17Maven 3.6。你如果电脑上装的是新版JDK跑RuoYi-Vue老版本时记得去pom.xml里看下spring-boot版本是否兼容不兼容的话要么升级项目依赖要么本地装多个JDK切换。后端导入直接用IDEA打开RuoYi-Vue根目录等待Maven把依赖拉完。前端用VSCode或WebStorm打开ruoyi-ui目录执行npm install这一步依赖包比较多网速慢的同学可能要等很久。我建议在npm前先设置淘宝镜像源能省不少时间npm config set registry https://registry.npmmirror.com装完依赖后启动后端进入ruoyi-admin模块运行Application主类再把前端跑起来npm run dev默认访问 http://localhost:8080 初始账号 admin/admin123。能跳到登录页并正常登录说明脚手架本身没有任何问题。3.2 建表之后用代码生成器提速RuoYi-Vue的代码生成功能是毕设项目的核武器。先在数据库里建好业务表然后在系统管理→代码生成里“导入”对应的表配置生成信息选择生成模板包名比如com.ruoyi.family点击生成就会自动下载一个压缩包。这里有一个必须注意的点代码生成器生成的代码默认是按照“单表无关联”来生成CRUD的但家教系统里的需求表、预约表、课时包表之间是有外键关系的。我生成的业务表代码只把它当基础的增删改查涉及到多表联查、业务状态变化的接口我还是手写。别指望生成器解决所有问题它只是帮你把增删改查和前端表单页面搭起来省掉写样板代码的时间。3.3 手写核心业务接口的套路以“家长发布需求”为例前端表单提交请求到后端流程是这样的前端拿到当前登录用户的ID通过Pinia/Vuex中的用户信息获取然后随表单一起提交。后端在Controller里接收DTO对象通过UserId从数据库查家长信息。服务层创建需求记录初始状态为“招募中”。开发者将整个操作包在一个事务里如果插入失败会自动回滚。Service层代码示意Transactional(rollbackFor Exception.class) public Long publishDemand(DemandDTO dto) { Demand demand new Demand(); BeanUtils.copyProperties(dto, demand); demand.setStatus(DemandStatus.RECRUITING.getCode()); demand.setPublisherId(SecurityUtils.getUserId()); demandMapper.insert(demand); return demand.getDemandId(); }关键点在于所有业务写入操作都要加上事务控制因为家教业务中经常涉及“预约申请通知”“确认接单更新需求状态”这种耦合更新不加事务容易产生脏数据这也是答辩时老师最爱问的点。3.4 权限控制和菜单配置RuoYi的权限控制基于RBAC模型后端接口使用PreAuthorize注解做权限校验。比如管理员才能删除需求接口上加PreAuthorize(ss.hasPermi(family:demand:remove))前端菜单管理里给每个按钮分配一个权限标识符和这个注解里的字符串对应。这样家长角色的菜单只能看到浏览需求和预约教员角色才能看到接单入口管理员才有删除、审核按钮。我建议在开发初期就把权限标识设计好围绕固定前缀规范写避免后期全部返工。3.5 前端页面开发中的组件复用前端开发中我一直用的是RuoYi自带的基础框架Element UI组件库已经内置。家教系统的核心页面基本是表格弹窗表单的结构。列表页用Table组件展示需求列表搜索区用Form加几个输入框和下拉选择详情用Dialog嵌套。做课消记录和评价时我用到了el-tabs将多个子页面整合在一个详情弹窗内比如“基本信息”“课时记录”“评价记录”三个Tab页这种展现方式很实用页面也显得功能完善。有一个值得分享的小技巧RuoYi前端封装了很多自定义指令和全局方法比如this.$modal.msgSuccess(操作成功)这类反馈提示以及clickhandleUpdate(row)这类表单回显套路。实际操作时多翻翻脚手架自带的管理页面学它们怎么处理loading状态和空数据比自己瞎写好看很多。4. 从本地跑通到部署上线一路踩过的坑和最终演示方案4.1 数据库初始化最容易踩的坑我第一次导入ruoyi.sql的时候直接丢进Navicat执行大概执行到一半就报了语法错误。原因很简单命令行执行和工具导入对SQL文件编码的兼容性不同且源文件里包含了一些注释段Navicat对某些编码字符处理会出现问题。正确做法是先用命令行执行mysql -uroot -p your_database ruoyi.sql然后再用Navicat连接检查表数量和信息是否完整。如果只想导入业务表我会单独导出一个family_business.sql只包含新业务表的建表语句和初始数据这样既降低出错概率也方便给老师演示“系统初始化的完整步骤”。4.2 前端打包后接口404的问题本地开发时前端通过Vite代理解决了跨域问题所以前端能访问到后端接口。但一旦执行npm run build:prod生成的dist目录需要在Nginx里配置反向代理把/api路径转发到后端8080端口。我第一次没配代理直接双击index.html打开结果页面空白一片控制台里全是跨域报错。搞定Nginx配置后还需要注意history路由模式下的fallback配置否则刷新任意子路由都会404。一个比较省事的演示方案是如果只是答辩演示完全不用买服务器直接在前端和后端都保持本地开发环境浏览器访问localhost:8080端口即可。但如果老师要求线上演示我建议用一台轻量服务器在上面跑Nginx和Spring Boot jar包。后端打包命令mvn clean package -DskipTests java -jar ruoyi-admin.jar前端dist目录用Nginx托管把root /usr/share/nginx/html;指向dist目录就行。4.3 一次真实联调问题复盘课时“超卖”了这是我整个项目里遇到的最有意思的bug也成了我答辩时最能讲的实战案例。业务场景是家长创建了A教员的30节课时包一天下午同时有两个“上课确认”请求打过来家长在手机端连续点了两次确认。结果系统显示课时包剩余课时从5节变成了3节一查数据表发现有两个“课时消费”记录各扣了1节但实际上这同一节课被重复确认了两次。这个问题的根因在于扣减课时的SQL是“先查询剩余课时再在Java代码里减1最后update”两个请求并发读取到相同的剩余课时自然就会各写回一个错误的值。解决办法是改成数据库层面的原子扣减update course_package set remaining_hours remaining_hours - 1 where package_id #{packageId} and remaining_hours 0同时给课时消费表加上唯一索引防止同一节课重复插入。这个案例老师非常感兴趣因为它是典型的并发一致性问题直接把毕设从“业务堆叠”拔高到了“工程实践”。4.4 演示地址和演示话术的打磨如果自己不想买服务器又想给老师一个“在线演示”的震撼效果可以把前端部署到GitHub Pages或Gitee Pages后端接口写成本地内网穿透或服务器部署。但这里要非常注意公开的演示环境必须有完善的数据权限和风控措施不然演示时被其他人删库就尴尬了。演示话术方面我有三个建议。第一开门见山说出系统架构和技术栈Spring Boot Vue Redis MySQL前后端分离部署。第二按角色演示业务闭环先以家长身份登录发布一条需求再换成教员账号接单再换回家长确认直到完成一次课时和评价。第三特意挑一两个代表性的表和接口讲清楚比如课时包表的原子扣减SQL或者预约状态的流转逻辑展示你对底层设计的理解。5. 论文怎么写才能和代码呼应起来5.1 技术栈部分别再记流水账很多人的毕业论文技术选型那章写得像菜单Spring Boot是一个框架Vue是一个框架MySQL是数据库。其实老师更希望看到“为什么在这个场景用这个技术”。我当时是这样写的选用Spring Boot是为了快速构建坚固的后端微服务基础选用MyBatis-Plus是因为它的分页插件和条件构造器能显著减少单表查询代码量选用Vue和Element UI是因为RuoYi-Vue作为成熟前端脚手架提供了统一布局和权限管理组件我可以把精力放在家教业务页面上选用Redis缓存用户Token和热点数据比如热门家教老师列表和科目字典因为这类数据读多写少。每一条都对应到系统的一个真实需求论文的排版和答辩的底气都会完全不一样。5.2 关键图表怎么画论文里至少要有三张图系统总体架构图、业务流程图、数据库E-R图。架构图可以画成“前端浏览器 - Nginx - Spring Boot - MySQL/Redis”的分层结构业务流程图就把我第2节说到的闭环画出来E-R图直接根据数据表关系生成。这三张图有经验的人一眼就能看出系统设计完整完全可以支撑起“一体化”的定位。5.3 测试章节也是得分点毕设导师和答辩老师通常都会翻测试那一章。建议至少包含功能测试表格和接口测试截图。功能测试用边界值法列出测试用例比如课时包剩余0时能否继续确认、家长未登录能否查看教员列表等。接口测试用Postman或Apifox记录几个核心接口的请求和响应并把正常情况和异常情况都测一遍。这些材料会让整个项目的可信度上一个level。6. 实战心得做完这个项目后我对RuoYi-Vue的理解如果只让我说一点最重要的体会那就是用脚手架不是原罪只用了脚手架才是。RuoYi-Vue给了权限管理、代码生成、日志监控这些基础能力家教系统真正的价值在于我把“家庭教育的找老师、约课、消课、评价”整条业务链完整地落到了代码和页面上还处理了并发扣课这种真实工程问题。答辩时老师问我“你在这个项目里做了什么”我可以非常清晰地列出设计了15张业务表、完成了三端权限隔离、实现了业务状态机流转、将课时扣减优化为原子操作。每一句都有代码可验证。最后再分享一个小技巧如果你打算把这个项目扩展成求职作品可以往两个方向加料。一是接入微信支付或支付宝沙箱支付让课时包购买成为一个真实的交易闭环二是增加一个“在线试讲”模块使用WebRTC或声网实现一对一线上的音视频上课再结合课消系统这样项目就不再只是管理系统而是一个带互动能力的小平台了。代码开源也好、闭源也好都不影响你从中获得的最重要的东西把一个模糊的“家教系统”概念变成一套能跑、能演示、能解释清楚每一个设计决策的系统。这个能力才是毕设真正的交付物。本文还有配套的精品资源点击获取 基于RuoYi-Vue的家教系统毕设实战：二次开发与并发扣减
简介这是一套面向计算机相关专业本科生的毕业设计与课程设计实战项目基于主流开源框架 Ruoyi-Vue 构建家教一体化系统解决家教服务中教师管理、学生匹配、课程预约、评价反馈等核心业务场景适用于计科、人工智能、通信工程等专业学生开展毕设、课设或大作业开发。压缩包共708个文件涵盖303个Java后端逻辑文件、113个Vue前端组件、83个JS交互脚本、36个XML配置及5个YML环境配置文件辅以SQL建表脚本、SVG图标资源与多环境启动脚本如run.bat、package.bat整体体积仅5.36MB结构清晰、模块解耦度高。已有79人下载学习项目经完整测试并成功通过答辩平均评分96分附带可运行演示地址与详细README说明。读者可直接部署体验全流程功能亦可基于现有模块快速二次开发如拓展支付集成、消息推送或数据分析看板是兼具教学性、工程性与扩展性的高质量学习范例。 带“家教一体化系统”这个标题做毕设我一开始是有点犹豫的。市面上那么多开源项目光家教管理系统少说也能搜出三四套直接拿来改改交上去老师一问细节就露馅。但如果从零手写一个Vue前端加Spring Boot后端三个月都不一定够。后来我换了个思路不跟那些“纯原生”的项目比而是把RuoYi-Vue这种成熟脚手架当底座在它上面做家教业务系统的二次开发。这样一来系统管理相关的功能不用自己造轮子我又能把全部精力放在家教业务模块的设计和实现上最终做出来的系统功能完整、权限清晰、演示效果也够好答辩时讲起来底气很足。这篇就把整个项目从选型、功能拆解、二次开发、部署演示到答辩亮点的完整链路写出来给正在做RuoYi-Vue方向毕设或者课设的同学做个参考。尤其是那些想用现成脚手架但又怕被当成“纯搬运”的人我的经验是选型不是问题关键是你在选型之上做了什么。1. 为什么拿RuoYi-Vue当毕设底座是条捷径但不是偷懒1.1 RuoYi-Vue到底是什么值不值得用它做毕设RuoYi-Vue是一套基于Spring Boot、Spring Security、MyBatis-Plus、Vue 2/3、Element UI的前后端分离开发平台社区已经帮我处理好了很多通用功能登录认证、用户管理、角色权限、菜单管理、操作日志、定时任务、代码生成、通用导入导出、系统监控等等。对毕业设计而言这些功能恰恰是老师最常看的“系统完整性”部分。说实话每个同学都会纠结“用开源框架算不算抄袭”。我的理解是毕业设计的核心是考察你分析问题、设计系统、解决实际业务问题的能力而不是逼着你在2025年不用任何工具链从零写一个权限框架。RuoYi-Vue就好比工地上的脚手架你不需要自己焊钢管搭架子但你在架子上砌砖、布线、装窗户才是真正的活。搭建出来的“建筑”是你的家教系统不是那套脚手架。另外还有一个很现实的原因RuoYi-Vue有完整的代码生成功能。业务表建好之后可以自动生成前端的列表页、表单页、后端的Controller、Service、Mapper生成出来的代码风格统一、格式规范交给老师看也挑不出大毛病。这个对毕设进度的提升是决定性的。1.2 家教业务选它有哪些优势我选RuoYi-Vue的第二个原因是家教系统的业务复杂度刚好踩在“脚手架之上、定制之下”的黄金位置。先说复杂度。家教一体化系统如果只做最简单的“家长找老师、老师被联系”那功能太单薄撑不起一个像样的毕设。但要做到平台级的完整流程比如家长发需求、老师抢单、双方约课、课时记录、课消结算、评价互评工作量又不小。RuoYi-Vue提供的用户体系、权限模型、日志审计、数据字典帮我省掉了至少30%的重复劳动剩下的70%业务开发才是我要展示的核心。再说模块划分。RuoYi-Vue的后端是模块化结构有一个ruoyi-system模块管理用户和权限还有ruoyi-quartz处理定时任务我在实践中可以新增一个ruoyi-family模块来集中放家教业务相关代码。前端也是一样src/views下新增family目录和系统自带的system目录并列结构非常清晰。答辩PPT里即使只放一张项目目录截图老师也能一眼看出你确实是做了二次开发而不是简单套壳。1.3 这套方案适合什么样的毕设/课设题目说起来家教系统只是其中一个典型场景。RuoYi-Vue做底座实际上非常适合一大类管理系统型题目社区团购平台、二手交易平台、校园跑腿系统、在线预约系统、宠物寄养平台等核心都是“多角色、有流程、有状态流转、有权限控制”。只要是这种业务你按我这篇文章的思路走把“家教”替换成你的主体对象就能复制。所以如果你是本科毕设、专科毕业设计或者课程设计需要交付一个能演示的系统这个选型很合适。但如果你是研究生课题需要推导算法、搞分布式架构、写并发设计那RuoYi-Vue只能当辅助后台论文重点还是要放到算法研究上。2. 家教一体化系统的功能边界先画出业务地图再动手2.1 三方角色和他们的核心诉求我写代码前花了将近一周时间梳理需求这一周在后来的开发中换来了巨大的效率回报。家教一体化系统我最终定义了三种角色家长、教员家教老师、系统管理员。家长端的诉求是注册登录后能发布家教需求、浏览教员列表、查看教员详情和评价、向教员发起预约申请、确认上课时间、记录孩子已上课时、核销课时包同时能对上完课的教员进行评价。教员端的诉求是接收和搜索家教需求、提交接单申请、管理自己的可上课时间、查看待上课日程、记录课时完成情况、查看收入统计、回访家长评价。管理员端的诉求是审核家长和教员的注册信息、下架违规需求、管理学科分类和年级分类、查看平台交易和课消数据、管理公告通知。这些需求听起来很常规但它们组合在一起就形成了完整业务闭环也是后面开发时划分模块的天然依据。2.2 核心业务闭环是怎么跑的我给这个系统设计的主线流程是家长发布需求 - 教员浏览并申请接单 - 家长在申请列表中选择教员 - 双方面对面或线上沟通 - 家长为教员创建课时包 - 上课后在系统中确认课时抵扣 - 课时结束触发评价入口 - 双方互评后数据进入教师评分体系。这套闭环画成流程图非常漂亮尤其适合放在毕业设计论文的“业务需求分析”那一章。关键是它把“人找课”变成了“课找老师”而且每个状态都有归属方系统在任意节点都要有状态更新和记录这就体现了“一体化”的含义。2.3 数据表设计15张业务表背后的设计逻辑家庭业务模块我最终建了15张表这里只挑核心的几张讲一下设计思路。家长需求表需求表 是业务起点包含标题、详细描述、孩子年级、学科、期望上课区域、期望时薪、状态、家长ID、发布时间。教务表必须单独建因为一个需求可能被多个老师申请。教员的申请记录表用于承接接单流程包含需求ID、教员ID、申请说明、状态。教员和孩子的关联通过课时包表关联。课时包表是重点包含家长ID、教员ID、剩余课时、总课时、有效期开始结束时间、状态。每次上课后通过课时消费详情表记录一条课时消费记录关联课时包ID和上课时间从而实现课消闭环。评价表存储家长对教员、教员对家长的双向评价评分等级1到5。这些表之间的关系我建议用一张整体ER图先画出来再同步到数据库设计文档里。开发时直接用RuoYi-Vue菜单添加业务菜单把接口挂在对应的目录下。2.4 用RuoYi自带能力覆盖通用管理功能业务模块之外系统管理层面我基本没有额外开发用的是脚手架自带的能力系统用户用于管理管理员账号角色管理用来给不同角色分配菜单权限部门管理映射平台组织的区域结构菜单管理用来配置前端路由数据字典管理学科分类和订单状态。这一块不管你是教育系统还是电商系统基本都是差不多的好处是答辩的时候你不用再从零解释用户密码怎么加密的、权限怎么鉴权的直接说“Spring Security JWT Redis”就是标准答案。不过有一点要特别提醒RuoYi自带的用户管理表在普通业务系统里通常会当成“后台用户”来用但在家教系统里家长和教员都是独立的业务主体我更推荐在业务侧建自己的家长表、教员表再和RuoYi的sys_user表通过外键关联。这样业务逻辑更清晰也不容易和系统用户的管理逻辑纠缠在一起。3. RuoYi-Vue二次开发实操从代码生成到业务接口落地3.1 环境准备和项目导入我使用的环境是JDK 1.8官方新版也可以上JDK 17但为了稳妥我还是用了8、MySQL 5.7、Redis 6.x、Node 14.17Maven 3.6。你如果电脑上装的是新版JDK跑RuoYi-Vue老版本时记得去pom.xml里看下spring-boot版本是否兼容不兼容的话要么升级项目依赖要么本地装多个JDK切换。后端导入直接用IDEA打开RuoYi-Vue根目录等待Maven把依赖拉完。前端用VSCode或WebStorm打开ruoyi-ui目录执行npm install这一步依赖包比较多网速慢的同学可能要等很久。我建议在npm前先设置淘宝镜像源能省不少时间npm config set registry https://registry.npmmirror.com装完依赖后启动后端进入ruoyi-admin模块运行Application主类再把前端跑起来npm run dev默认访问 http://localhost:8080 初始账号 admin/admin123。能跳到登录页并正常登录说明脚手架本身没有任何问题。3.2 建表之后用代码生成器提速RuoYi-Vue的代码生成功能是毕设项目的核武器。先在数据库里建好业务表然后在系统管理→代码生成里“导入”对应的表配置生成信息选择生成模板包名比如com.ruoyi.family点击生成就会自动下载一个压缩包。这里有一个必须注意的点代码生成器生成的代码默认是按照“单表无关联”来生成CRUD的但家教系统里的需求表、预约表、课时包表之间是有外键关系的。我生成的业务表代码只把它当基础的增删改查涉及到多表联查、业务状态变化的接口我还是手写。别指望生成器解决所有问题它只是帮你把增删改查和前端表单页面搭起来省掉写样板代码的时间。3.3 手写核心业务接口的套路以“家长发布需求”为例前端表单提交请求到后端流程是这样的前端拿到当前登录用户的ID通过Pinia/Vuex中的用户信息获取然后随表单一起提交。后端在Controller里接收DTO对象通过UserId从数据库查家长信息。服务层创建需求记录初始状态为“招募中”。开发者将整个操作包在一个事务里如果插入失败会自动回滚。Service层代码示意Transactional(rollbackFor Exception.class) public Long publishDemand(DemandDTO dto) { Demand demand new Demand(); BeanUtils.copyProperties(dto, demand); demand.setStatus(DemandStatus.RECRUITING.getCode()); demand.setPublisherId(SecurityUtils.getUserId()); demandMapper.insert(demand); return demand.getDemandId(); }关键点在于所有业务写入操作都要加上事务控制因为家教业务中经常涉及“预约申请通知”“确认接单更新需求状态”这种耦合更新不加事务容易产生脏数据这也是答辩时老师最爱问的点。3.4 权限控制和菜单配置RuoYi的权限控制基于RBAC模型后端接口使用PreAuthorize注解做权限校验。比如管理员才能删除需求接口上加PreAuthorize(ss.hasPermi(family:demand:remove))前端菜单管理里给每个按钮分配一个权限标识符和这个注解里的字符串对应。这样家长角色的菜单只能看到浏览需求和预约教员角色才能看到接单入口管理员才有删除、审核按钮。我建议在开发初期就把权限标识设计好围绕固定前缀规范写避免后期全部返工。3.5 前端页面开发中的组件复用前端开发中我一直用的是RuoYi自带的基础框架Element UI组件库已经内置。家教系统的核心页面基本是表格弹窗表单的结构。列表页用Table组件展示需求列表搜索区用Form加几个输入框和下拉选择详情用Dialog嵌套。做课消记录和评价时我用到了el-tabs将多个子页面整合在一个详情弹窗内比如“基本信息”“课时记录”“评价记录”三个Tab页这种展现方式很实用页面也显得功能完善。有一个值得分享的小技巧RuoYi前端封装了很多自定义指令和全局方法比如this.$modal.msgSuccess(操作成功)这类反馈提示以及clickhandleUpdate(row)这类表单回显套路。实际操作时多翻翻脚手架自带的管理页面学它们怎么处理loading状态和空数据比自己瞎写好看很多。4. 从本地跑通到部署上线一路踩过的坑和最终演示方案4.1 数据库初始化最容易踩的坑我第一次导入ruoyi.sql的时候直接丢进Navicat执行大概执行到一半就报了语法错误。原因很简单命令行执行和工具导入对SQL文件编码的兼容性不同且源文件里包含了一些注释段Navicat对某些编码字符处理会出现问题。正确做法是先用命令行执行mysql -uroot -p your_database ruoyi.sql然后再用Navicat连接检查表数量和信息是否完整。如果只想导入业务表我会单独导出一个family_business.sql只包含新业务表的建表语句和初始数据这样既降低出错概率也方便给老师演示“系统初始化的完整步骤”。4.2 前端打包后接口404的问题本地开发时前端通过Vite代理解决了跨域问题所以前端能访问到后端接口。但一旦执行npm run build:prod生成的dist目录需要在Nginx里配置反向代理把/api路径转发到后端8080端口。我第一次没配代理直接双击index.html打开结果页面空白一片控制台里全是跨域报错。搞定Nginx配置后还需要注意history路由模式下的fallback配置否则刷新任意子路由都会404。一个比较省事的演示方案是如果只是答辩演示完全不用买服务器直接在前端和后端都保持本地开发环境浏览器访问localhost:8080端口即可。但如果老师要求线上演示我建议用一台轻量服务器在上面跑Nginx和Spring Boot jar包。后端打包命令mvn clean package -DskipTests java -jar ruoyi-admin.jar前端dist目录用Nginx托管把root /usr/share/nginx/html;指向dist目录就行。4.3 一次真实联调问题复盘课时“超卖”了这是我整个项目里遇到的最有意思的bug也成了我答辩时最能讲的实战案例。业务场景是家长创建了A教员的30节课时包一天下午同时有两个“上课确认”请求打过来家长在手机端连续点了两次确认。结果系统显示课时包剩余课时从5节变成了3节一查数据表发现有两个“课时消费”记录各扣了1节但实际上这同一节课被重复确认了两次。这个问题的根因在于扣减课时的SQL是“先查询剩余课时再在Java代码里减1最后update”两个请求并发读取到相同的剩余课时自然就会各写回一个错误的值。解决办法是改成数据库层面的原子扣减update course_package set remaining_hours remaining_hours - 1 where package_id #{packageId} and remaining_hours 0同时给课时消费表加上唯一索引防止同一节课重复插入。这个案例老师非常感兴趣因为它是典型的并发一致性问题直接把毕设从“业务堆叠”拔高到了“工程实践”。4.4 演示地址和演示话术的打磨如果自己不想买服务器又想给老师一个“在线演示”的震撼效果可以把前端部署到GitHub Pages或Gitee Pages后端接口写成本地内网穿透或服务器部署。但这里要非常注意公开的演示环境必须有完善的数据权限和风控措施不然演示时被其他人删库就尴尬了。演示话术方面我有三个建议。第一开门见山说出系统架构和技术栈Spring Boot Vue Redis MySQL前后端分离部署。第二按角色演示业务闭环先以家长身份登录发布一条需求再换成教员账号接单再换回家长确认直到完成一次课时和评价。第三特意挑一两个代表性的表和接口讲清楚比如课时包表的原子扣减SQL或者预约状态的流转逻辑展示你对底层设计的理解。5. 论文怎么写才能和代码呼应起来5.1 技术栈部分别再记流水账很多人的毕业论文技术选型那章写得像菜单Spring Boot是一个框架Vue是一个框架MySQL是数据库。其实老师更希望看到“为什么在这个场景用这个技术”。我当时是这样写的选用Spring Boot是为了快速构建坚固的后端微服务基础选用MyBatis-Plus是因为它的分页插件和条件构造器能显著减少单表查询代码量选用Vue和Element UI是因为RuoYi-Vue作为成熟前端脚手架提供了统一布局和权限管理组件我可以把精力放在家教业务页面上选用Redis缓存用户Token和热点数据比如热门家教老师列表和科目字典因为这类数据读多写少。每一条都对应到系统的一个真实需求论文的排版和答辩的底气都会完全不一样。5.2 关键图表怎么画论文里至少要有三张图系统总体架构图、业务流程图、数据库E-R图。架构图可以画成“前端浏览器 - Nginx - Spring Boot - MySQL/Redis”的分层结构业务流程图就把我第2节说到的闭环画出来E-R图直接根据数据表关系生成。这三张图有经验的人一眼就能看出系统设计完整完全可以支撑起“一体化”的定位。5.3 测试章节也是得分点毕设导师和答辩老师通常都会翻测试那一章。建议至少包含功能测试表格和接口测试截图。功能测试用边界值法列出测试用例比如课时包剩余0时能否继续确认、家长未登录能否查看教员列表等。接口测试用Postman或Apifox记录几个核心接口的请求和响应并把正常情况和异常情况都测一遍。这些材料会让整个项目的可信度上一个level。6. 实战心得做完这个项目后我对RuoYi-Vue的理解如果只让我说一点最重要的体会那就是用脚手架不是原罪只用了脚手架才是。RuoYi-Vue给了权限管理、代码生成、日志监控这些基础能力家教系统真正的价值在于我把“家庭教育的找老师、约课、消课、评价”整条业务链完整地落到了代码和页面上还处理了并发扣课这种真实工程问题。答辩时老师问我“你在这个项目里做了什么”我可以非常清晰地列出设计了15张业务表、完成了三端权限隔离、实现了业务状态机流转、将课时扣减优化为原子操作。每一句都有代码可验证。最后再分享一个小技巧如果你打算把这个项目扩展成求职作品可以往两个方向加料。一是接入微信支付或支付宝沙箱支付让课时包购买成为一个真实的交易闭环二是增加一个“在线试讲”模块使用WebRTC或声网实现一对一线上的音视频上课再结合课消系统这样项目就不再只是管理系统而是一个带互动能力的小平台了。代码开源也好、闭源也好都不影响你从中获得的最重要的东西把一个模糊的“家教系统”概念变成一套能跑、能演示、能解释清楚每一个设计决策的系统。这个能力才是毕设真正的交付物。本文还有配套的精品资源点击获取