用户甲很多大四学生选毕设题目时，一看到"家教信息发布平台"这种题，第一反应是"简单"，觉得无非是发布信息、查看信息、联系家长，十几天就能交差。等真正动手写代码就会发现：用户角色权限怎么分、预约时间怎么校验、同一个家教老师被两个家长抢时段怎么办、订单状态怎么流转不乱套——这些问题一个比一个扎心。我在带毕设的过程中见过太多"答辩前一天发现核心预约逻辑根本没法演示"的人，基本都是栽在业务设计没想透。
这篇就聊一下我自己用 SpringBoot 做家教信息高效对接平台时沉淀下来的设计思路和实现细节。项目本身不大，但角色划分、时间预约、消息通知、状态流转这些点很典型，拿来当毕设或者作为 SpringBoot 综合练习都很合适。全文不假设你已经很熟练，但也不会只写"点击创建工程、写个Controller"这种水文，而是从业务出发，告诉你每一步为什么这么设计，代码落地的依据是什么。
1. 这个平台到底在解决什么问题：先别碰代码，把业务画像画清楚
做任何系统，最忌讳的是上来就建表。家教平台表面上是"发信息和看信息"，实际上牵扯到三类角色的协作，每一类人对系统的诉求完全不同。
- 学生/家长：想找到合适的家教，关注老师的资历、授课经验、距离远近、可预约的时间段和价格。他们要的是"快速筛选出靠谱的人"。
- 家教老师：想把自己的授课信息发布出去，管理空闲时段，跟进预约请求。他们要的是"单量管理方便，避免时间冲突"。
- 平台管理员：需要审核老师发布的信息，处理用户举报，维持信息的合法性和真实性。他们要的是"后台可见可控"。
如果把这三类诉求直接映射到代码层面，你就能推导出模块清单：用户模块（注册/登录/身份信息完善）、家教信息模块（发布/编辑/上下架）、在线预约模块（发起预约/确认/取消）、后台管理模块（用户审核/信息审核）。再往下拆就是表结构和接口。
所以"家教信息服务发布平台"这个题目，真正考察的点不是 CRUD，而是你有没有从需求里提炼出角色权限、业务状态、时间维度约束的能力。这也是答辩时老师最关心的：一个家教老师能不能把自己变成"可约状态"？改成不可约之后，已经发起的预约怎么处理？同一时间家长只能预约一个动作该落在哪一层？
建议你在需求分析文档里先把这几条理清楚，再进代码。画不画UML图不重要，脑子里这张业务图必须清晰。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型和搭建：SpringBoot版本不是越高越好，搭配才有价值
2.1 SpringBoot版本：2.7.18比3.x更适合毕设场景
标题里点名了 SpringBoot，但没说版本。我在实际项目中多次吃过版本选择的亏，这里直接给结论：如果目标是快速、稳定地完成毕设，SpringBoot 2.7.18 是首选，而不是最新的 SpringBoot 3.x。
原因很实在：
- SpringBoot 3.0 基于 Spring Framework 6，要求 JDK 17 起步。很多同学的电脑里环境还是 JDK 8，老师给的参考代码也是 JDK 8 写的。但 2.7.18 是 2.x 系列最后一个版本，既能 JDK 8 运行，也支持到 JDK 11/17，兼容度最高。
- 毕设常用的第三方组件版本，比如 MyBatis-Plus、Druid、Knife4j，绝大多数稳定文档和网上的解决方案都是基于 SpringBoot 2.x 的。升到 3.x 后遇到问题，搜出来的答案经常对不上。
- 大部分学校机房的项目运行环境、部署演示用的机器也是 JDK 8 居多，用 3.x 版本反而给自己制造部署障碍。
SpringBoot 3.x 当然好，但如果你只是想做平台功能演示，没必要跟版本较劲。版本号低一档，答辩不会扣分，跑不起来才是硬伤。
2.2 整套技术栈的搭配清单
下面是我在多个毕设和中小型项目中反复使用并验证稳定的一套组合：
| 层次 | 选型 | 说明 |
|---|---|---|
| 后端框架 | SpringBoot 2.7.18 | 稳定、资料多 |
| 持久层 | MyBatis-Plus 3.5.x | 单表CRUD不用写SQL，复杂查询用注解或XML |
| 数据库 | MySQL 8.0 | 功能全面，教学环境最常见 |
| 安全认证 | Sa-Token 或 JWT + 拦截器 | 毕设规模不需要引入Spring Security全家桶 |
| 接口文档 | Knife4j（基于Swagger2） | 生成可调试的在线文档，答辩演示加分 |
| 前端 | Vue 3 + Element Plus + Axios | 前后端分离，国内社区资料多 |
| 构建工具 | Maven 3.8+ | 不折腾，别用Gradle，除非你真的很熟 |
2.3 骨架式工程结构：按业务分包比按技术分包好用
网上很多教程喜欢把类都丢进 controller / service / mapper 三层。诚然这在代码量不大时没问题，但家教平台角色多、模块间有交叉操作，我更建议你按照 module 分包，一个业务域一个包，内聚性会好很多。
code复制com.example.tutor
├── common # 统一返回体、全局异常、公共工具类
├── config # 配置类（拦截器、跨域、MyBatis-Plus分页等）
├── security # 登录鉴权相关（JWT工具、拦截器、注解）
├── module
│ ├── user # 用户注册登录、个人信息
│ ├── tutor # 家教信息发布/展示
│ ├── order # 预约订单
│ ├── evaluation # 评价
│ └── admin # 后台管理
module 包里再各建 controller、service、mapper、entity、dto。这样哪怕后面想拆成独立的微服务模块，零件也是齐的。
3. 数据库设计：五张核心表决定整个平台的上限
为了说清楚业务，我把整套设计的核心表结构放到这一节展开。你需要关注的不只是字段名，还有每个字段为什么存在、怎么被使用。
3.1 用户表：用 user_type 区分角色，而不是建三张表
见过有些设计把家长表、老师表、管理员表分开建。从纯范式来说这没大问题，但在小程序/Web 端都要共用登录态的毕设场景里，维护成本很高。我的习惯是建一张 t_user，通过 user_type 区分角色，再补充一张 t_teacher_profile 保存老师特有的资质、教学年限、授课科目等扩展信息。
sql复制CREATE TABLE `t_user` (
`id` bigint NOT NULL AUTO_INCREMENT,
`phone` varchar(20) NOT NULL COMMENT '登录手机号',
`password` varchar(100) NOT NULL COMMENT 'BCrypt密文',
`user_type` tinyint NOT NULL DEFAULT 1 COMMENT '1-学生/家长 2-老师 3-管理员',
`nickname` varchar(50