基于RuoYi-Vue的家教系统开发实战：从架构到避坑全指南

简介：这是一套面向计算机相关专业本科生的毕业设计与课程设计实战项目——基于Ruoyi-Vue框架开发的家教一体化系统，适用于计科、人工智能、通信工程等方向的学生完成毕设、课设或大作业，也适合初学者通过完整业务系统理解前后端协同开发流程。资源包共708个文件，涵盖303个Java后端逻辑文件、113个Vue前端组件、83个JS交互脚本、36个XML配置及3个SQL数据库脚本，辅以bat自动化构建脚本和多环境配置文件（.env.development等），整体压缩包仅5.36MB，结构清晰、模块解耦明确。已有79人下载学习，项目经实机部署验证，所有功能模块均可正常运行，答辩平均分达96分；配套README详述启动步骤与模块说明，支持二次开发与功能扩展，可直接用于演示、教学或项目立项原型。

1. 项目定位与核心需求拆解

1.1 家教行业的业务痛点

做毕业设计选题的时候，我见过太多人一上来就挑"学生管理系统""图书管理系统"这类老掉牙的题目，答辩时老师一眼就能看穿工作量。家教一体化系统这个方向，表面看也是管理类系统，但它的业务链条比传统的单角色CRUD要长得多，涵盖了用户注册、课程发布、在线预约、课时管理、评价反馈、统计分析等多个环节，非常适合用来展示前后端分离开发的完整能力。

先看家教行业的实际场景。家长想给孩子找个靠谱的老师，靠的是朋友介绍、线下中介或者各种信息平台。老师想接单，往往也是通过微信群、熟人转介绍。这个过程中有几个痛点特别明显：第一，供需信息不透明，家长找不到合适的老师，老师找不到稳定的生源；第二，试听、排课、课时记录全部靠人工沟通，时间一长就乱；第三，课消统计和费用结算没有统一口径，容易扯皮。家教一体化系统要解决的，就是把这些线下散落的流程搬到线上，让家长、老师、平台管理员三方在同一个系统里完成信息匹配和服务闭环。

把痛点翻译成系统需求，核心就一句话：让不同角色在统一的平台上完成信息发布、预约、确认、执行、评价的完整闭环。围绕这句话往下拆，系统就至少需要三类角色的支撑——管理员做平台运营和审核，教师做课程供给和服务执行，学生/家长做需求发起和服务反馈。至于具体功能，后面第2章会展开。

1.2 为什么选 RuoYi-Vue 作为基座

确定了业务方向后，接下来就是技术选型。我见过不少同学直接裸写Spring Boot加Vue，从零搭权限系统、用户系统、日志系统，结果光基础功能就写了一两个月，留给业务功能的时间所剩无几。这个项目选型RuoYi-Vue，核心原因有三个。

第一，RuoYi是国内使用率极高的开源后台管理框架，基于Spring Boot和Vue实现前后端分离，自带完整的RBAC权限体系、用户管理、菜单管理、字典管理、操作日志、定时任务、代码生成器。这些是几乎所有后台系统都需要的通用能力，不需要重复造轮子。第二，RuoYi的代码生成器可以根据数据库表直接生成Java代码和Vue页面，对于毕业设计这种需要赶时间的项目来说，相当于把CRUD部分的开发效率提了一倍以上。第三，RuoYi的社区活跃度很高，遇到问题随便一搜就有解决方案，对经验不够丰富的学生党来说，这一点太重要了。

当然，选型RuoYi也有需要注意的地方。它的框架代码风格偏传统，没有Spring Cloud那套微服务体系，但这恰恰是毕业设计该有的复杂度——单体应用加前后端分离，既能展示技术能力，又不会把工程量撑爆。另外，RuoYi自带的功能默认是英文菜单（部分版本）或通用业务，你需要花时间把菜单、权限配置成家教业务的专属结构。这块我在第4章实操部分会详细说。

2. 系统功能模块全解

2.1 平台管理端：管人、管课、管数据

先看管理端。管理端是平台运营方使用的后台，也是RuoYi框架原本就很擅长的部分。核心功能包括管理员管理、教师审核、课程科目管理、订单监控、数据统计等。

教师入驻审核是管理端一个非常重要的功能。家长对老师的信任度直接决定成交率，所以系统里我会设计一个"教师认证"的流程。用户注册为教师后，需要提交资质信息（比如学历认证、教学经历），状态默认为"待审核"。管理员登录后台看到待审核列表，点击详情查看资料，审核通过后教师在用户端的"教师认证"标识才会点亮。这个功能本质上是RuoYi通用用户表的一个状态字段扩展，但业务价值很高，写论文和答辩时都能拿出来讲。

订单监控和课时消课监控也建议放在管理端。家长预约课程、教师确认排课、实际上课打卡、课时费结算，这些关键节点的数据都应该在管理端有可视化的列表和统计图表，方便平台方知道系统每天产生了多少交易、有多少课被消化掉。

2.2 教师端：课程发布与课时管理

教师端是业务链条里的供给方。教师在完成认证后，可以在系统里发布课程，课程信息包括课程名称、适用年级、科目、授课方式（线上/线下）、课时单价、可授课时段。这块的难点在于数据建模，一门课程对应一个教师，一个教师可以发布多门课程，数据库里要用外键关联好。

排课管理是教师端的核心，也是最容易出Bug的地方。一个合理的排课系统需要做到：教师在某个时间段已经排了课，就不能再排新的课；家长预约某个时段后，其他家长看不到这个时段。最简单的实现思路是设计一张"可用课时表"，教师先维护自己未来N天的可授课时段，家长预约时段后把状态改成"已预约"，冲突判断在生成可授课时段时做一次即可。如果想让系统更智能，可以再加一个排课冲突校验的工具类，但毕设阶段做到状态机层面就够了。

课时记录同样值得做细。每完成一节课，教师端可以提交课时小结，记录上课内容、学生表现、课后练习建议。家长端可以看到这些记录，形成服务的留痕。课时记录表要和订单表、课程表做关联，同时在管理端能够按教师、按时间维度统计课时消课情况，方便后续做课时费结算。

2.3 学生与家长端：找老师、约课、看反馈

学生/家长端的消费路径可以拆成两条：一条是找老师，一条是上完课后的反馈闭环。

找老师的场景，系统需要提供课程搜索和教师列表。搜索条件应该包括科目、年级、授课方式、价格区间、好评率排序，这些条件在SQL层面都可以通过RuoYi生成的查询条件扩展实现。课程详情页要展示教师信息、课程介绍、课时单价、已购人数和历史评价。这里我要提一个热词里的点——有同学问vue播放m3u8怎么处理。如果课程包含线上录播视频，视频回放建议用m3u8格式做切片，前端用video.js配合hls.js播放，兼容性比直接放mp4好很多，拖动进度也流畅。把视频地址放在课程详情里，已经购买的学员可以点击播放，这是系统的加分项。

反馈闭环包括预约、支付（模拟）、上课打卡、评价。考虑到毕业设计不接入真实支付，可以用一个"预约下单"按钮代替支付环节，订单状态从"待上课"到"已完成"。上完课后家长可以给教师打分和写评价，评价数据反哺到教师列表的好评率和"精选评价"模块。这样一个消费闭环就完整了。

2.4 核心业务闭环与状态机设计

整个系统最核心的业务闭环是：教师发布课程 -> 家长搜索浏览 -> 家长预约下单 -> 教师确认排课 -> 按时上课 -> 提交课时记录 -> 家长评价 -> 管理员统计分析。

围绕这个闭环，订单表的状态设计至关重要。我的建议是订单状态至少要有这几个：待确认（家长下单后等待教师确认）、待上课（教师已确认）、已完成（课时记录提交且家长评价完成）、已取消（任何一方在待确认状态下都可取消）。在代码层面，这个状态机可以用一个枚举类来定义，在Service层做状态流转的校验。

这里给一个通用的状态校验模板思路：

public enum OrderStatus { PENDING_CONFIRM(0, "待确认"), TO_BE_HELD(1, "待上课"), COMPLETED(2, "已完成"), CANCELLED(3, "已取消"); private final Integer code; private final String desc; // 构造方法、getter... }

每次更新订单状态前，先用当前状态和期望流转的目标状态做一次合法性校验，不允许跳状态。这个设计在答辩时是很好的亮点，说明你考虑了业务健壮性，而不只是写了增删改查。

3. 技术栈选型与架构分析

3.1 RuoYi-Vue 的架构成熟度

RuoYi-Vue这个组合在毕业设计里的地位，相当于手机圈的"水桶机"——它未必有最惊艳的单项能力，但整体素质均衡，什么场景都能打。前端是Vue 2 + Element UI + Vuex + Vue Router，后端是Spring Boot + MyBatis + Shiro（或Spring Security，取决于你下的版本），配套MySQL和Redis。对于毕设级别的项目，这套组合无论从开发效率还是答辩展示角度，都完全够用。

我尤其想说的是RuoYi的权限设计。它基于RBAC（Role-Based Access Control，基于角色的访问控制）模型，用户-角色-菜单三层解耦。你在"系统管理-角色管理"里给某个角色勾选菜单权限，该角色下的用户登录后只能看到被授权的菜单和接口。对于家教系统来说，管理员、教师、家长天然就是三种角色，用RuoYi的权限体系可以非常清爽地完成界面隔离和数据权限隔离。这里的数据权限不只是菜单级别，RuoYi还有数据范围控制，可以按角色配置仅查看本人数据，教师端只能用自己ID查询课程数据，就是这个机制实现的。

3.2 后端目录结构与分层思路

第一次打开RuoYi后端项目的人，往往会对着一大堆模块发懵。我这里逐个讲清楚。RuoYi-Vue后端是一个Maven多模块工程，主要模块包括ruoyi-admin、ruoyi-framework、ruoyi-system、ruoyi-common、ruoyi-quartz、ruoyi-generator。

• ruoyi-admin：启动模块，包含Controller层，也是系统的入口。
• ruoyi-framework：框架核心配置，包括安全配置、拦截器、AOP切面、Redis配置等。
• ruoyi-system：业务模块，包含Service和Mapper。
• ruoyi-common：公共工具模块，包括通用常量、工具类、统一返回结果。
• ruoyi-quartz：定时任务模块。
• ruoyi-generator：代码生成模块。

在RuoYi中写业务代码，Controller放在ruoyi-admin的web目录下，Service接口和实现放在ruoyi-system的service目录，Mapper接口和XML放在ruoyi-system的mapper目录。做家教系统时，建议单独包一层，比如com.ruoyi.web.controller.tutor、com.ruoyi.system.service.impl.TutorCourseServiceImpl，这样自己的业务代码和框架代码之间有清晰的边界，后续升级框架版本也不会互相干扰。

分层设计上，我强烈建议遵守RuoYi自带的规范：Controller只做参数接收、调用Service、返回结果，Service层写业务逻辑，Mapper层访问数据库。不要图省事在Controller里怼SQL，后期维护会非常痛苦。RuoYi的AOP日志切面默认记录了所有Controller的访问日志，操作日志记录在sys_oper_log表，这在答辩演示环节很有展示价值。

3.3 前端目录结构与Vue实践

前端Vue项目默认是vue-element-admin风格，核心目录包括：

• src/api：按业务模块拆分的接口定义文件，比如tutorCourse.js、tutorOrder.js。
• src/views：页面组件，一个页面通常对应一个目录，目录里包含index.vue。
• src/components：公共组件，比如上传组件、富文本编辑器。
• src/router：路由配置。RuoYi支持后端动态路由，菜单从后端数据库读取，前端根据菜单配置动态生成路由表。
• src/store：Vuex状态管理，存放用户信息、权限标识、标签页状态。

这里和热词里对应的几个Vue知识点可以串起来说。比如vue-router中，RuoYi默认使用history模式，但打包部署到Nginx时需要配置try_files，否则刷新页面会404。有同学在本地npm run dev跑得好好的，一部署就白屏，九成是这个问题。

再比如vue keep-alive。RuoYi内置了标签页导航功能（也就是热词里的$tab.closeOpenPage相关功能），点击左侧菜单会在顶部生成标签页，切换标签页时默认会缓存页面状态。如果你在做课时列表页，发现切换路由再回来时，el-table滚动条位置或者查询条件丢了，那就是keep-alive缓存策略没生效。RuoYi路由配置里meta有个keepAlive字段，只有设为true的页面才会被<keep-alive>包裹缓存。打开代码看src/layout/components/AppMain.vue，逻辑很清晰：

<keep-alive> <router-view v-if="$route.meta.keepAlive" /> </keep-alive> <router-view v-if="!$route.meta.keepAlive" />

如果你的列表页在切换课程分类后表格滚回顶部，重点检查页面name和路由meta.keepAlive是否匹配。这个坑我在第5章还会提到。

vue computed的计算属性在课时费展示这类场景很实用。比如教师首页要汇总本月完成课时数和预期收入，完全可以用computed基于list数据做计算，数据变化时视图自动更新，比在methods里手动累加优雅得多。

3.4 数据库设计要点

数据库设计是毕业设计的核心评分点之一。家教系统我建议至少准备这些核心表：用户表（可以在RuoYi的sys_user上扩展）、教师认证信息表、课程表、可预约课时表、订单表、课时记录表、评价表、科目字典表。

课程表建议这样设计：

可预约课时表是这个系统的设计亮点。字段包括id、course_id、teacher_id、start_time、end_time、status（可用/已预约/已完成）。每次教师新增排课时，在Service层做一次时间段重叠校验。这里给个SQL思路：

SELECT count(*) FROM t_teacher_slot WHERE teacher_id = #{teacherId} AND status != 'CANCELLED' AND (start_time < #{endTime} AND end_time > #{startTime})

如果查出来大于0，说明该时间段已有排课，返回提示。

3.5 关键技术点：权限、文件上传、地图与视频

家教系统里还有几个值得单独写进论文的关键技术点。

权限这块，RuoYi后端默认用@PreAuthorize("@ss.hasPermi('tutor:course:add')")这种注解做接口鉴权，前端用v-hasPermi指令控制按钮显示。做毕设时建议把每个业务接口的权限标识都配置好，演示的时候管理员账号和教师账号登录看到的界面完全不同，这个效果非常直观。

文件上传在RuoYi里开箱即用，本地路径配置在application.yml的ruoyi.profile字段。教师上传资质证明、课程封面都走这个接口。注意如果要部署到服务器，需要把上传路径改成服务器上的绝对路径，并且给Nginx配置一个静态资源映射，否则上传的图片无法通过URL访问。

地图和视频是加分项。如果系统做线下家教，希望教师列表展示地理位置，可以用腾讯地图JavaScript API GL，在Vue组件里通过script标签引入SDK，然后用经纬度做标记点展示。注意需要去控制台申请Key，开发阶段可以不校验域名白名单，部署后必须配置。视频方面，如果是录播课在线播放，m3u8格式需要前端用hls.js做转换，Element UI本身没有封装播放器，可以自己封装一个video组件，把hls.js实例挂到video标签上。

4. 实操部署与二次开发指南

4.1 本地环境准备

先把环境搞定。RuoYi-Vue官方推荐的运行环境是：JDK 1.8、MySQL 5.7或8.0、Redis 3.x以上、Maven 3.6以上、Node.js 12以上。如果你拿到的是标题里这个打包好的.zip项目，解压后应该是ruoyi-ui（前端）和后端多模块工程两个目录。

后端Idea打开时，记得先配置Maven的settings.xml指向阿里云镜像，不然下载依赖能让你等到怀疑人生。JDK版本这里多说一句，热词里有"ruoyi docker jdk17"，说明有人试着用JDK17跑RuoYi。坦率讲，RuoYi官方推荐JDK1.8，如果你图省事就用1.8；如果老师要求高版本JDK，你得处理CGLIB代理和反射相关的兼容问题，这个折腾成本不低，非必要不建议。

前端依赖安装是另一个大坑。有同学npm install之后报"the project can not found node_modules"，本质就是依赖没装全。建议使用npm install命令时如果失败，优先检查Node版本和registry源。也可以用淘宝镜像源npm config set registry https://registry.npmmirror.com，实测下载速度能快好几倍。

4.2 数据库初始化和配置调整

数据库初始化分两步。第一步，创建数据库，字符集选utf8mb4（注意不是utf8，utf8mb4才能完整支持中文和特殊字符）。第二步，导入RuoYi自带的ry_xxx.sql脚本，这个文件在项目sql目录下，导入后系统就能跑起来。如果你拿到的是已经做好的家教系统项目，压缩包里应该还有一份业务库的SQL，里面应该包含t_course、t_order这些业务表。导入顺序很重要：先导RuoYi基础SQL，再导业务SQL。

数据库连接配置在ruoyi-admin/src/main/resources/application-druid.yml里。需要改三处：url中的数据库地址、username、password。如果MySQL端口不是默认的3306，记得一并改掉。Redis配置在application.yml里，默认连127.0.0.1:6379，如果你本机Redis有密码，也要填上。

注意：RuoYi启动时会检查Redis连接，Redis没启动的话后端会一直报错，所以本地跑项目之前，一定先启动Redis服务。我见过太多同学在这里卡一晚上。

4.3 后端启动验证

后端启动比较简单，找到ruoyi-admin模块里的RuoYiApplication类，右键运行。日志里如果出现"Started RuoYiApplication"字样，说明启动成功。默认端口8080，启动后建议先用浏览器或Postman访问http://localhost:8080，如果能返回一个"服务启动成功"之类的提示，就说明后端没问题。接口文档方面，RuoYi自带Swagger，访问路径是/swagger-ui/index.html，可以快速查看所有Controller接口的入参和出参，调试业务接口时很有用。

4.4 前端启动与环境变量配置

前端项目启动前，先看根目录的.env.development文件，里面写了VUE_APP_BASE_API这个环境变量，默认是/dev-api，前端通过Vue CLI的代理把请求转发到后端8080端口。代理配置在vue.config.js里，代码类似：

proxy: { '/dev-api': { target: 'http://localhost:8080', changeOrigin: true, pathRewrite: { '^/dev-api': '' } } }

这个配置的意思是，前端请求/dev-api/system/user/list会被转发到http://localhost:8080/system/user/list。如果后端启动在其他端口，改这里的target即可。

在ruoyi-ui目录下执行npm install，装完依赖后执行npm run dev，启动成功后浏览器访问http://localhost:80（或控制台提示的端口），用admin账号登录。注意第一次安装依赖时间可能比较长，耐心等待。如果npm install中途报错，可以把node_modules目录删掉重新装，这个操作我干过不下十次。

4.5 二次开发：从建表到页面生成

拿到项目后，你肯定要改造成自己的家教系统。RuoYi的代码生成器是整个二次开发流程里效率最高的一环，强烈建议用好。

第一步，在数据库里建好你的业务表，注释要写得规范，字段要有备注，因为生成器会读取注释作为代码的说明。第二步，在系统工具_代码生成里，选择数据源，找到刚才建的表，点击导入。第三步，配置生成信息，包括类名（比如TutorCourse）、包名（com.ruoyi）、模块名（tutor）、生成模板（单表或树表）。生成方式可以选"按包下载"，会生成一个zip。第四步，把zip里的文件解压到对应目录：controller放到ruoyi-admin，service和mapper放到ruoyi-system，前端vue文件放到src/views/tutor下，API文件放到src/api/tutor下。第五步，在菜单管理里创建菜单，并给菜单添加按钮权限标识，把权限标识配给管理员角色。第六步，重启后端，刷新前端，新页面就出来了。

这个过程我在实际跑通之后最大的感受是：RuoYi生成器生成的代码可以跑，但业务逻辑绝不能只靠生成器。生成的页面是通用的增删改查，你要在此基础上增加预约按钮、排课时间选择器、评价星级组件等业务元素。代码生成器解决的是基础框架问题，业务价值还是要靠手动开发。

5. 常见问题与避坑记录

5.1 环境启动类问题

后端启动报"Application run failed"、端口占用、数据库连接失败，这类问题占毕设排查的一半。端口占用最简单：netstat -ano | findstr 8080（Windows）或lsof -i:8080（macOS/Linux）找到占用进程，杀掉即可。数据库连接失败，重点看application-druid.yml里url的时区参数serverTimezone=Asia/Shanghai，这个不设置的话MySQL 8.x必然报时区错误，连不上数据库。

Redis连接失败的话，先确认Redis是否启动。Windows命令行启动Redis直接把redis-server.exe拖进终端回车即可；macOS如果装了Homebrew，brew services start redis命令搞定。还有一个小概率问题：Redis设置过密码但配置里没填，或者在配置里填了密码但Redis改成了无密码模式，这两种都会导致认证失败。

5.2 RuoYi框架认知类问题

前端登录后菜单空白，是新手上路最大的拦路虎。原因通常是以下几点之一：数据库里菜单配置没导入完整、当前登录用户的角色没有分配菜单权限、动态路由没加载成功。排查思路是先看接口返回，登录后打开开发者工具，Network里找getRouters这个请求，看返回的JSON里是否包含菜单数据，如果返回为空，回数据库检查sys_menu表里是否有对应菜单以及sys_role_menu关联是否正确。这个排查流程走一遍，你就能理解RuoYi动态路由的加载机制了。

还有同学问RuoYi和Spring Security版本的问题。RuoYi-Vue官方有两个分支：RuoYi-Vue基于Spring Security，RuoYi-Vue旧版本基于Shiro（Shiro版本使用单表登录）。下载项目时看清楚是哪个版本，因为两者的权限注解和登录逻辑写法不同。一般新版RuoYi-Vue默认是Spring Security，代码里用@PreAuthorize注解做权限控制，密码加密用BCrypt。如果看到网上教程用的是@RequiresPermissions，那可能是老版本的Shiro写法，别直接照抄。

5.3 Vue前端类问题

热词里"vue is not defined"这种报错，通常是忽略了对Vue的引入方式。在Vue 2项目中组件内用Vue对象时不要忘记import Vue from 'vue'；新版Element UI按需引入时也要注意Vue.use的调用顺序，顺序错了同样会报错。

"node_modules找不到"的问题前面提过，这里再补充一个操作建议：不要用cnpm，它虽然快但依赖的目录结构和npm有些差异，RuoYi这类严格的项目可能跑出奇怪的Bug。实在要用镜像，直接设置npm官方registry的镜像源，依然用npm命令操作，最稳。

热词里还有"vue devtools插件下载"。调试Vue项目强烈建议安装Vue Devtools，Chrome插件商店直接搜Vue.js devtools安装即可，登录页面和菜单页面打开可以看到组件树和Vuex状态。排查"菜单为何空白"时，在Devtools里看store里的permission路由数组是否被正确赋值，能快速定位问题环节。

5.4 业务实现类问题

排课时间冲突，是家教系统里最容易出现的业务Bug。仅仅靠前端禁用某些时间段不够，因为用户可以同时开两个页面提交。后端Service层必须做校验，逻辑就是前面给的重叠区间查询SQL。实际开发中建议再加一层数据库乐观锁或唯一索引，防止并发请求穿透校验，不过毕设阶段能把Service校验做好就已经够优秀了。

课时状态流转错乱，常见原因是页面多次点击提交按钮。解决方案是在前端提交后给按钮加loading状态，同时后端在状态流转前做判断，状态不匹配直接抛异常。RuoYi的@Service事务管理默认只回滚RuntimeException，业务异常如果要回滚，需要自己抛出RuntimeException类型，或者使用@Transactional(rollbackFor = Exception.class)注解。这块是面试和答辩的高频问题，值得提前准备理解。

使用腾讯地图展示家教位置时，有一个常见坑：地图初始化时容器还没渲染完成，导致地图显示空白。解决办法是在Vue的nextTick回调里初始化地图组件：

this.$nextTick(() => { this.map = new TMap.Map(this.$refs.mapContainer, {...}); });

如果是列表循环多个地图组件，还需要注意lat和lng的类型，接口返回的坐标可能是字符串，地图API要求数字，提前Number()转换一下，否则标记点不显示。

m3u8视频播放失败，排查方向如下：第一，确认视频文件本身能不能通过浏览器直接访问；第二，hls.js的CORS配置，如果视频文件在OSS或CDN上，跨域响应头必须正确；第三，如果是混合内容（HTTPS页面引入HTTP视频），浏览器会直接拦截，本地开发用http://localhost问题不大，部署到HTTPS环境就必须让视频源也支持HTTPS。

6. 拿去答辩时的扩展建议

这块算是我额外送的经验。如果你的毕设题目是这个，答辩时不能只讲功能，还要能讲清楚设计决策。比如老师问你"为什么选RuoYi"，不要只说速度快，要说"RuoYi提供了成熟的RBAC权限模型和代码生成机制，让我能把精力集中在家教业务的核心流程上，这符合软件工程中复用成熟组件、聚焦核心业务的理念"。

如果想让项目更有竞争力，可以考虑加这三个扩展方向。

第一个方向是课程评价的算法优化。普通评价是星级加文本，你可以在此基础上做教师综合分，综合分由评分均值、评价数量、响应速度等维度加权计算，在教师列表页按综合分排序。这个功能工作量和复杂度适中，但讲出来很唬人。

第二个方向是数据可视化大屏。RuoYi自带Echarts依赖，你可以做一个管理员数据大屏页面，展示平台GMV趋势、各科目预约占比、教师排行Top10、课时消课热力图。用Echarts做几个图表拼一个页面，配上一句"基于Echarts实现平台运营指标可视化"，轻松多两页论文篇幅。

第三个方向是消息通知。RuoYi集成过WebSocket，可以在教师确认排课、课时完成、订单取消这些节点给对应角色发送站内消息提醒。这个功能在真实业务中不可或缺——线上服务不像线下面对面沟通，一切通知都要靠系统主动推送。

最后我根据自己的实际操作，补一句踩坑心得：这类系统项目，最怕的不是技术壁垒，而是你花了大量时间在环境配置和框架适配的杂活上。拿到一个陌生的RuoYi项目，第一步要做的不是看代码，而是先启动起来、登录进去、点到每个菜单看一遍，对项目有什么功能、数据结构长什么样心里有数，再开始自己的改造。这个流程走下来，后面写代码会顺很多。我上面写的这些内容，基本覆盖了从拿到项目到跑通改造再到答辩展示的全过程，照着这个思路去准备，至少能让你的毕设少走一大半弯路。

本文还有配套的精品资源，点击获取