企业官网建设流程全解析

做这个项目之前，我首先会盘清楚一件事：一个“农家乐管理系统”听起来好像并不新鲜，但如果你真动手去设计，会发现它远比想象的复杂。因为农家乐本身是一个多业态集合体——有民宿住宿、有餐饮点菜、有采摘农事体验、有土特产零售、还有平台侧的运营管理。这不是做一个简单的CRUD后台，而是要构建一个面向C端游客、B端运营者双向使用的综合服务系统。我个人认为，这个题目放在SpringBoot技术栈下是特别合适的：SpringBoot提供了快速搭建、内置配置、生态成熟等优势，加上Java在高校教学和企业开发里占据的主流地位，用这个技术栈做毕业设计既好实现，也好演示，同时还能在答辩时讲出不少加分点。

这篇文章我会把它当作一个真实的项目来拆解：从系统设计、技术选型、数据库表结构、前端交互到部署上线的完整闭环，并穿插一些我在实际开发中踩过的坑和总结的经验。内容适合正在准备毕业设计、想自己动手从零做一个完整项目的同学，也适合打算给乡村农庄做信息化系统的小团队参考。

1. 项目核心定位与整体设计思路

1.1 这套系统的价值定位：为什么做“一体化”而不是“单模块”

市面上的“某某管理系统”容易做成一个纯后台的数据维护界面，但农家乐场景里你如果只做一个后台，运营者会在实际操作中非常痛苦。为什么？因为农庄的日常运营是围绕游客来的：游客来之前的预订、到达后的餐饮消费、住宿安排、农事活动预约、离店后的评价，这些链路必须串起来，才能减少重复沟通和纸质记录。

所以这套系统的定位不仅是“管理”，更是“服务”，核心是把农庄的线下运营流程搬到线上。游客端能自己看房、选日期、下单，能提前点菜，能预约采摘或垂钓；运营端能统一处理订单、管理房态和菜品库存、发布活动公告。民宿餐饮一体化体现在：一个用户体系，一次登录，在平台上可以同时完成住宿和餐饮的预订，后台能联动统计收入来源。

1.2 角色划分：游客、运营者、平台管理员各司其职

系统的角色设计直接决定权限模型的复杂度，也是答辩时老师最常追问的地方。我建议把角色拆成三种，而不是过度细化。

• 游客（C端）：主要功能是浏览农庄信息、查看民宿房型、在线预订、餐饮点单、报名农事活动、发表评价、管理个人订单。
• 运营者（庄主/农庄员工）：负责发布和管理房型、设置可订日期和价格、管理菜品及库存、创建活动场次、处理订单、查看经营数据。
• 平台管理员：偏向整个系统的支撑层，负责用户管理、角色分配、公告与轮播图配置、系统参数维护。

这样设计的好处是职责清晰，也容易在后端用角色字段做接口权限控制。如果你做的项目是入驻式平台，多农庄加盟，可以再加一个“农庄表”外键关联；如果是单体农庄自用，就不需要过度设计。

1.3 功能模块全景：从游客到运营的完整业务闭环

我把功能拆解成下面几个模块，整体是按“信息展示 → 预订交易 → 履约经营 → 数据反馈”这条线走的，你在设计时也尽量保证这个闭环：

• 游客端：农庄首页与介绍、民宿列表与详情、房间预订下单、在线点餐、活动与农事项目预约、个人中心、订单管理、评价系统。
• 运营端：房态日历管理、订单确认与取消、菜品上下架与库存预警、活动场次发布、评价管理、收入统计图表。
• 管理端：用户列表与角色分配、广告图（Banner）管理、公告管理、系统配置。

这块内容很多，不要想着一个版本全做完。毕业设计的第一版建议优先做“民宿预订 + 在线点餐 + 活动报名”，剩下的功能排优先级往后放。这样做的好处是核心链路完整，答辩演示时逻辑清晰，不会因为功能太散而显得没有深度。

2. 技术选型分析与关键组件落地

2.1 后端技术栈：SpringBoot、MyBatis-Plus与JDK版本的取舍

技术选型直接决定你写的代码风格和开发效率。我强烈建议用SpringBoot 2.7.x搭配JDK 8或JDK 11。原因有两点：

第一，稳定性。SpringBoot 2.7.x非常成熟，开发文档和网上资料都特别多，遇到报错几乎都能搜到解决方案。第二，兼容性。很多高校实验环境和老项目依赖用的是JDK8，如果你用SpringBoot 3.x，要求JDK17，加上Jakarta命名空间的变化，反而会在环境配置上花掉不少时间。

持久层框架选MyBatis-Plus，不选JPA，也不选原生MyBatis。理由是农家乐系统的查询场景以单表增删改查和简单的多表关联为主，MyBatis-Plus提供的BaseMapper和LambdaQueryWrapper能少写大量重复SQL，而且分页插件非常方便，后端接口开发速度会快很多。多表关联场景，比如订单带用户信息、房间带订单状态，直接用注解或XML写少量SQL即可。

2.2 前端方案怎么定：前后端分离还是服务端渲染

这是很多做毕业设计的同学卡住的地方。我见过不少人一开始就用Vue全家桶前后端分离，结果写到一半发现联调工作量太大，一个人根本顾不过来。

我的建议是分两种情况考虑：

• 如果你自己负责全部开发，选一个轻量的前端方案。比如Thymeleaf服务端渲染，搭配Bootstrap或Element UI手工写页面，后端返回页面和JSON混合，能省去跨域和Token管理的大量麻烦。
• 如果你对前端比较熟练，也愿意花时间调样式，那Vue3 + Element Plus做管理后台、H5游客端用移动端适配，整体效果会好看很多。但必须留足联调和调试的时间。

以我的经验，最稳妥的组合是“Thymeleaf做游客端页面 + Vue独立做运营管理后台”。因为游客端重点是SEO和首屏速度，服务端渲染友好；管理后台是工具型页面，适合前端框架高效搭建表格和表单。

2.3 Redis与文件存储：哪些组件真正用得着

不是所有热门组件都必须引入，引入什么组件取决于系统里有没有真实需求。在这个项目里，有两个组件是明确用得到的：

• Redis：用来存储短信验证码、登录Token可以设置过期时间、还可以缓存热门房型和轮播图。比如用户请求验证码后，验证码有效期5分钟，用Redis设置过期时间非常自然，比用数据库记录过期时间优雅很多。
• 文件存储：农庄必须上传房间实拍图、菜品图和活动海报。最务实的方式是上传到服务器本地磁盘，再通过Nginx或SpringBoot的静态资源映射对外访问。不用接云OSS，因为这类系统通常部署在单台服务器，本地存储最省成本也最可控。

我自己的实践是单独建一个FileController处理上传，文件名用UUID拼接原有后缀名，日期按月份分目录存储，上传成功后再把访问路径保存到数据库字段里。这一步做下来，图片管理基本不会出问题。

2.4 SpringBoot项目的基础目录结构：按业务模块分包

分包方式直接影响代码可读性和答辩印象分。我是按功能模块分包，而不是按技术层次一把梭到底。具体结构是这样：

com.example.farm ├── common // 通用配置、常量、工具类 ├── config // 配置类：MyBatisPlus、拦截器、跨域、文件映射 ├── controller // 接口层，按模块划分 ├── service // 业务逻辑层 ├── mapper // 数据访问层 ├── entity // 数据实体类 ├── dto // 请求与响应对象 ├── vo // 视图对象 └── security // 登录拦截、权限注解

你会发现我把controller、service、mapper这些传统层次保留了一部分，但把具体的业务模块放在controller包用前缀区分，比如FarmhouseController、DishController、OrderController。这种结构便于快速定位代码，也方便你后期扩展新功能。

2.5 为什么SpringBoot适合这类毕业设计项目

很多人会问：用SpringBoot做毕业设计是不是太“模板化”了？我的真实感受是，技术永远是为业务服务的。这家农家乐系统里，SpringBoot带来的自动配置极大降低了环境复杂度，@RestController注解一行就能暴露接口，@Transactional事务管理保证订单和库存操作不会出错，这些恰好是学生项目最需要的稳定性和开发效率。

再加上SpringBoot天然支持多种部署方式，开发时本地跑Jar包，上线直接扔服务器，整个过程不用修改任何代码。这样你就能把精力集中在业务逻辑和功能实现上，而不是跟配置较劲。

3. 数据库设计与核心表结构梳理

数据库设计是毕业设计里最容易暴露问题、也最能拿分的地方。我不建议一上来就画很多张表，先抓住核心实体：用户、房间、民宿订单、菜品、餐饮订单、活动、活动预约。第一版有这七张表就能完成主流程。下面我挑几张关键表细说字段设计思路。

3.1 user表：一个用户身份贯穿所有业务

用户表统一保存游客和运营者，通过role字段区分身份，避免分别建“游客表”和“管理员表”造成的关联复杂性。

CREATE TABLE `user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键', `username` varchar(50) NOT NULL COMMENT '登录账号', `password` varchar(100) NOT NULL COMMENT '加密后的密码', `nickname` varchar(50) DEFAULT NULL COMMENT '昵称', `phone` varchar(20) DEFAULT NULL COMMENT '手机号', `avatar` varchar(255) DEFAULT NULL COMMENT '头像地址', `role` tinyint(4) NOT NULL DEFAULT 1 COMMENT '角色：1游客 2运营者 3管理员', `status` tinyint(4) NOT NULL DEFAULT 1 COMMENT '状态：1正常 0禁用', `create_time` datetime DEFAULT NULL COMMENT '创建时间', PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

密码不要明文存储，建议用MD5加盐或BCrypt。在SpringBoot里，Spring Security的BCryptPasswordEncoder可以直接用，即使你不引入Security，单独引入spring-security-crypto也可以完成加密。

3.2 house表与house_order表：房态库存与预订冲突是关键

民宿房间表有价格、面积、床型、设施、封面图、介绍等基础字段，但最关键的字段是“房间类型”和“状态”。我建议把房间状态分成两个维度：一个是房间本身的上下架状态，一个是具体日期是否可订。可订日期由订单来判断，而不是在房间表里维护一个大数组字段。

CREATE TABLE `house` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `house_name` varchar(100) NOT NULL COMMENT '房型名称', `price` decimal(10,2) NOT NULL COMMENT '门市价', `discount_price` decimal(10,2) DEFAULT NULL COMMENT '优惠价', `area` varchar(20) DEFAULT NULL COMMENT '房间面积', `bed_info` varchar(50) DEFAULT NULL COMMENT '床型信息', `facility` varchar(500) DEFAULT NULL COMMENT '设施配套', `cover_image` varchar(255) DEFAULT NULL COMMENT '封面图', `detail_images` text COMMENT '多图地址，逗号分隔', `intro` text COMMENT '房间介绍', `status` tinyint(4) NOT NULL DEFAULT 1 COMMENT '1上架 0下架', `create_time` datetime DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='民宿房间表';

订单表的设计要特别注意“入住日期”和“离店日期”，因为农家乐订单金额一般按“间夜”计算。一张订单里如果有多个房间，可以拆成订单明细，但第一版可以直接在house_order表保留一个房间ID，简单直观。

3.3 dish表与food_order表：餐饮订单的小票结构

餐饮模块比民宿模块简单，但也要遵循“订单主表 + 订单明细表”的标准结构。主表存订单号、总金额、状态、下单时间；明细表存菜品ID、数量、单价、小计。为什么这样设计？因为你不能把菜品列表用逗号塞进主表一个字段里，否则无法对账、无法统计热销菜品、也无法在取消订单时恢复库存。

菜品表里有几个字段值得注意：库存字段（stock）、上下架状态、是否推荐。如果你的农庄是“现摘现做”模式，库存可能不是硬约束，但为了体现系统严谨性，我还是建议保留库存字段，并且在点餐接口里用一条update语句做扣减判断：

boolean success = dishService.update() .setSql("stock = stock - 1") .eq("id", dishId) .gt("stock", 0) .update();

这样能防止两个人同时点最后一份菜导致的超卖。这个细节在答辩时讲到，老师会认为你考虑到了并发问题。

3.4 activity表与activity_order表：场次预约要用时间窗口

农事体验活动，比如采摘草莓、插秧、钓鱼，核心是场次和人数限制。我的建议是设计一张activity表保存活动名称、封面、介绍、价格、人数上限，再设计一张activity_order表记录哪个用户预约了哪个场次。而“场次”本身可以设计成activity_time表，也可以用简单的start_time和end_time字段代替。

这里有一个实践细节：活动的开始时间一旦过了，订单状态应该自动变为“已结束”或“已完成”。最简单的方式是定时任务（Spring的@Scheduled）每天凌晨扫一遍活动订单，把时间已过的预约记录更新状态。定时任务在这个系统里也是一个小亮点，实现成本低，但能体现你对业务状态流转的考虑。

3.5 补充表：评价、公告、轮播图，让系统更完整

核心表做完后，再补四张轻量表就能让系统看起来相当完整：comment（评价表）、notice（公告表）、banner（轮播图表）、coupon（优惠券表，可选）。评价表关联用户ID和订单ID或商品ID，公告表和轮播图表在游客端首页展示，优惠券表可以做成“满减”，但如果你时间紧张，优惠券可以先不做成真正的抵扣流程，只做一个列表展示，也能撑起页面。

数据库设计的整体思路就一句话：以订单表为中心，向外延伸出商品、用户、活动等维度。千万不要一开始就设计十几张表，先把主流程跑通，再根据页面需要补表或者加字段。

4. 核心功能模块实现细节

4.1 民宿预订流程：日期冲突校验是重中之重

民宿预订的前端流程是：用户选择入住日期和离店日期，系统根据日期查询所有房间中哪些还不冲突，返回可选房型列表；用户选择房型提交订单；运营者在后台确认订单。

这里的核心算法是“区间重叠判断”。给定一个房间，已有订单的入住日期范围是[start1, end1)，用户预订的是[start2, end2)，两个区间发生冲突的条件是：

start1 < end2 AND start2 < end1

这个判断非常经典，也特别适合拿出来当技术亮点讲。在数据库层面，查询某个房间在目标日期段内是否可订的SQL是这样：

SELECT COUNT(*) FROM house_order WHERE house_id = ? AND status IN ('已支付', '待确认') AND start_date < ? -- 离店日期 AND end_date > ? -- 入住日期

查询结果大于0就说明日期冲突，不能预订。这样做比把每个日期都存一条记录要高效得多，也避免了日历型库存表带来的冗余问题。

4.2 餐饮点餐模块：购物车与订单结算

游客进入菜品列表后，可以把菜品加入购物车。购物车的实现不需要设计表，用Redis或者前端本地缓存都行。我先讲后端方案：如果你做前后端分离，购物车可以用一个CartController，后端用Redis的Hash结构保存“userId -> 菜品ID -> 数量”，接口提供添加、修改数量、删除、清空和结算。

结算时，后端需要做几件事：

• 从购物车读取菜品列表，校验每个菜品目前的状态是上架且库存充足；
• 计算总金额，此时可以叠加优惠（比如满100减10），但第一版建议直接按原价计算；
• 创建订单主表记录，同时创建订单明细，逐条扣减库存；
• 扣减成功后，清空购物车。

这几个操作必须加事务注解@Transactional，任何一个环节失败都要全部回滚。我曾经见到有人不加事务，支付成功后库存没扣，最后对不上账，这个坑一定不要踩。

4.3 活动预约模块：人数上限的并发控制

活动预约比民宿预订简单，但要注意人数限制。如果activity表里有“剩余名额”字段，预约接口执行时也要做并发控制。最简单有效的方案还是那句update语句：

UPDATE activity SET remain_count = remain_count - 1 WHERE id = ? AND remain_count > 0;

如果影响行数为0，说明名额已被抢完，直接返回“活动已满”。这个做法没有使用复杂的分布式锁，但对付单服务器场景绰绰有余。

活动预约订单的状态可以分成“已预约”“已核销”“已取消”。核销操作由运营者在后台操作，比如用户到现场报手机号，运营者在后台搜索订单，点击核销，这个流程也很符合农庄线下的实际操作习惯。

4.4 评价模块：给游客一个表达出口

评价模块虽然简单，但很出效果。游客在“已完成”的订单里可以点“去评价”，评价内容包含星级、文字内容和图片，评价成功后关联到对应的民宿或餐饮订单。运营者可以在后台回复评价，这个互动机制能让系统看起来有真实运营的感觉。

在实现评价时，我建议要加上“订单校验”：只能评价属于自己的订单，而且该订单必须处于已完成状态。这个校验不仅能防止恶意刷评，也是答辩时能讲的一个业务逻辑细节。

4.5 数据统计：为运营者提供可视化图表

毕业设计如果只做增删改查，显得单薄。运营后台加一个“经营统计”页面，能立刻拉高系统完整度。统计项可以包括：

• 近7日订单数量趋势；
• 各房型的收入排行；
• 热销菜品Top5；
• 活动预约人数统计。

实现方式很简单：用ECharts在前端绘图，后端提供几个统计接口，用MySQL的GROUP BY和DATE_FORMAT函数做聚合查询。后端返回JSON数组，前端解析后填充图表。这部分工作量不大，但视觉上非常加分。

4.6 运营者后台的核心操作场景

运营者后台不需要做得很花哨，关键是功能要顺。第一版至少要有这些页面：登录页、控制台（带统计卡片）、民宿管理（列表、新增、编辑、上下架）、民宿订单管理、菜品管理、餐饮订单管理、活动管理、评价管理。

我推荐用Vue2或Vue3加Element Plus快速搭建表格页面。表格页的通用的模式是：搜索栏 + 表格 + 分页 + 新增/编辑弹窗。Prepared一个“基础CRUD模板”后，后面的页面都复制改改，开发速度会非常快。

运营者登录后，后端接口要通过角色校验，确保游客不能访问运营后台接口。这个功能涉及权限设计，接下来专门写一节。

5. 权限控制与安全设计

5.1 基于角色的访问控制（RBAC）

前面我把用户角色划分成游客、运营者、管理员三种，权限控制就可以直接基于角色。最简单的方式是登录成功后把用户角色存入Session或Token中，后端写一个拦截器，拦截所有需要权限的请求，检查当前用户的角色是否满足要求。

我封装了一个自定义注解@RequireRole，用在Controller方法上：

@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface RequireRole { int value() default 1; // 1游客 2运营者 3管理员 }

然后写一个HandlerInterceptor，在preHandle方法里读取当前登录用户角色，再读取方法上的注解，不满足就返回401 JSON。核心逻辑不算复杂，但对系统的安全性来说是质的提升。如果时间充裕，可以用Spring Security，但我觉得对这个项目来说，一个拦截器完全够用，而且更好理解。

5.2 登录认证方案：JWT还是Session

这里我给一个明确的建议：如果做前后端分离，用JWT；如果做服务端渲染，用Session。为什么？

• JWT无状态，对移动端和前后端分离特别友好，前端把Token存在localStorage或请求头里；缺点是过期时间控制不方便，遇到需要临时封禁用户的操作不好处理。
• Session有状态，天然支持失效操作，但前后端分离时需要配置跨域携带Cookie，稍显麻烦。

我自己的示例项目用的是JWT。登录成功后，后端生成一个Token返回前端；前端每次请求在拦截器里带上Authorization请求头；后端通过JWT工具类解析Token获取用户ID。Token有效期设为24小时，前端收到401状态码后自动跳转登录页。这个流程简单、好用，也能在答辩时介绍清楚JWT的结构（Header.Payload.Signature）。

5.3 接口防越权：不仅要有权限，还要校验数据归属

角色权限只能解决“这个用户能不能访问这个接口”的问题，但解决不了“这个用户能不能操作这条数据”的问题。比如一个游客ID为5，他如果直接请求“获取订单详情接口”并传订单ID=100，而这个订单是ID为7的用户创建的，那他就越权了。这个场景叫做水平越权。

解决方案很直接：Service层在查询前判断订单的userId是否等于当前登录用户的ID。我在代码里习惯写一个checkOwner方法：

Order order = orderService.getById(orderId); if (!order.getUserId().equals(currentUserId)) { throw new ServiceException("无权访问该订单"); }

这个细节很多初学者会忽略，但它是系统上线后真实安全性的一道重要防线。

5.4 图片上传的安全限制

图片上传接口如果什么都不限制，会成为一个安全隐患。建议做三件事：

• 限制上传大小，SpringBoot里设置SpringServletMultipart的max-file-size和max-request-size；
• 校验文件类型，不能只看扩展名，要通过文件的ContentType判断；
• 文件名重新生成，不保留原始文件名，避免路径穿越。

我上传文件时用UUID生成新文件名，后缀名也做白名单校验。比如只允许jpg、png、gif、webp这几种格式，其他类型的文件一律返回错误提示。

6. 项目部署与上线实操

6.1 本地开发环境准备

开发时我的环境配置是这样的，你可以直接参考：

JDK 8 Maven 3.6.x MySQL 8.0 Redis 6.x（可选） SpringBoot 2.7.6 MyBatis-Plus 3.5.x

MySQL安装后，记得把数据库连接URL加上时区和字符集参数：

spring: datasource: url: jdbc:mysql://localhost:3306/farm_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 redis: host: localhost port: 6379

注意：application.yml里千万不要提交真实密码到Git仓库，实践时我一般用application-local.yml放本机配置，用application-prod.yml放服务器配置，启动时通过--spring.profiles.active指定环境。

6.2 项目打包与服务器部署

部署前先确认一件事：项目里的文件上传路径是否用了绝对路径。如果代码里写死“C:/upload/”，部署到Linux服务器上就会出问题。我建议在配置里定义一个file.upload-path，根据系统自动切换。

打包命令很简单：

mvn clean package -DskipTests

生成的可执行Jar包在target目录下，上传到服务器后：

nohup java -jar farm-system.jar --spring.profiles.active=prod > farm.log 2>&1 &

日志输出到farm.log，方便排查问题。如果想实现开机自启，可以在/etc/systemd/system下写一个systemd服务文件，也可以先用nohup顶着，后续再优化。

6.3 为什么建议用云服务器部署：演示与维护两不误

如果你是用在线演示或者答辩展示，云服务器几乎是必须的。本地只能你自己看到，评委和同学都看不到效果。云服务器选择轻量应用服务器即可，配置2核4G，带宽5Mbps就够一个演示项目使用。

部署时需要做的几件事：

• 安装JDK8和MySQL8；
• 执行项目里的init.sql创建数据库和表结构；
• 配置MySQL允许远程连接，或者直接服务器本机跑；
• 服务器安全组放行8080端口；
• 如果有域名，可以配置Nginx反向代理+HTTPS。

这整套部署流程非常成熟，跟着操作下来差不多一小时就搞定。而且你有了一次真实部署经验，以后面试聊项目时也更有底气。

7. 常见问题与排查技巧实录

7.1 跨域请求报错：前后端分离的第一道坎

典型报错是“Access to XMLHttpRequest has been blocked by CORS policy”。解决方式有几种：

• 后端加@CrossOrigin注解，但只能作用于单个Controller；
• 写一个CorsFilter全局配置类，允许指定前端地址跨域。

我在项目中写了全局跨域配置，允许携带Token的Authorization请求头，allowedOriginPatterns设为“*”或具体的前端地址，实际部署时建议设置成具体的域名或IP，更安全。

7.2 上传图片后浏览器无法访问

图片上传成功，数据库里也有路径，但浏览器输入地址却404。这个问题90%的原因是静态资源映射没有配。如果你是本地磁盘存储而不是用OSS，必须在SpringBoot里做映射：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceHandler("file:" + uploadPath + "/"); } }

这样访问http://域名/upload/xxx.jpg就能正常看到图片了。如果用了Nginx，也可以直接用Nginx的location /upload/配置指向磁盘目录，性能和配置都更好。

7.3 日期字段返回格式不对

默认情况下，Java的LocalDateTime序列化成JSON后可能是一长串数字或者带T的格式，前端显示很不友好。解决方式是全局配置Jackson格式化：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

也可以在每个实体类的日期字段上加@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")。两种方案选一种即可，我习惯用全局配置，省得每个字段都加。

7.4 数据库连接报错：时区与SSL

最常见的两个启动报错：

• “The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized” —— 原因是MySQL时区问题，解决就是URL加上serverTimezone=Asia/Shanghai；
• “SSL connection error” —— 在URL上加useSSL=false。

同时，MySQL 8的驱动类名是com.mysql.cj.jdbc.Driver，如果你复制了老项目的配置，用的是com.mysql.jdbc.Driver，启动时会报警告，建议换成新驱动类名。

7.5 Jar包运行后端口被占用或配置文件路径不对

打包后在服务器上运行，可能有几种新手易踩的问题：

• Jar包启动后提示端口8080被占用，用netstat -tunlp | grep 8080查看进程，或者启动时加--server.port=8090临时改端口；
• 启动时加载不到配置文件，因为配置文件在src/main/resources下面，打进去就不会有问题；如果你是外置配置文件，要加--spring.config.additional-location=file:/路径/application.yml；
• 数据库连不上，先用mysql -u root -p测试能否登录，再用telnet 127.0.0.1 3306测试端口，逐层排查。

7.6 订单并发量不高也要考虑事务和锁吗

很多人会觉得毕业设计不需要考虑并发。我的观点是：功能层面确实可以不考虑高并发，但代码层面写一个“防超卖”的update语句并不复杂，却能体现工程师的严谨性。而且这也是一个很好的答辩亮点。我建议在涉及扣减库存、修改订单状态的接口中加@Transactional，并在SQL的update语句中加入条件判断，比如“库存大于0”。

这些代码量很小，但确保逻辑不会出错的心态，和“只能演示静态数据”完全是两个Level。

7.7 开发提效：善用MyBatis-Plus的代码生成器

最后说一个能明显减少重复工作的经验。MyBatis-Plus提供了代码生成器，可以根据数据库表直接生成实体类、Mapper接口、Service和ServiceImpl，Controller也可以生成，但Controller建议自己写，因为生成模板不一定符合你的业务习惯。代码生成器只需要引入一个依赖，写一个简单的main方法执行即可。我开发这套系统时，十几张表靠代码生成器，只花了几分钟就把骨架搭好了，后面专心写业务逻辑和页面。这个工具非常适合时间紧张的同学。

8. 经验总结与后续扩展建议

做这个项目给我最大的体验是：一个看似“简单”的农家乐系统，真正落地时会牵扯到用户、订单、库存、权限、图片、统计等一堆环节。它不像纯电商系统那样强调复杂的支付和物流，但多业态融合的特点刚好适合用来展示全栈开发能力，也特别适合作为SpringBoot的综合性练手项目。

如果你按照这篇文章的思路把系统做完，有几件事后续还可以继续扩展：

• 接入真实支付：把模拟支付换成沙箱支付或微信支付Native支付，这个改动会显著增加系统的真实可用性；
• 增加多农庄入驻：如果想把系统做成平台型，可以增加农庄表，所有内容按农庄ID隔离；
• 增加统计报表的导出功能：用EasyExcel把经营数据导出成Excel，这也是企业里非常常见的需求；
• 增加消息通知：在订单状态变更时给用户发送短信或小程序订阅消息。

最后再分享一个小技巧：开发时一定要养成提交Git的习惯。每完成一个模块就提交一次代码，之后自己改坏了也能迅速回滚。我见过不少同学一个项目从头写到尾不提交，最后想退回某一版却无从下手。这个习惯从毕业设计开始养成，以后进入实际开发会非常受益。