企业官网建设流程全解析

如果你最近在准备计算机方向的毕业设计，大概率刷到过“基于 Java + Spring Boot 的家教管理系统”这类题目。我第一次带学生做“家教服务全流程对接与管控系统”的时候，心里想的是：无非就是用户管理、课程管理、订单管理，标准 CRUD 三件套。真正动手之后才发现，这个题目能成为毕设常客是有道理的——它几乎覆盖了 Spring Boot 开发里最值得练的几块硬骨头：多角色权限、状态机流转、资源匹配、并发防重。把这些啃下来，比做十个增删改查页面都有说服力。

这篇文章我以带过多个类似项目的开发者视角，把整套系统从业务分析、技术选型、数据库设计到核心逻辑实现完整过一遍。重点不会放在“怎么新建一个 Spring Boot 项目”这种基础操作上，而是说清楚每一步为什么这么做、坑在哪里。适合正在为毕设发愁的同学，也适合想用完整业务项目练练手的初级开发者，照着这个思路走，至少能少走大半个月弯路。

1. 家教平台和普通管理系统差在哪：业务闭环是命根子

1.1 先还原线下找家教的真实场景

在线下，家长找家教一般是这样：托亲戚朋友打听，或者在小区群里吼一声，然后挨个打电话问老师有没有空、课时费多少、能不能试讲。试讲觉得行了，再口头约定每周几上课、一次几小时、迟到怎么办。后面每次上课，要么微信转账，要么月底统一结一次。中间一旦老师临时有事、学生想调时间、或者对课时费有分歧，全凭一张嘴，没有任何凭证。

这个系统要做的第一件事，就是把线下一堆零散的、口头的约定搬到线上，变成一条可追踪的完整链路：需求发布 → 平台审核 → 教师匹配与申请 → 线上签约下单 → 排课上课 → 课时确认 → 评价与结算。每一步都留下记录，每一步都有明确状态。

1.2 按“三层”拆需求，而不是无脑堆功能

很多学生一上来就想做“在线视频辅导”“智能匹配算法”，结果两个月过去，连最基本的流程都没跑通。毕设的第一原则是先做闭环，再谈亮点。我把这个系统的功能按三个层次拆解，每一层的价值和优先级完全不同。

基础层是地基，没有它别的都白搭；业务层是这个系统的灵魂，直接决定答辩时能不能讲出完整的业务故事；管控层是让系统看起来“像个产品”而不是课程作业的关键，但可以往后放。我见过太多人把时间耗在给教师端做花哨的头像上传和相册功能上，结果订单状态机都没写完——这是最典型的本末倒置。

1.3 三类角色，两条业务线

家教平台至少有三类使用者，每一类看到的界面和操作完全不同：

• 学生/家长端：发布家教需求、查看推荐教师、下单支付、确认课时、评价教师。
• 教师端：完善教资档案、浏览可接需求、申请接单、填写上课记录、查看自己的接单收入。
• 管理员端：审核教师认证与需求内容、处理纠纷、查看平台运营数据。

这个系统的核心价值不在于某个单页面做得多么好看，而在于同一份数据在不同角色眼里有完全不同的视图。设计的时候一定要把“角色思维”贯穿到接口设计里，否则后面前后端联调会痛不欲生。

2. 技术选型与工程结构：Spring Boot 之外，还有几件事要想清楚

2.1 后端既然定了 Spring Boot，ORM 和安全框架怎么选

Spring Boot 在这个题目里几乎是最优解：自动配置降低了集成成本，生态成熟，内置容器，本地开发不需要额外安装 Tomcat，打成一个 jar 就能部署，对毕设答辩来说非常省事。

ORM 层我推荐 MyBatis-Plus，不推荐 JPA。原因是这样的：MyBatis-Plus 对单表 CRUD 几乎零 SQL，自带逻辑删除和自动填充，能省掉大量样板代码；而一旦涉及多表关联或者复杂统计，又可以手写 XML 精确定制 SQL。相比之下，JPA 的关联关系、懒加载、N+1 问题对新手并不友好，深挖下去是个无底洞。

安全框架方面，如果对 Spring Security 不熟，可以先自己写一个基于 JWT 的拦截器方案，系统跑通了再决定要不要换框架。但如果想在答辩里讲“RBAC 权限模型”，直接用 Spring Security 会更名正言顺。两条路线我都带人做过，后面讲权限设计时会给出具体建议。

2.2 前端两条路：前后端分离还是服务端渲染

方案 A：Vue3 + Element Plus，前后端分离。接口风格统一走 RESTful，前端路由做页面级权限控制。优点是贴近现在企业的开发模式，学习价值高；缺点是同时调试两个工程，跨域配置、打包上线都是额外成本。

方案 B：Spring Boot 内置 Thymeleaf 模板 + Bootstrap，服务端渲染。一片代码直接部署，没有跨域问题，接口数量少一半，开发速度快很多。缺点是看起来“不够现代”，在追求简历亮点的学生眼里不够时髦。

我的建议是：如果离答辩不到三周，选方案 B 求稳；如果时间充裕，选方案 A，顺便把 Vue 和跨域交互练一遍。但不管选哪条，后端接口都必须按“可以被独立调用”的标准来设计——这是工程素养问题，不是技术路线问题。

2.3 工程结构这样分包，答辩不怕被追问

一个清晰的包结构，比任何花哨技术都能体现你的工程意识。我常用的分包方式是这样的：

com.example.tutor ├── common // 统一返回结果、全局异常、工具类 ├── config // 安全配置、跨域、拦截器注册 ├── controller // REST 接口层，只做参数接收与结果返回 ├── service // 业务层，核心逻辑全部放这里 ├── mapper // MyBatis-Plus 的 Mapper 接口 ├── entity // 与数据库表对应的实体类 ├── dto // 请求参数对象 ├── vo // 返回视图对象 └── enums // 状态枚举、角色枚举、异常枚举

为什么要单独拆 dto 和 vo，而不直接把 entity 返回给前端？两个原因：第一，实体类里往往有 password、phone 这类敏感字段，直接序列化出去等于裸奔；第二，通过 vo 限制返回字段，能显著降低接口数据量，以后加字段改字段也不影响前端。答辩时把这两点讲清楚，比背十遍三层架构都有说服力。

3. 数据库设计：六张核心表如何把全流程串成一条链

3.1 用户认证与用户档案拆分设计

数据库是整个系统的地基，这块掉了链子，后面全得返工。我先把最基础的用户体系说明白：

user 表只负责认证：id、username、password（BCrypt 加密存）、phone、role_type、status、create_time。

tutor_profile 表存教师特有信息：id、user_id、subject_ids、hourly_price、education、years、intro、verify_status。

student_profile 表存学生/家长特有信息：id、user_id、address、contact_name。

这么拆的原因是：user 表的职责纯粹，只解决“你是谁、能不能登录”的问题；业务属性放扩展表，后面加字段不用动认证逻辑，也避免单表字段膨胀成一锅粥。教师档案里的 verify_status 单独拎出来，是为了让后台审核时能一眼筛出待审记录——这个字段在审核功能里是核心。

3.2 需求表与匹配记录表

demand 表是整条业务链的起点，关键字段包括：id、publisher_id、subject_type、grade、region、teaching_mode（线上授课还是线下上门）、budget_min、budget_max、description、status、create_time。

match_record 表承接匹配结果：id、demand_id、tutor_id、apply_type（系统推荐还是教师自荐）、match_score、status、apply_time、handle_time。

demand.status 是这条业务链的头号状态字段，我用枚举控制，取值包括：待审核、已发布、匹配中、已完成、已下架。管理员审核通过那一刻，系统才允许教师端看到这条需求——这既是业务规则，也是一道安全边界，不审核的需求绝对不能让教师去抢。

3.3 订单、课表与评价表

orders 表：id、order_no、demand_id、tutor_id、student_id、total_amount、hourly_price、total_hours、status、pay_time、create_time。

lesson 表：id、order_id、lesson_date、start_time、end_time、status、teacher_note。

evaluation 表：id、order_id、from_user_id、to_user_id、rating、content、create_time。

lesson 表承接的是“排课执行”环节，这一点很多学生容易忽略。订单是契约，lesson 是履约明细，一个订单对应多节课。如果没有 lesson 表，订单状态会变得非常粗，压根回答不了“今天到底上没上课”“这个月上了几节”这种最基本的问题——而这恰恰是家教平台日常最常用的功能。评价表单独成表，是为了支持双向评价（家长评教师、教师也可反馈），同时为后面的推荐算法打分提供数据来源。

3.4 字段设计的四个细节，全是踩过坑才换来的

• 金额一律用 BigDecimal，禁止用 double。float/double 的二进制误差在涉及钱时不可接受，用一次错一次。
• order_no 的生成规则建议用“日期时间 + 随机数”，比如 20250517 加 8 位随机数，并且建唯一索引，防止并发下单时生成重复单号。
• 状态字段要么用 int 配合枚举翻译，要么直接存枚举名字符串，禁止在代码里散落一堆魔法数字（1 代表什么、2 代表什么，一个月后你自己都忘）。
• 公共字段前置：create_time、update_time 用 MyBatis-Plus 的自动填充功能，后面做列表倒序、做统计都能省一大堆重复代码。

4. 匹配推荐与订单状态机：整个系统最值钱的两段逻辑

4.1 按需推荐的打分算法，别一上来就谈人工智能

很多学生一看到“匹配平台”就想着上推荐算法、协同过滤甚至深度学习，结果把自己困在数学公式里出不来。毕设场景里，一个可解释的规则打分算法不仅够用，而且答辩时更容易讲清楚——老师问“为什么推荐这个老师”，你直接列出科目、价格、区域三个硬指标的命中情况就行。

我的规则打分设计如下：

• 教授科目匹配：+40 分
• 预算区间与教师标价有交集：+20 分
• 教学区域一致（线下单）：+20 分
• 教师历史评分 4.5 分以上：+10 分
• 教龄超过 3 年：+10 分

总分 100，按分数倒序推送给家长端。核心代码就是一个简单的遍历评分，再排序取前若干条：

public List<MatchResultVO> recommend(Long demandId) { Demand demand = demandMapper.selectById(demandId); List<TutorProfile> tutors = tutorProfileMapper.selectList(null); return tutors.stream() .map(tutor -> buildMatchResult(demand, tutor)) .sorted(Comparator.comparingInt(MatchResultVO::getScore).reversed()) .limit(10) .collect(Collectors.toList()); }

这套规则的可解释性在于：每一分都能说出理由。我的经验是，先把规则逻辑讲清楚，再主动提一句“后续可以考虑引入学生历史行为做个性化加权”，这比硬套一个说不明白的矩阵分解模型靠谱得多。

4.2 教师申请接单的防重与并发处理

同一个需求，可能同时被多个教师申请；同一个教师，也可能手滑连点两次申请按钮。这里需要两层防护：

第一层是业务判断，申请前查一下是否已存在当前教师对该需求的申请记录；第二层是数据库兜底，在 match_record 表建 (demand_id, tutor_id) 唯一索引。

很多人只做第一层，这是有隐患的。因为“先查再插”在并发场景下存在时间窗口：两个请求同时查到“没有记录”，然后同时插入，重复数据就进来了。唯一索引会让第二个插入直接抛异常，再由全局异常处理器转成友好提示返回给前端。这个“唯一索引兜底”的思路，同样适用于订单号生成、点赞防重、收藏防重等所有类似场景。

4.3 订单状态机：用枚举管住所有流转

订单状态必须穷举，而且必须规定流转方向。我用的是这样一套状态机：

待支付 → 已支付 → 待上课 → 进行中 → 已完成
待支付 → 已取消
已支付 → 退款中 → 已退款

在 Java 里我直接用枚举把流转规则写死：

public enum OrderStatus { PENDING_PAY, PAID, PENDING_LESSON, IN_PROGRESS, COMPLETED, CANCELLED, REFUNDING, REFUNDED; public boolean canTransitTo(OrderStatus target) { switch (this) { case PENDING_PAY: return target == PAID || target == CANCELLED; case PAID: return target == PENDING_LESSON || target == REFUNDING; case PENDING_LESSON: return target == IN_PROGRESS; case IN_PROGRESS: return target == COMPLETED; case REFUNDING: return target == REFUNDED; default: return false; } } }

状态机的价值不是看起来专业，而是把非法操作挡在业务层外面。已完成订单不能被再次支付，退款中的订单不能被确认上课——没有状态机，这些校验就得靠一堆 if/else 散落维护，改一处漏一处，迟早出事。

4.4 课时确认与结算逻辑怎么设计

现实业务里，课时费结算是按“实际上课次数”来算的，而不是按签约的总课时数。所以 lesson 表的状态要支撑一条确认链路：教师发起“上课完成” → 学生确认 → 管理员端可见结算数据。

我用的方案是：教师点击完成课程后，lesson.status 变为“待确认”；学生确认后变为“已完成”，同时累计订单的完成课时数；当完成课时数等于订单总课时数时，订单自动变为“已完成”。结算金额 = 课时单价 × 完成课时数，在订单详情页实时展示。这段逻辑建议单独封装成一个 service 方法，比如confirmLessonCompleted(lessonId, studentId)，保持单一职责，后面写单元测试也好下手。

5. 多角色权限与接口安全：隐蔽雷区集中排查

5.1 基于 JWT 的认证与角色控制

登录成功返回 token，前端每次请求在 Authorization 头带上，后端用拦截器解析 token，把当前用户信息塞进请求上下文。这个方案无状态、支持前后端分离，毕设里完全够用。

接口的角色控制，配合 Spring Security 的注解是最优雅的：

@PreAuthorize("hasRole('ROLE_TUTOR')") @PostMapping("/lesson/complete") public R completeLesson(@RequestBody LessonCompleteDTO dto) { // 只有教师角色能调用 }

用注解声明接口的角色门槛，比在每个 controller 里写if (user.getRole() != ...)要清爽得多，而且整个系统的角色权限清单一眼就能看全。需要注意的是，一旦用了注解控制，拦截器也得配套放行，别把登录校验和角色校验搞成两套逻辑互相打架。

5.2 越权漏洞：多角色系统最常见的事故现场

这里说的不是黑客攻击，而是普通用户改一下 URL 里的参数，就能看到别人的订单、别人的需求。这是多角色系统里最高发的问题。

我见过这样的典型错误写法：

@GetMapping("/order/{orderId}") public R getOrder(@PathVariable Long orderId) { Order order = orderMapper.selectById(orderId); return R.success(order); }

这个接口没有任何归属校验，任何登录用户传一个订单 id 就能查到别人的订单信息。正确做法至少要判断数据归属：

@GetMapping("/order/{orderId}") public R getOrder(@PathVariable Long orderId) { Long loginUserId = UserContext.getUserId(); Order order = orderMapper.selectById(orderId); if (!order.getStudentId().equals(loginUserId) && !order.getTutorId().equals(loginUserId)) { throw new BizException("无权查看该订单"); } return R.success(order); }

每个涉及“按 id 查询”的接口，都要先问一句：这条数据是否属于当前登录用户？权限管控不只是角色，更重要的是数据归属（Ownership）。这个问题一想就通，但特别容易在赶工时漏掉，写代码时养成习惯能省很多麻烦。

5.3 全局异常处理与操作日志

统一异常处理这块，用@RestControllerAdvice捕获业务异常、参数校验异常、未知异常，统一返回{ code, message, data }结构。这样前端只处理一种响应格式，联调效率能翻倍，也不会把 Java 堆栈信息直接甩到浏览器上。

操作日志建议用 AOP 切面记录：谁、什么时间、调了哪个接口、参数是什么、IP 是多少。这一块对你答辩帮助很大，演示的时候翻一翻日志，直接体现系统的完整性。日志表设计也不复杂：id、user_id、api_url、method、params、ip、create_time 就够用。

6. 落地排期与答辩准备：把这个项目真正做完

6.1 建议的开发顺序与时间分配

整个系统按下面顺序开发，每周结束都有一条能看到效果的链路，而不是到最后一周才把所有模块拼装在一起。

这个顺序的核心逻辑是：先把“需求 → 匹配 → 订单 → 上课”这条主干打通，再补分支功能。主干通了，心里就不慌了，后面加什么都只是工作量问题。

6.2 演示环境准备：数据比功能更打动评委

• 造 10 个教师账号，科目、价格、评分要有区分度，方便现场演示推荐排序效果。
• 造 3 到 4 个处于不同状态的需求，现场演示状态流转。
• 准备一个“已完成”状态的订单，演示评价和结算数据。
• 每个角色准备一个演示账号，密码写在纸片上，别等到老师问再现场找。

我见过太多学生代码写得不错，结果演示时因为测试数据太少，界面上空荡荡的，效果大打折扣。数据准备到位，十分钟就能讲清楚整个业务闭环的价值。

6.3 答辩高频追问与回答思路

• 为什么用 JWT 不用 Session？——答：无状态、适合前后端分离、可以支撑多端登录。同时主动提一句 token 吊销不方便，所以配了短有效期来解决，显得你有完整的思考。
• 并发场景下匹配会不会出错？——答：业务层先判断，数据库唯一索引兜底，再配合行锁或乐观锁，把并发问题挡在源头。
• 有人恶意重复下单怎么办？——答：订单号唯一索引加幂等校验，支付回调也做了幂等处理。
• 系统最大的不足是什么？——答：目前匹配算法是规则打分，后续可以结合学生历史行为做个性化排序。诚实并且有改进方向，比硬吹效果好得多。

最后说一点我这些年的感受：做这类毕业设计项目，大多数人不是栽在技术上，而是栽在节奏上。前面一个月慢悠悠写界面，最后两周狂补业务逻辑，核心流程没时间自测，答辩现场当场翻车。我自己的习惯是第一天就把最小闭环列出来——注册、发需求、审核上架、申请匹配、下单、确认课时，哪怕界面再简陋，也要先让它跑通。这个顺序看着慢，其实是整个项目最快的路。收尾之前，记得导出一份数据库备份，提前一天把演示环境打开，把测试账号确认好。这些细节不会出现在论文里，但一定写在评委和导师的评分表上。