简介这份 springboot 民宿管理平台源码与配套文档资源专为 Java 毕业设计和课程设计场景准备适合正在做酒店/民宿类管理系统课题的学生直接参考或二次开发。系统围绕“管理员—用户—商家”三类角色搭建权限体系管理员可管理用户、商家、民宿信息、房间类型及房间信息并处理房间预订与退订、投诉反馈和系统设置用户与商家则分别行使预订、收藏、维护信息等对应权限完整覆盖民宿业务核心闭环。项目基于 Spring Boot 开发使用 JDK1.8、MySQL5.7 和 Maven3.3.9可导入 Eclipse/MyEclipse/IDEA 直接运行有助于理解 RBAC 权限控制、业务表关系设计与订单状态流转等关键点。压缩包约 23.8MB内含项目源码、LW 文档和 PPT 演示材料便于答辩展示和本地部署。目前已有 571 人学习浏览是同类民宿管理系统中结构清晰、功能完整的参考案例。1. springboot 民宿管理平台的验收重心不是 CRUD是订单状态机毕业设计里出现“springboot民宿管理平台”很容易把它当成一个“房间表订单表几张页面”的 CRUD 项目。真实边界不在菜单里有几项而在订单状态怎么转顾客下单时冻结房间、取消后释放房间、入住后保持冻结、退房后重新放出。这些动作错一个房间里就会出现“同一个日期订给两个人”这种硬伤。所以这题表面是管理平台实际考的是 Spring Boot 的事务、乐观锁和状态机。这类平台最常见的交付包就是“springboot 源码 LW PPT”三件套。LW 在毕设语境里通常就是设计文档或论文需要把表结构、接口设计、状态流转说明白PPT 则用来现场把“民宿查询—登录—下单—状态变化”这条主线串起来。对读者来说拿到包后第一步是把它变成能跑的工程第二步才是逐个模块去理解。下面从建表、后端实现、本地运行到答辩排错按我个人在 Spring Boot 项目中顺手的顺序展开。2. 拆需求与建表民宿管理平台的数据边界怎么定拿“springboot民宿管理平台”这个题目不要一上来就打开 IDEA。先看题目里的名词和动词游客要查“还有什么房”用户要“下单”前台要“入住、退房”老板要“调价”。每个动词都会变成接口每个接口都会用到表。民宿和酒店的区别在于规模民宿没有几十个房型也没有渠道价格联动两张核心表加两张辅助表足够撑起演示链路。2.1 先从用户故事里定角色和状态流别急着写项目民宿管理平台我一般只保留四类角色管理员、前台、已登录用户、游客。管理员维护民宿资料和房价前台处理入住、退房、换房用户下单、取消订单、发表评价游客只能查房。四类角色对应到 Spring Boot 后端就是两条路径/api/auth/**放行/api/admin/**强制管理员/api/user/**要求登录。角色判断集中放在拦截器里不要散落在各个 Controller 的 if 里。订单状态也必须在建表前定死0 已预订1 已入住2 已退房3 已取消。合法跳转只有三条边0→1 入住、0→3 取消、1→2 退房。入住后不能取消这种限制不能只靠前端把按钮藏起来后端要在状态修改时做条件更新否则用 curl 直接打接口就能绕过去。另一个常见误用是把取消做成 delete统计订单时还得把已取消数据捞出来过滤正确做法是保留数据只变更状态。2.2 room 和 order 两张核心表用 DDL 把约束写清楚民宿平台里房间表和订单表直接决定业务能不能跑通。以下是我在源码包里常见的一套 MySQL DDLCREATE TABLE room ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL COMMENT 房号/房名, type VARCHAR(20) NOT NULL DEFAULT 大床房 COMMENT 房型, price DECIMAL(10,2) NOT NULL COMMENT 每晚价格, status TINYINT NOT NULL DEFAULT 0 COMMENT 0可订 1冻结, image_url VARCHAR(255) COMMENT 图片地址, version INT NOT NULL DEFAULT 0 COMMENT 乐观锁版本, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT 业务订单号, room_id BIGINT NOT NULL, customer_id BIGINT NOT NULL, check_in_date DATE NOT NULL, check_out_date DATE NOT NULL, nights INT NOT NULL COMMENT 入住晚数, total_amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0预订 1入住 2退房 3取消, version INT NOT NULL DEFAULT 0, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_room_date (room_id, check_in_date, check_out_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这两张表有四个设计点建议在 LW 文档里写清楚。room.status只表示“可订/冻结”不要存“被谁订了”真正的事实来源是order.status加version字段是为了配合 MyBatis-Plus 的乐观锁插件并发演示时能讲清楚被抢占的场景order_no用业务号而不是自增 id可以避免把表主键暴露给用户也能在日志里直接对应订单nights是冗余字段保存时计算而不是每次用 DATEDIFF查询房间列表时能少做一次日期运算代价是改入住日期时必须同时重算nights和total_amount。下面这张状态表也是文档里必备的一张表订单状态允许动作房间 status 变化事务注意点0 已预订取消/入住冻结创建订单更新订单和房间在同一事务1 已入住退房保持冻结入住时校验日期是否重叠2 已退房无释放为可订退房先查订单状态3 已取消无释放为可订用条件更新不能直接改状态房间能不能订不能只看room.status0还要查已经存在的已预订和已入住订单有没有日期重叠。判断用的是区间相交check_in_date 新离店日期 AND check_out_date 新入住日期。只看单个日期会漏掉跨天订单这也是我最常替毕设包改 SQL 的位置。2.3 application.yml 的 springboot 配置只调三个地方拿到源码先别改代码把 Spring Boot 的配置收拾好项目能跑起来才有下一步。常用配置可以收敛成这样spring: datasource: url: jdbc:mysql://localhost:3306/homestay?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue username: root password: root123 driver-class-name: com.mysql.cj.jdbc.Driver jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml 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 server: port: 8080url里的serverTimezoneAsia/Shanghai不能省省了在 MySQL 8.x 下会报时间偏移错误allowPublicKeyRetrievaltrue是 mysql-connector-j 8 连接本地 root 用户时的常见要求。map-underscore-to-camel-case开启后check_in_date才自动映射成checkInDate否则接口返回一堆 null。log-impl设为 StdOutImplMyBatis 最后执行的 SQL 会直接打到控制台排错比看前端报错快得多。如果源码用的是 H2 内存库演示时关一次服务数据就没了可以把 url 改成jdbc:h2:file:./data/homestay;MODEMySQL数据落在本地文件重启不会清空。遇到Access denied for user rootlocalhost先看 application.yml 的用户名密码是否和本机 MySQL 一致不要跳过配置文件直接在命令行里写额外参数那种方式只能验证连接不能解决源码运行问题。3. 用 Spring Boot 把民宿后台接口接起来登录、分页、订单状态机后端代码的风格决定了答辩时能不能讲清楚。不建议一个 Controller 对应一张表就完事民宿平台的三个核心链路要单独拆开认证链、房源链、订单链。下面的片段以 Spring Boot 2.7 MyBatis-Plus 为例这也是大多数毕设源码包的默认组合。3.1 登录接口与 JWT 拦截器一个 token 管住三种角色民宿管理平台不需要把 Spring Security 全套引进来一个 JWT 拦截器加角色判断就足够。登录接口返回 token后续请求通过Authorization头带回来。最简写法PostMapping(/login) public Result login(RequestBody LoginDTO dto) { User user userService.lambdaQuery() .eq(User::getUsername, dto.getUsername()) .one(); if (user null || !BCrypt.checkpw(dto.getPassword(), user.getPassword())) { return Result.error(用户名或密码错误); } String token JwtUtil.createToken(user.getId(), user.getRole()); return Result.ok(new LoginVO(token, user)); }BCrypt.checkpw用来比对哈希后的密码源码包里如果直接存的是明文也请换成哈希再演示。JwtUtil.createToken里一般放三个信息用户 id、角色、过期时间。过期时间 2 小时比较合适太短演示到一半要重新登录太长没法解释 JWT 防重放的价值。拦截器的注册放在实现类里比PreAuthorize注解更好讲控制所有/api/**请求的边界Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new JwtInterceptor()) .addPathPatterns(/api/**) .excludePathPatterns(/api/auth/login, /api/rooms/**); } }/api/rooms/**放行是因为游客也要查房源/api/admin/**在 JwtInterceptor 里校验 role 等于 admin。注意不要图省事排除/api/**不然拦截器等于白写。如果不写异常的全局处理JWT 解析失败返回的是 500建议在RestControllerAdvice里把ExpiredJwtException和SignatureException统一捕获返回 401 和一个可读信息。3.2 民宿房源的分页查询keyword 过滤和图片地址房源接口是首页门面数据量不大也要分页下面是 MyBatis-Plus 的写法GetMapping(/rooms) public Result pageRooms(RequestParam(defaultValue 1) int page, RequestParam(defaultValue 8) int size, RequestParam(required false) String keyword) { PageRoom p new Page(page, size); LambdaQueryWrapperRoom qw new LambdaQueryWrapper(); qw.eq(Room::getStatus, 0) .like(StringUtils.hasText(keyword), Room::getName, keyword) .orderByDesc(Room::getId); return Result.ok(roomService.page(p, qw)); }分页参数page和size必须给默认值避免前端不传时把整表拉出来。like的第一个参数是个条件表达式空 keyword 时不会拼LIKE子句这步我经常在评审时看到有人漏掉。orderByDesc(Room::getId)让新房间排前面和首页 UI 的“最新上架”对上。图片字段尽量存相对路径比如/upload/room101.jpg再在 Spring Boot 里把 upload 目录映射为静态资源spring: web: resources: static-locations: classpath:/static/,file:${upload-dir}图片入库的是“路径”不是“base64 字符串”。有的毕设包把图片塞进数据库前端拿到的 JSON 体积大一圈没有人会点赞。upload-dir的绝对路径写在配置里不要写死到某个同学自己的目录否则换一台电脑就 404。3.3 订单状态机一个 Service 类把事务说清楚订单接口里最重的一点不是增删改查而是怎么让“创建订单”“取消订单”“入住”“退房”四个动作都守住各自的状态边界。先用一张小表说清动作和状态的关系业务动作前置状态后置状态房间处理创建订单无0 已预订冻结房间取消订单0 已预订3 已取消释放房间办理入住0 已预订1 已入住保持冻结办理退房1 已入住2 已退房释放房间创建订单的代码要回答“并发抢房”的问题Transactional(rollbackFor Exception.class) public Order createOrder(Long roomId, Long customerId, LocalDate start, LocalDate end) { long nights ChronoUnit.DAYS.between(start, end); if (nights 0) throw new BizException(离店日期必须晚于入住日期); Room room roomMapper.selectByIdForUpdate(roomId); if (room null || room.getStatus() ! 0) { throw new BizException(房间不可预订); } Long conflict orderMapper.countConflict(roomId, start, end); if (conflict 0) { throw new BizException(该日期区间已被预订); } Order order new Order(); order.setOrderNo(generateOrderNo()); order.setRoomId(roomId); order.setCustomerId(customerId); order.setCheckInDate(start); order.setCheckOutDate(end); order.setNights((int) nights); order.setTotalAmount(room.getPrice().multiply(BigDecimal.valueOf(nights))); order.setStatus(0); orderMapper.insert(order); roomMapper.freeze(roomId); return order; }selectByIdForUpdate是把 room 这一行锁住防止两个人同时查到“可订”。countConflict对应的 SQL 是where room_id ? and status in (0,1) and check_in_date #{end} and check_out_date #{start}。整个方法标了Transactional(rollbackFor Exception.class)这个rollbackFor很关键因为如果自定义异常不是 RuntimeExceptionSpring 默认不会回滚。取消订单不建议用“先查后改”常见做法是直接条件更新int rows orderMapper.cancelIfStatus(orderId, 3, 0); if (rows 0) throw new BizException(只有已预订的订单能取消); roomMapper.release(orderId);cancelIfStatus发的是update order set status3 where id? and status0。受影响行数是 0说明订单已经被别人改成入住或取消返回错误信息就行。提示cancelIfStatus返回受影响行数不要用selectById后判断再updateById两个请求同时读到状态 0 时都会通过判断并发下会把已经入住的订单又取消一次。4. 从 zip 包落地的顺序IDEA 导入、数据库脚本和演示数据毕设交付包里常见一堆文件夹里面有源码、LW 文档和 PPT。遇到这种包最忌讳的是双击Application.java等页面白屏再去翻配置文件。稳妥的顺序是解压、看 pom.xml、看 sql、看 application.yml然后启动。4.1 解压 zip 后优先确认这四项文件不管 zip 从哪来先找这四个东西pom.xml确认 Spring Boot 版本、JDK 版本和依赖是否齐全*.sql确认建表脚本是否带初始数据application.yml/application.properties确认数据库、端口、上传路径README.md或 LW 文档里的“运行说明”很多包作者会把默认账号写在这里。如果只有 target 目录和 jar没有源码说明包里的“源码”其实只剩编译产物答辩时要小心。看pom.xml时spring-boot-starter-parent的版本和本地 JDK 要对齐Spring Boot 3.x 要求 JDK 17Spring Boot 2.7 用 JDK 8 或 11 都能跑。这个判断能帮你避开一半的 java 环境问题也是面试题里常考的起步点。4.2 用 IDEA 导入 Maven 工程并初始化数据库用 IDEA 导入 Spring Boot 项目和新建空项目略有不同但都从同一个入口进File - Open选中解压后的根目录或 pom.xmlIDEA 会识别成 Maven 工程。依赖下载完成后按顺序执行两条命令mysql -uroot -p db/homestay.sql mvn spring-boot:run第一条命令把数据库脚本导入本机 MySQL第二条命令启动 Spring Boot。如果源码包里没有sql目录按第 2.2 节的建表语句手动建库再插入 3 条房型数据首页也能撑起来。IDEA 里如果报无效的源发行版 17到Project Structure - Project - SDK把项目 SDK 和 pom.xml 里的java.version对齐Maven 依赖标红时先在终端跑mvn -U clean install -DskipTests强制刷新远程仓库而不是乱改版本号。启动日志出现Tomcat started on port 8080访问http://localhost:8080能看到首页后端就算通了。如果源码包含 Swagger再打开/doc.html或/swagger-ui.html可以直接在浏览器里点接口测试这一步比 Postman 更省事。4.3 预置演示数据把账号、房态和订单做成表格毕设演示最尴尬的是演示到一半没有数据。我一般会在 sql 脚本里预置这些值类型示例值用途管理员admin / admin123登录后台管理房间普通用户zhangsan / 123456前端用户下单房间 101大床房 298.00 可订首页展示房间 102海景房 398.00 已预订演示订单列表房间 103亲子房 528.00 可订演示下单并查看状态变化这些数据足够跑通“游客查房 - 登录 - 下单 - 管理端入住 - 退房”整条链路。PPT 里的截图也要用同一批数据别在 PPT 里叫“房间 A/B”系统里又变成“一号楼 203”评委对不上号会以为你对业务不熟。LW 文档的测试章节建议同样引用这套数据把输入、输出、结果列成表不要只写“系统测试通过”。订单从 0 到 2 的截图和数据库字段的变化对照是答辩时最容易展开讲的部分。5. 验收前过一遍接口自测、Spring Boot 版本冲突和订单回放技巧最后一轮不补功能只给现场留退路。从运行日志到接口返回能用一条命令验证的绝不去页面上点三次。5.1 用 curl 和 Actuator 做 5 分钟冒烟检查先确认 Spring Boot 活着curl http://localhost:8080/actuator/health curl -X POST http://localhost:8080/api/auth/login \ -H Content-Type: application/json \ -d {username:admin,password:admin123}/actuator/health返回{status:UP}说明框架层正常登录接口返回 token 后把它带进房源查询curl http://localhost:8080/api/rooms?page1size5 -H Authorization: Bearer $TOKEN这条命令验证了 Spring Boot 配置、数据库连接、MyBatis 分页、JWT 拦截器四个环节。一旦报错先看控制台的 StdOutImpl 打出的 SQL能定位大部分问题。5.2 springboot 版本太高时要检查的三个地方如果包是 Spring Boot 3.x而答辩电脑是 JDK 8java -jar会直接失败。要检查三个地方javax.servlet.*已经换名成jakarta.servlet.*拦截器/过滤器还在引老包会ClassNotFoundExceptionMyBatis-Plus 要用mybatis-plus-spring-boot3-starter继续用mybatis-plus-boot-starter会出现 Invalid bound statement内嵌 Tomcat 版本升级后 JSP 支持默认关闭页面是 JSP 的访问不到。民宿管理平台尽量用 Thymeleaf 或静态 Vue 构建页面。排查时按CtrlShiftF全局搜javax.替换成jakarta.再调整 mybatis-plus 的 starter 坐标多数兼容问题都能解决。5.3 把订单状态变更变成“时间线”演示效果立住比口头讲状态机更有效的方式是让状态变更可以回放。常见做法是加一张order_log字段就四个id、order_id、from_status、to_status、create_time。在状态变更方法末尾追加一条记录orderLogService.save(new OrderLog(order.getId(), oldStatus, order.getStatus()));演示时管理端页面显示“2025-01-06 14:20:10 已预订 - 已入住”评委能直接看到状态转移可观测。LW 文档里把这个设计写成“基于操作日志的订单审计”比只写“我用了 Spring Boot”更有信息量。验证这张表是否生效退房后执行最后一次查询SELECT order_id, from_status, to_status, create_time FROM order_log WHERE order_id 1 ORDER BY create_time DESC;本文还有配套的精品资源点击获取 SpringBoot民宿管理平台实战：订单状态机与事务设计核心解析
简介这份 springboot 民宿管理平台源码与配套文档资源专为 Java 毕业设计和课程设计场景准备适合正在做酒店/民宿类管理系统课题的学生直接参考或二次开发。系统围绕“管理员—用户—商家”三类角色搭建权限体系管理员可管理用户、商家、民宿信息、房间类型及房间信息并处理房间预订与退订、投诉反馈和系统设置用户与商家则分别行使预订、收藏、维护信息等对应权限完整覆盖民宿业务核心闭环。项目基于 Spring Boot 开发使用 JDK1.8、MySQL5.7 和 Maven3.3.9可导入 Eclipse/MyEclipse/IDEA 直接运行有助于理解 RBAC 权限控制、业务表关系设计与订单状态流转等关键点。压缩包约 23.8MB内含项目源码、LW 文档和 PPT 演示材料便于答辩展示和本地部署。目前已有 571 人学习浏览是同类民宿管理系统中结构清晰、功能完整的参考案例。1. springboot 民宿管理平台的验收重心不是 CRUD是订单状态机毕业设计里出现“springboot民宿管理平台”很容易把它当成一个“房间表订单表几张页面”的 CRUD 项目。真实边界不在菜单里有几项而在订单状态怎么转顾客下单时冻结房间、取消后释放房间、入住后保持冻结、退房后重新放出。这些动作错一个房间里就会出现“同一个日期订给两个人”这种硬伤。所以这题表面是管理平台实际考的是 Spring Boot 的事务、乐观锁和状态机。这类平台最常见的交付包就是“springboot 源码 LW PPT”三件套。LW 在毕设语境里通常就是设计文档或论文需要把表结构、接口设计、状态流转说明白PPT 则用来现场把“民宿查询—登录—下单—状态变化”这条主线串起来。对读者来说拿到包后第一步是把它变成能跑的工程第二步才是逐个模块去理解。下面从建表、后端实现、本地运行到答辩排错按我个人在 Spring Boot 项目中顺手的顺序展开。2. 拆需求与建表民宿管理平台的数据边界怎么定拿“springboot民宿管理平台”这个题目不要一上来就打开 IDEA。先看题目里的名词和动词游客要查“还有什么房”用户要“下单”前台要“入住、退房”老板要“调价”。每个动词都会变成接口每个接口都会用到表。民宿和酒店的区别在于规模民宿没有几十个房型也没有渠道价格联动两张核心表加两张辅助表足够撑起演示链路。2.1 先从用户故事里定角色和状态流别急着写项目民宿管理平台我一般只保留四类角色管理员、前台、已登录用户、游客。管理员维护民宿资料和房价前台处理入住、退房、换房用户下单、取消订单、发表评价游客只能查房。四类角色对应到 Spring Boot 后端就是两条路径/api/auth/**放行/api/admin/**强制管理员/api/user/**要求登录。角色判断集中放在拦截器里不要散落在各个 Controller 的 if 里。订单状态也必须在建表前定死0 已预订1 已入住2 已退房3 已取消。合法跳转只有三条边0→1 入住、0→3 取消、1→2 退房。入住后不能取消这种限制不能只靠前端把按钮藏起来后端要在状态修改时做条件更新否则用 curl 直接打接口就能绕过去。另一个常见误用是把取消做成 delete统计订单时还得把已取消数据捞出来过滤正确做法是保留数据只变更状态。2.2 room 和 order 两张核心表用 DDL 把约束写清楚民宿平台里房间表和订单表直接决定业务能不能跑通。以下是我在源码包里常见的一套 MySQL DDLCREATE TABLE room ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL COMMENT 房号/房名, type VARCHAR(20) NOT NULL DEFAULT 大床房 COMMENT 房型, price DECIMAL(10,2) NOT NULL COMMENT 每晚价格, status TINYINT NOT NULL DEFAULT 0 COMMENT 0可订 1冻结, image_url VARCHAR(255) COMMENT 图片地址, version INT NOT NULL DEFAULT 0 COMMENT 乐观锁版本, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT 业务订单号, room_id BIGINT NOT NULL, customer_id BIGINT NOT NULL, check_in_date DATE NOT NULL, check_out_date DATE NOT NULL, nights INT NOT NULL COMMENT 入住晚数, total_amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0预订 1入住 2退房 3取消, version INT NOT NULL DEFAULT 0, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_room_date (room_id, check_in_date, check_out_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这两张表有四个设计点建议在 LW 文档里写清楚。room.status只表示“可订/冻结”不要存“被谁订了”真正的事实来源是order.status加version字段是为了配合 MyBatis-Plus 的乐观锁插件并发演示时能讲清楚被抢占的场景order_no用业务号而不是自增 id可以避免把表主键暴露给用户也能在日志里直接对应订单nights是冗余字段保存时计算而不是每次用 DATEDIFF查询房间列表时能少做一次日期运算代价是改入住日期时必须同时重算nights和total_amount。下面这张状态表也是文档里必备的一张表订单状态允许动作房间 status 变化事务注意点0 已预订取消/入住冻结创建订单更新订单和房间在同一事务1 已入住退房保持冻结入住时校验日期是否重叠2 已退房无释放为可订退房先查订单状态3 已取消无释放为可订用条件更新不能直接改状态房间能不能订不能只看room.status0还要查已经存在的已预订和已入住订单有没有日期重叠。判断用的是区间相交check_in_date 新离店日期 AND check_out_date 新入住日期。只看单个日期会漏掉跨天订单这也是我最常替毕设包改 SQL 的位置。2.3 application.yml 的 springboot 配置只调三个地方拿到源码先别改代码把 Spring Boot 的配置收拾好项目能跑起来才有下一步。常用配置可以收敛成这样spring: datasource: url: jdbc:mysql://localhost:3306/homestay?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue username: root password: root123 driver-class-name: com.mysql.cj.jdbc.Driver jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml 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 server: port: 8080url里的serverTimezoneAsia/Shanghai不能省省了在 MySQL 8.x 下会报时间偏移错误allowPublicKeyRetrievaltrue是 mysql-connector-j 8 连接本地 root 用户时的常见要求。map-underscore-to-camel-case开启后check_in_date才自动映射成checkInDate否则接口返回一堆 null。log-impl设为 StdOutImplMyBatis 最后执行的 SQL 会直接打到控制台排错比看前端报错快得多。如果源码用的是 H2 内存库演示时关一次服务数据就没了可以把 url 改成jdbc:h2:file:./data/homestay;MODEMySQL数据落在本地文件重启不会清空。遇到Access denied for user rootlocalhost先看 application.yml 的用户名密码是否和本机 MySQL 一致不要跳过配置文件直接在命令行里写额外参数那种方式只能验证连接不能解决源码运行问题。3. 用 Spring Boot 把民宿后台接口接起来登录、分页、订单状态机后端代码的风格决定了答辩时能不能讲清楚。不建议一个 Controller 对应一张表就完事民宿平台的三个核心链路要单独拆开认证链、房源链、订单链。下面的片段以 Spring Boot 2.7 MyBatis-Plus 为例这也是大多数毕设源码包的默认组合。3.1 登录接口与 JWT 拦截器一个 token 管住三种角色民宿管理平台不需要把 Spring Security 全套引进来一个 JWT 拦截器加角色判断就足够。登录接口返回 token后续请求通过Authorization头带回来。最简写法PostMapping(/login) public Result login(RequestBody LoginDTO dto) { User user userService.lambdaQuery() .eq(User::getUsername, dto.getUsername()) .one(); if (user null || !BCrypt.checkpw(dto.getPassword(), user.getPassword())) { return Result.error(用户名或密码错误); } String token JwtUtil.createToken(user.getId(), user.getRole()); return Result.ok(new LoginVO(token, user)); }BCrypt.checkpw用来比对哈希后的密码源码包里如果直接存的是明文也请换成哈希再演示。JwtUtil.createToken里一般放三个信息用户 id、角色、过期时间。过期时间 2 小时比较合适太短演示到一半要重新登录太长没法解释 JWT 防重放的价值。拦截器的注册放在实现类里比PreAuthorize注解更好讲控制所有/api/**请求的边界Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new JwtInterceptor()) .addPathPatterns(/api/**) .excludePathPatterns(/api/auth/login, /api/rooms/**); } }/api/rooms/**放行是因为游客也要查房源/api/admin/**在 JwtInterceptor 里校验 role 等于 admin。注意不要图省事排除/api/**不然拦截器等于白写。如果不写异常的全局处理JWT 解析失败返回的是 500建议在RestControllerAdvice里把ExpiredJwtException和SignatureException统一捕获返回 401 和一个可读信息。3.2 民宿房源的分页查询keyword 过滤和图片地址房源接口是首页门面数据量不大也要分页下面是 MyBatis-Plus 的写法GetMapping(/rooms) public Result pageRooms(RequestParam(defaultValue 1) int page, RequestParam(defaultValue 8) int size, RequestParam(required false) String keyword) { PageRoom p new Page(page, size); LambdaQueryWrapperRoom qw new LambdaQueryWrapper(); qw.eq(Room::getStatus, 0) .like(StringUtils.hasText(keyword), Room::getName, keyword) .orderByDesc(Room::getId); return Result.ok(roomService.page(p, qw)); }分页参数page和size必须给默认值避免前端不传时把整表拉出来。like的第一个参数是个条件表达式空 keyword 时不会拼LIKE子句这步我经常在评审时看到有人漏掉。orderByDesc(Room::getId)让新房间排前面和首页 UI 的“最新上架”对上。图片字段尽量存相对路径比如/upload/room101.jpg再在 Spring Boot 里把 upload 目录映射为静态资源spring: web: resources: static-locations: classpath:/static/,file:${upload-dir}图片入库的是“路径”不是“base64 字符串”。有的毕设包把图片塞进数据库前端拿到的 JSON 体积大一圈没有人会点赞。upload-dir的绝对路径写在配置里不要写死到某个同学自己的目录否则换一台电脑就 404。3.3 订单状态机一个 Service 类把事务说清楚订单接口里最重的一点不是增删改查而是怎么让“创建订单”“取消订单”“入住”“退房”四个动作都守住各自的状态边界。先用一张小表说清动作和状态的关系业务动作前置状态后置状态房间处理创建订单无0 已预订冻结房间取消订单0 已预订3 已取消释放房间办理入住0 已预订1 已入住保持冻结办理退房1 已入住2 已退房释放房间创建订单的代码要回答“并发抢房”的问题Transactional(rollbackFor Exception.class) public Order createOrder(Long roomId, Long customerId, LocalDate start, LocalDate end) { long nights ChronoUnit.DAYS.between(start, end); if (nights 0) throw new BizException(离店日期必须晚于入住日期); Room room roomMapper.selectByIdForUpdate(roomId); if (room null || room.getStatus() ! 0) { throw new BizException(房间不可预订); } Long conflict orderMapper.countConflict(roomId, start, end); if (conflict 0) { throw new BizException(该日期区间已被预订); } Order order new Order(); order.setOrderNo(generateOrderNo()); order.setRoomId(roomId); order.setCustomerId(customerId); order.setCheckInDate(start); order.setCheckOutDate(end); order.setNights((int) nights); order.setTotalAmount(room.getPrice().multiply(BigDecimal.valueOf(nights))); order.setStatus(0); orderMapper.insert(order); roomMapper.freeze(roomId); return order; }selectByIdForUpdate是把 room 这一行锁住防止两个人同时查到“可订”。countConflict对应的 SQL 是where room_id ? and status in (0,1) and check_in_date #{end} and check_out_date #{start}。整个方法标了Transactional(rollbackFor Exception.class)这个rollbackFor很关键因为如果自定义异常不是 RuntimeExceptionSpring 默认不会回滚。取消订单不建议用“先查后改”常见做法是直接条件更新int rows orderMapper.cancelIfStatus(orderId, 3, 0); if (rows 0) throw new BizException(只有已预订的订单能取消); roomMapper.release(orderId);cancelIfStatus发的是update order set status3 where id? and status0。受影响行数是 0说明订单已经被别人改成入住或取消返回错误信息就行。提示cancelIfStatus返回受影响行数不要用selectById后判断再updateById两个请求同时读到状态 0 时都会通过判断并发下会把已经入住的订单又取消一次。4. 从 zip 包落地的顺序IDEA 导入、数据库脚本和演示数据毕设交付包里常见一堆文件夹里面有源码、LW 文档和 PPT。遇到这种包最忌讳的是双击Application.java等页面白屏再去翻配置文件。稳妥的顺序是解压、看 pom.xml、看 sql、看 application.yml然后启动。4.1 解压 zip 后优先确认这四项文件不管 zip 从哪来先找这四个东西pom.xml确认 Spring Boot 版本、JDK 版本和依赖是否齐全*.sql确认建表脚本是否带初始数据application.yml/application.properties确认数据库、端口、上传路径README.md或 LW 文档里的“运行说明”很多包作者会把默认账号写在这里。如果只有 target 目录和 jar没有源码说明包里的“源码”其实只剩编译产物答辩时要小心。看pom.xml时spring-boot-starter-parent的版本和本地 JDK 要对齐Spring Boot 3.x 要求 JDK 17Spring Boot 2.7 用 JDK 8 或 11 都能跑。这个判断能帮你避开一半的 java 环境问题也是面试题里常考的起步点。4.2 用 IDEA 导入 Maven 工程并初始化数据库用 IDEA 导入 Spring Boot 项目和新建空项目略有不同但都从同一个入口进File - Open选中解压后的根目录或 pom.xmlIDEA 会识别成 Maven 工程。依赖下载完成后按顺序执行两条命令mysql -uroot -p db/homestay.sql mvn spring-boot:run第一条命令把数据库脚本导入本机 MySQL第二条命令启动 Spring Boot。如果源码包里没有sql目录按第 2.2 节的建表语句手动建库再插入 3 条房型数据首页也能撑起来。IDEA 里如果报无效的源发行版 17到Project Structure - Project - SDK把项目 SDK 和 pom.xml 里的java.version对齐Maven 依赖标红时先在终端跑mvn -U clean install -DskipTests强制刷新远程仓库而不是乱改版本号。启动日志出现Tomcat started on port 8080访问http://localhost:8080能看到首页后端就算通了。如果源码包含 Swagger再打开/doc.html或/swagger-ui.html可以直接在浏览器里点接口测试这一步比 Postman 更省事。4.3 预置演示数据把账号、房态和订单做成表格毕设演示最尴尬的是演示到一半没有数据。我一般会在 sql 脚本里预置这些值类型示例值用途管理员admin / admin123登录后台管理房间普通用户zhangsan / 123456前端用户下单房间 101大床房 298.00 可订首页展示房间 102海景房 398.00 已预订演示订单列表房间 103亲子房 528.00 可订演示下单并查看状态变化这些数据足够跑通“游客查房 - 登录 - 下单 - 管理端入住 - 退房”整条链路。PPT 里的截图也要用同一批数据别在 PPT 里叫“房间 A/B”系统里又变成“一号楼 203”评委对不上号会以为你对业务不熟。LW 文档的测试章节建议同样引用这套数据把输入、输出、结果列成表不要只写“系统测试通过”。订单从 0 到 2 的截图和数据库字段的变化对照是答辩时最容易展开讲的部分。5. 验收前过一遍接口自测、Spring Boot 版本冲突和订单回放技巧最后一轮不补功能只给现场留退路。从运行日志到接口返回能用一条命令验证的绝不去页面上点三次。5.1 用 curl 和 Actuator 做 5 分钟冒烟检查先确认 Spring Boot 活着curl http://localhost:8080/actuator/health curl -X POST http://localhost:8080/api/auth/login \ -H Content-Type: application/json \ -d {username:admin,password:admin123}/actuator/health返回{status:UP}说明框架层正常登录接口返回 token 后把它带进房源查询curl http://localhost:8080/api/rooms?page1size5 -H Authorization: Bearer $TOKEN这条命令验证了 Spring Boot 配置、数据库连接、MyBatis 分页、JWT 拦截器四个环节。一旦报错先看控制台的 StdOutImpl 打出的 SQL能定位大部分问题。5.2 springboot 版本太高时要检查的三个地方如果包是 Spring Boot 3.x而答辩电脑是 JDK 8java -jar会直接失败。要检查三个地方javax.servlet.*已经换名成jakarta.servlet.*拦截器/过滤器还在引老包会ClassNotFoundExceptionMyBatis-Plus 要用mybatis-plus-spring-boot3-starter继续用mybatis-plus-boot-starter会出现 Invalid bound statement内嵌 Tomcat 版本升级后 JSP 支持默认关闭页面是 JSP 的访问不到。民宿管理平台尽量用 Thymeleaf 或静态 Vue 构建页面。排查时按CtrlShiftF全局搜javax.替换成jakarta.再调整 mybatis-plus 的 starter 坐标多数兼容问题都能解决。5.3 把订单状态变更变成“时间线”演示效果立住比口头讲状态机更有效的方式是让状态变更可以回放。常见做法是加一张order_log字段就四个id、order_id、from_status、to_status、create_time。在状态变更方法末尾追加一条记录orderLogService.save(new OrderLog(order.getId(), oldStatus, order.getStatus()));演示时管理端页面显示“2025-01-06 14:20:10 已预订 - 已入住”评委能直接看到状态转移可观测。LW 文档里把这个设计写成“基于操作日志的订单审计”比只写“我用了 Spring Boot”更有信息量。验证这张表是否生效退房后执行最后一次查询SELECT order_id, from_status, to_status, create_time FROM order_log WHERE order_id 1 ORDER BY create_time DESC;本文还有配套的精品资源点击获取