拿“数字化农家乐管理平台”当毕业设计，不是一个冷门选择。最近几年我见过不少学生选这类题，原因很直接：农家乐场景大家都有生活经验，餐厅、民宿、采摘、活动预约都听得懂，不用评委追问“你这个业务到底解决什么问题”；同时它又是非常完整的Java Web业务系统，从信息展示、用户注册、在线预订、点餐结账到商家端接单、房态维护、经营统计，一条链路做下来，Spring Boot、MySQL、权限控制、事务、文件上传这些知识点全都能踩到。
这篇文章我按自己做毕设时的顺序来写：先梳理需求和模块边界，再聊技术选型和工程搭建，然后重点展开数据库设计和核心业务实现，最后给一份接口自测清单和踩坑速查表。适合正在选型或已经启动项目、想少走弯路的同学，也适合准备把系统“讲清楚”的答辩选手。纯后端方向做到能跑通完整业务闭环；如果想再加分，配一个Vue3管理端即可，下文也会给出衔接思路。
1. 先搞清楚的几件事：这个平台到底在做什么
很多同学拿到题目就急着建表、写接口，结果做到一半发现订单和房态对不上，或者管理端不知道怎么演示。我建议先花一天时间把需求和角色边界理清。
1.1 角色、痛点与“数字化”的真实含义
平台里至少有三类角色：游客（C端用户）、农家乐经营者（B端商家）、平台管理员（运营方）。三类角色各有各的痛点。
游客的痛点是什么？以前订农家乐主要靠电话，问有没有房、能不能订餐、周末还有没有位置，全靠店家本子记录，信息不透明，到了现场才发现房间和图片不符。数字化平台要解决的就是把“信息不对称”变成“在线可见”：房型价格、菜品、活动公告都展示在页面上，评价也能沉淀下来。
经营者的痛点更实在：手写单据容易漏单，房间有没有被订全凭脑子记，菜品原材料库存靠月末盘点。平台要给他们提供“一张能看全天的房态表”“一份能改库存的菜单”“一个自动算营业额的报表”。
管理员的角色则偏向平台治理，比如审核商家入驻、发布公告、看全平台经营数据。把这个三角色想清楚，后续数据库设计里为什么有 user、business、room_order 这些表，就顺理成章了。
1.2 功能模块全貌：三端一后台
我用一张表把常见模块列出来，做毕设时对照着检查自己有没有漏功能。
| 端 | 功能模块 | 核心动作 |
|---|---|---|
| 游客端 | 内容展示 | 首页公告、房型列表、菜品列表、活动列表 |
| 游客端 | 账号体系 | 注册、登录、个人信息维护、密码修改 |
| 游客端 | 交易闭环 | 预订房间、选择入住日期、模拟支付、菜品加购下单、活动报名 |
| 游客端 | 互动反馈 | 订单评论、评分、查看商家回复 |
| 商家端 | 资源管理 | 自建房型、维护房态日历、菜品上下架、库存修改 |
| 商家端 | 订单处理 | 接单、确认入住、安排退房、查看订单详情 |
| 商家端 | 数据汇总 | 今日营业额、月度订单量、热门菜品排行 |
| 管理端 | 运营管理 | 商家入驻审核、用户启用/禁用、公告发布 |
| 管理端 | 平台统计 | 总订单量、总交易额、各商家订单分布 |
表格里最容易被忽略的是“商家入驻审核”。很多同学做了商家端，却忘了平台需要管理员审核这个前置环节。加上这个功能，等于多了一个角色权限场景，答辩时也能讲出“平台治理”的逻辑。
1.3 题目难度评估：适合谁来做、周期怎么规划
从技术难度看，这个题没有明显的高墙。Spring Boot 是主流框架，MySQL 是常规数据库，业务复杂度低于电商秒杀，但高于单纯的学生管理系统。一个正常水平的本科生，用大约八到十周可以完成：前两周做需求设计和数据库，中间四周做后端接口，再用两周做前端联调，最后留一到两周给测试和论文。
如果你是那种“Java基础一般、SSM还没搞明白”的同学，这个题其实也适合，因为它的难点集中在一个核心链路“浏览-下单-支付（模拟）-确认-完成”上，把这一条链路吃透，系统就完成了七成。技术新意不足又想要高分，就要靠细节取胜，比如库存的并发控制、订单的自动取消、统计报表的可视化展示，这些后面会展开说。
2. 技术选型与工程搭建，不能拍脑袋
选技术栈不是越新越好，而是要匹配“能跑、能讲、能维护”这三个要求。下面是我推荐的一套组合，也是绝大多数毕设组能接受的方案。
2.1 为什么是Spring Boot + MyBatis-Plus组合
后端用 Java 8 或 Java 11，框架用 Spring Boot 2.7.x，理由不用多说：资料多、踩坑记录全、老师也熟悉。数据库用 MySQL 8.x，字符集统一 utf8mb4，避免中文乱码和表情符号报错。
ORM 我推荐 MyBatis-Plus 而不是 Spring Data JPA。原因很实际：它的单表 CRUD 和分页插件能省掉大量重复代码，比如批量插入、条件构造器、逻辑删除都是现成的。对毕设来说，大部分查询都是单表或者简单关联，MyBatis-Plus 足够；万一要写复杂统计 SQL，又能直接手写 XML，十分灵活。JPA 虽然也能用，但对初学者来说，懒加载、N+1查询、级联更新这些问题都比较隐蔽，出了问题排查成本高。
其他配套工具：工具类用 Hutool，能省写日期、字符串、UUID 的时间。登录鉴权用 JWT，具体用 java-jwt 库。密码加密用 Spring Security 里的 BCryptPasswordEncoder，即便不引入整个安全框架，也可以单独把这段加密逻辑抽出来用，避免明文密码存库。
2.2 从零初始化一个能跑起来的后端工程
我习惯先用 Spring Initializr 生成工程骨架，依赖只需要挑这几个：Spring Web、MySQL Driver、Lombok、Validation。生成之后再在 pom.xml 里补 MyBatis-Plus、Hutool、JWT 相关依赖。
一个最小可用 pom.xml 的核心依赖片段大致是这样：
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-api</artifactId> <version>0.11.5</version> </dependency>application.yml 里我提醒三个容易出问题的点。第一个是 datasource 的时区参数，必须写成：
spring: datasource: url: jdbc:mysql://localhost:3306/farm_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver第二个是 MyBatis-Plus 的配置，我一般会开启驼峰映射，并在 Mapper 扫描包上写清楚：
mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0第三个是 jackson 的日期格式，如果不配置，后端返回 LocalDateTime 序列化格式会很乱，前端解析容易出问题：
spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8启动类上记得加@MapperScan("com.xxx.farm.mapper")，要不然 Mapper 接口扫描不到，启动直接报错。
2.3 先把“统一返回体”和“全局异常处理”做好，后面全是收益
工程刚跑起来时，我强烈建议先把基础设施做掉，而不是急着写业务。所谓基础设施，就是所有接口返回的统一结构，以及全局异常捕获。
统一返回体我命名为 Result，结构很简单：
@Data public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> ok(T data) { Result<T> r = new Result<>(); r.setCode(200); r.setMessage("success"); r.setData(data); return r; } public static <T> Result<T> fail(String message) { Result<T> r = new Result<>(); r.setCode(500); r.setMessage(message); return r; } }全局异常处理用 @RestControllerAdvice + @ExceptionHandler。我通常自定义一个 BizException，业务里凡是“库存不足”“日期已被占用”“登录已过期”都直接 throw 出去。异常处理器统一转换成 Result 返回，前端拿到 code 和 message 就能弹提示。这样做最大的好处是：不管程序哪里报错，返回格式都是稳定的，不会把 MySQL 驱动里的原始异常堆栈直接抛给前端，相当于给整个项目穿了一层防护衣。
3. 数据库设计，把C端和B端的业务需求落到表上
数据库设计是毕设的“地基”，也是最容易在答辩被问倒的地方。我的建议是不要上来就建几十张表，先围绕一条主链路走通，再逐步扩展。
3.1 业务主链路梳理：从“看房”到“离店”
以民宿预订为例，完整链路是：游客注册登录 → 浏览房型列表 → 选择入住和离店日期 → 提交预订订单 → 模拟支付 → 商家确认订单 → 游客入住 → 离店完成 → 评价。
这条链路至少经过 user、room、room_order 三张表。房型的状态又和订单状态强关联，比如“已预订”状态下，该房间在对应日期区间不可再被下单。餐饮链路类似：游客点菜 → 生成订单 → 商家做菜 → 完成。两条链路都围绕“订单”这个核心实体展开，所以订单表设计质量基本决定了整个系统质量。
3.2 核心表设计：一张一张过
完整表结构比较多，我挑几张重点表说明设计逻辑。
第一张是用户表 user，字段包括 id、username、password（BCrypt 加密后的密文）、nickname、phone、avatar、role（1游客，2商家，3管理员）、status（1正常，0禁用）、created_at、updated_at、deleted。这里注意 role 和 status 都用 tinyint，不要用字符串，方便查询性能更好。
第二张是农家乐商家表 business，字段包括 id、user_id（关联用户表）、name、description、address、phone、cover_image、status（0待审核，1审核通过，2拒绝）、audit_remark。商家和用户有两种建模方式：一种是在 user 表加 is_business 字段，另一种是单独建 business 表。我推荐后者，因为商家有独立的审核字段和营业信息，后续扩展更容易。
第三张是房间表 room，字段包括 id、business_id、name、type（单间/套房等）、price（decimal(10,2)）、bed_count、area、image、status（0停用，1启用）。房间对应的日期状态并不建议在 room 表上维护，而是通过订单表来推算，这样不会出现状态和订单不一致的问题。
第四张是订单表 room_order，这是全系统最核心的表。我给一个关键字段设计：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| order_no | varchar(32) | 业务订单号，可读性好，方便对账 |
| user_id | bigint | 下单用户 |
| business_id | bigint | 所属商家 |
| room_id | bigint | 预订房间 |
| check_in_date | date | 入住日期 |
| check_out_date | date | 离店日期 |
| guest_count | tinyint | 入住人数 |
| total_amount | decimal(10,2) | 订单总金额 |
| pay_status | tinyint | 0未支付，1已支付，2已退款 |
| order_status | tinyint | 10待确认，20已确认，30已入住，40已完成，50已取消 |
| contact_name | varchar(30) | 联系人 |
| contact_phone | varchar(20) | 联系电话 |
| created_at | datetime | 下单时间 |
| updated_at | datetime | 更新时间 |
| deleted | tinyint | 逻辑删除 |
这里我不建议订单状态和支付状态合并成一个字段，虽然看起来可以省一列，但“已支付但商家未确认”和“未支付”是两种完全不同的状态，拆开表达更清晰。
菜品表 product 则要有 business_id、name、category、price、stock、sales、image、status。库存字段很关键，做点餐逻辑时要用它控制超卖。
第五类是订单详情表。如果点餐涉及多菜品，不能把菜品名直接塞进去一个字符串字段里。正确做法是拆成主表和明细表：order_form 保存单号、总价、状态；order_detail 保存每一个菜品的 id、名称、单价、数量。这样统计热门菜品时才算得清楚。
第六类是评论表 comment，字段包括 order_id（关联订单）、user_id、business_id、content、rating（1到5的整数评分）、reply_content、created_at。评论表关联到订单而不是单独让用户随便评，能防止不消费也去刷评分的问题。
3.3 订单状态机和金额处理的三个“隐形坑”
第一个坑是日期重叠。判断一个房间能不能订，不能只看“某一天有没有被订”，要查区间是否重叠。核心 SQL 类似这样：
SELECT COUNT(*) FROM room_order WHERE room_id = 1 AND pay_status <> 0 AND order_status NOT IN (40, 50) AND check_in_date < #{checkOutDate} AND check_out_date > #{checkInDate}这段 SQL 的写法有点反直觉，但它是正确的。判断重叠的标准不是“日期包含”，而是“先来的入住日期小于后者的离店日期，并且先来的离店日期大于后者的入住日期”，两条条件同时满足就说明区间交叉。
第二个坑是金额计算。房间总价 = 每晚单价 × 入住天数（离店日减入住日，单位是天）。一定要用 BigDecimal 计算，禁止用 double。每晚会涉及多天时，算出来直接存到订单的 total_amount 字段里，不要等支付时再算，避免后续改价造成的不一致。
第三个坑是状态流转要有“单向性”。比如订单状态只能从 10 到 20，再从 20 到 30，不能随手改成 50。我在业务层做了一组状态校验方法，进入任何修改状态的接口前先判断当前状态和期望状态是否满足跳转规则。虽然 MVC 架构下也可以靠前端约束，但后端必须再拦一道，答辩时讲“状态机”是很好的加分点。
4. 核心接口与业务逻辑实现，代码层面怎么落地
数据库设计好后，剩下的就是往框架里填代码。这一章我挑四块最重要的实现讲：登录鉴权、库存并发、文件上传、定时任务。这四块是区分“会写增删改查”和“真正做过系统”的关键。
4.1 登录鉴权：Token方案别做成“摆设”
登录鉴权我用 JWT，整体流程是：用户输入账号密码 → 后端用 BCrypt 校验密码 → 校验通过后生成 token 返回给前端 → 前端把 token 存在请求头里，后续接口都带上 → 后端用拦截器解析 token，再把用户信息放进去。
关键代码分两块。第一块是登录接口：
@PostMapping("/login") public Result<String> login(@RequestBody LoginDTO dto) { User user = userService.lambdaQuery() .eq(User::getUsername, dto.getUsername()) .one(); if (user == null || !passwordEncoder.matches(dto.getPassword(), user.getPassword())) { throw new BizException("账号或密码错误"); } if (user.getStatus() != 1) { throw new BizException("账号已被禁用"); } String token = JwtUtil.createToken(user.getId(), user.getRole()); return Result.ok(token); }第二块是拦截器。我写一个 AuthInterceptor 实现 HandlerInterceptor，在 preHandle 里取 Authorization 请求头，解析并校验 token，把 userId 和 role 放进 request 的 attribute。然后通过 WebMvcConfigurer 注册拦截器，并配置放行路径，比如登录注册接口、首页商品列表这些公开接口。
这个方案简单可靠，我提醒一句：token 一定要设置有效期，一般 7 天足够。过期时间一到，用户就需要重新登录，一方面符合多数平台习惯，另一方面也防止答辩当晚查到一堆不过期的 token 不知道怎么解释。
4.2 房态与库存并发控制：别让“超卖”出现在答辩现场
客房预订有一个并发问题：两个人同时在抢同一个房间的同一日期，如果都查到“无重叠订单”，然后同时插入，就会产生超卖。菜品库存也一样，前后端同时下单，可能把库存减成负数。
解决思路不复杂，用“条件更新 + 影响行数”代替“先查询再更新”。菜品库存扣减的例子：
boolean success = productMapper.update(null, new LambdaUpdateWrapper<Product>() .setSql("stock = stock - " + count) .setSql("sales = sales + " + count) .eq(Product::getId, productId) .ge(Product::getStock, count)) > 0; if (!success) { throw new BizException("库存不足"); }数据库层面的 update 语句在 where 条件里带上 stock >= count，一次原子操作，就不会出现超卖。不要先查库存，再用代码判断，这个“查询后再更新”的写法一旦并发必出问题。
房间预订的并发控制稍微复杂一点。最简单可靠的做法是在插入订单时，对房间表执行一个乐观锁更新，例如给 room 表加一个 version 字段，每订一次房 version 就加一，更新时带上前一次的 version。更新影响行数为 0 说明有人比你先下单了。如果觉得复杂，也可以使用“先插订单再查重叠”的策略，但务必保证“插入前已用数据库唯一约束或者互斥手段保护”。后者逻辑调起来更费劲，我更推荐乐观锁或直接使用数据库行锁处理，实现代码也不多。答辩时被问到“并发怎么办”，能说出上面的条件更新方案，就已经及格了。
4.3 文件上传与静态资源映射：图片显示不出来是高频问题
农家乐平台里到处都是图片：房间封面、菜品图、活动海报。文件上传的坑主要在“图片传上去了，但页面上显示不出来”和“重启项目后图片丢失”。
我在项目里的做法是：服务器本地磁盘保存文件，路径写成配置项：
file: upload-dir: ./upload/上传时用 UUID 重新生成文件名，保留原扩展名。文件类型白名单做校验，只允许 jpg、png、webp，大小控制在 5MB 以内，避免有人传一个巨大文件把磁盘塞满。
保存到本地之后，需要告诉 Spring MVC“哪些 URL 对应磁盘上的哪些目录”，我用的配置类：
@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/files/**") .addResourceHandler("file:" + fileProperties.getUploadDir()); } }这样图片访问路径就是http://localhost:8080/files/xxxxx.jpg，前端直接拼在域名后就能展示。这里最大的坑是：如果你把项目打成 jar 部署，那双斜杠路径和相对路径都会变，容易出错。所以我会把 upload 目录固定写成 tomcat 目录下的相对路径，并在论文里说明文件存储方案。如果不想处理这些，也可以用云存储，但涉及外部依赖，毕设阶段不建议引入。
4.4 定时任务和统计报表：给答辩加点“运营味”
很多毕设系统做到“能下单”就停了，评委总觉得少点什么。加一个定时任务，立刻让系统有“后台运营”的感觉。
我用 Spring Boot 自带的 @Scheduled 做两件事。第一件事是超时取消订单：
@Scheduled(cron = "0 */5 * * * *") public void cancelExpiredOrders() { LocalDateTime deadline = LocalDateTime.now().minusMinutes(30); List<RoomOrder> expiredOrders = roomOrderService.lambdaQuery() .eq(RoomOrder::getPayStatus, 0) .eq(RoomOrder::getOrderStatus, 10) .lt(RoomOrder::getCreatedAt, deadline) .list(); for (RoomOrder order : expiredOrders) { roomOrderService.updateOrderStatus(order.getId(), 50); } }这里唯一要注意的是，取消订单的同时要释放之前“锁定”的库存和房态，否则库存会被白白扣掉。第二件事可以做月报统计，统计当月营业额、订单量和前五的热门菜品，把这些数据维护到一张统计表里，管理端打开报表时就不用实时联表聚合，响应会快很多。
5. 测试、踩坑与答辩前的最后冲刺
到这里，项目主体基本能跑了。但“能跑”和“敢拿上台面”是两回事。我在答辩前一周最常做的事，就是拿着一份接口清单从头到尾点一遍。
5.1 一份自测清单，把核心链路完整走三遍
我建议按业务角色和流程来测，而不是按接口路径来测。
| 顺序 | 测试场景 | 预期结果 |
|---|---|---|
| 1 | 游客注册新账号 | 密码存储为密文，前端提示注册成功 |
| 2 | 游客登录 | 返回 token，后续请求携带 |
| 3 | 商家申请入驻 | 状态变为待审核，管理员端可见 |
| 4 | 管理员审核通过商家 | 商家账号获得商家权限 |
| 5 | 维护房型和菜品 | 图片能正常访问 |
| 6 | 游客浏览房型列表 | 只显示启用状态的房间 |
| 7 | 游客预订连续两晚 | 订单金额为单价乘天数 |
| 8 | 重复预订同一日期 | 被拦截并提示日期冲突 |
| 9 | 游客模拟支付 | 支付状态变已支付，库存扣减 |
| 10 | 商家确认订单 | 订单状态流转为已确认 |
| 11 | 游客发表评论 | 商家端可见并能回复 |
| 12 | 商家查看日报表 | 数据与订单一致 |
| 13 | 游客账号被管理员禁用 | 再次登录被拦截 |
这套流程走完，项目基本不会出现大漏洞。过程中如果发现问题，立刻在表格里登记。答辩前把表格打出来贴在桌上，你演示的时候心里有底。
5.2 高频问题排查速查表
我整理一份实战中十个人里九个会踩的问题。有些问题网上答案很散，这里直接给结论。
| 问题 | 原因 | 处理方式 |
|---|---|---|
| 连接 MySQL 报 Unknown time zone | 数据库和驱动时区不一致 | url 加 serverTimezone=Asia/Shanghai |
| 中文乱码 | 数据表/连接字符集不一致 | 表和连接统一 utf8mb4 |
| 前端请求跨域报错 | 后端未开跨域 | 实现 WebMvcConfigurer 的 addCorsMappings |
| 分页查不到数据 | MyBatis-Plus 分页插件未注册 | 加 MybatisPlusInterceptor 和 PaginationInnerInterceptor |
| 删除数据后唯一索引冲突 | 逻辑删除只更新 deleted 字段 | 唯一索引设计上把 deleted 纳入或用业务字段判断 |
| 上传图片能存但访问 404 | 静态资源映射没配 | 注册 ResourceHandler |
| 返回时间为数组 | LocalDateTime 序列化问题 | 配置 jackson date-format 和 time-zone |
| 事务不生效 | 同类内部方法调用或类未加注解 | 事务方法从外部调用，或拆分 service |
| IDEA 里快捷键生成的 getter 报错 | Lombok 插件未安装 | 安装 Lombok 插件 |
| 启动时端口冲突 | 8080 被占用 | 换端口或在命令行查占用进程 |
这里重点说一个容易被忽视的：逻辑删除和唯一索引的冲突。如果 user 表用逻辑删除，你给 username 建了唯一索引，第一次删除账号后，username 的值还在表里；新用户注册同名账号，就会触发重复键。解决办法是不要只依赖数据库唯一索引，而是在注册时用排除逻辑删除的查询先做用户名校验，或者在唯一索引中把 deleted 字段也放进去。这种细节评委很难问，但一旦被问到，回答出来非常加分。
5.3 演示和答辩：别对着代码念，要对着业务讲
最后说说演示节奏。开场的顺序很重要，我推荐：先用一句话说明这个平台解决什么问题，再花一分钟演示游客浏览和下单，重点停在“订单状态变更”和“库存变化”上，然后切换商家端，展示接单和报表。不要一上来就打开数据库给评委看表结构，那是论文里该有的东西。
演示时提前准备好数据，特别是报表页面，不要让评委看到一张空表。可以预造三天的模拟订单，日期选择当前日期前后各一天，这样房态日历和统计曲线都是“活的”。另外，手工演示容易出意外，我会提前录一份两分钟的完整视频作为备胎，万一现场浏览器被浏览器崩溃、数据库连接掉了，直接放视频继续讲，比当场修 bug 从容得多。
答辩时最常遇到的几个问题，我整理过回应思路：
- 问：订单并发你怎么处理？答：菜品库存用条件更新 SQL，客房预订用日期重叠判断加乐观锁。
- 问：为什么不用 Redis？答：本项目对缓存要求不高，MySQL 加合理索引足够，后续可以扩展 Redis。
- 问：支付的逻辑是什么？答：为了安全合规，项目采用模拟支付，状态流转完整，可以平滑接入真实支付。
- 问：你觉得自己系统最大的特点是什么？答：完整的三端业务闭环加基于订单状态机的状态管理，以及定时任务对超时订单的自动处理。
我个人做项目时的一个体会是，毕业设计做到最后，拼的往往不是某个高深算法，而是“全程想清楚每一个为什么”。你做的每一张表、每一个状态字段、每一次库存扣减，都能说出理由，这就是一次合格的工程训练。这个农家乐平台哪怕功能朴素一点，只要链路闭环、逻辑自洽，放在答辩现场是有说服力的。如果你后面还有时间，可以在这个基础上增加活动报名统计、优惠券核销、商家评分排行，扩展空间很大，但核心体验已经够了，先把主链路打磨扎实。
