尧图网页设计 
简介本资源为基于Spring Boot的民宿管理平台毕业设计全套资料面向计算机相关专业需要完成毕设的本科生尤其适合选择Java Web方向、希望快速搭建可运行系统的同学。包内包含完整论文、项目源码与PPT答辩材料覆盖绪论、关键技术、系统分析、系统设计、系统实现与系统测试等章节涉及Java、Eclipse、Tomcat、Spring Boot及MySQL数据库等知识点并给出管理员、商家用户、普通用户与前台首页四类功能模块的UML用例与流程分析。资源共841个文件以138个java源码、50个vue组件、48个html页面、44个css样式、153个js脚本及1个sql数据库脚本为主另含docx论文、ppt答辩稿与bat启动脚本压缩包约22.16MB目录结构清晰便于按模块查阅。已有57人学习下载可帮助读者获得完整赛题方案、可运行源码、数据库表设计与答辩演示思路适合作为毕设参考与二次开发基础。1. 民宿管理平台为什么总在“房态”这一步翻车做过民宿管理平台的人大多有个共同体会功能列表能写满两页纸真正上线后最先崩的往往是最不起眼的房态同步。房源、订单、入住人、保洁、渠道价这几张表一旦没设计好后面加一个“连住优惠”就能把整个订单模块推倒重来。这个标题讲的就是用 SpringBoot 搭一套能跑起来的民宿管理平台从库表设计到接口联调再到论文、源码、答辩 PPT 这条完整交付链路。它适合正在做课程设计、毕业设计或者想拿一个真实业务练手 SpringBoot 全栈的开发者。核心不是把功能堆多而是把房态、订单、权限这三条主线打通让系统能真正跑起来而不是只停留在演示截图。2. 民宿管理平台的领域建模与 SpringBoot 选型2.1 先想清楚业务边界再决定建几张表民宿和酒店最大的区别在于房源是非标准化的一套院子可能拆成三个独立房间也可能整租同一间房在不同渠道自营、OTA、线下价格不一样入住时间、退房时间、保洁间隔都带业务规则。如果一上来就照着酒店 PMS 抄表结构后面必然要改。我一般会把核心实体收敛到六张主表homestay民宿/房源、room_type房型、room具体房间、order订单、guest入住人、user后台账号。房态不单独建表而是用room上的状态字段加一张room_calendar日历表来记录每天的可售状态。这样查某天有没有房只需要按日期范围扫日历表比实时计算订单占用要快得多。-- 房态日历表一行代表某房间某一天的状态 CREATE TABLE room_calendar ( id BIGINT PRIMARY KEY AUTO_INCREMENT, room_id BIGINT NOT NULL COMMENT 房间ID, calendar_date DATE NOT NULL COMMENT 日期, status TINYINT NOT NULL DEFAULT 0 COMMENT 0可售 1已订 2锁定 3维修, price DECIMAL(10,2) NOT NULL COMMENT 当日价格, order_id BIGINT DEFAULT NULL COMMENT 关联订单, UNIQUE KEY uk_room_date (room_id, calendar_date) ) COMMENT 房态日历;这里的关键是uk_room_date唯一索引。下单时用INSERT ... ON DUPLICATE KEY UPDATE或者先查后改配合数据库唯一约束能挡住并发重复下单。status用整型而不是字符串是为了后续做状态机流转时判断更省事。price放在日历表而不是房型表是因为民宿周末和节假日价格浮动是常态按天存价格比按房型存更贴近真实业务。2.2 SpringBoot 版本和依赖怎么选才不给自己挖坑热搜里“springboot版本太高”是个高频抱怨。我的建议是如果这是毕设或课程项目不要追最新版。SpringBoot 3.x 要求 JDK 17很多学校的实验环境还停在 JDK 8一升级就报NoClassDefFoundError。稳妥组合是 SpringBoot 2.7.x JDK 8 或 11MyBatis-Plus 3.5.xMySQL 8.0。这套组合资料多、报错好搜、答辩时老师也认。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency /dependenciesspring-boot-starter-parent统一管理版本避免自己一个个填版本号填出冲突。MyBatis-Plus 比原生 MyBatis 省掉大量 XML做毕设这种 CRUD 密集的项目性价比很高。注意mysql-connector-java在 MySQL 8 下要配serverTimezoneAsia/Shanghai否则启动时报时区错误这是新手最常见的翻车点之一。2.3 项目结构按职责分层别全塞进 controller热搜里“springboot项目结构”被反复搜说明很多人卡在这一步。我一般用四层controller只做参数校验和返回封装service写业务逻辑mapper管数据库entity和dto分开。DTO 用于接收前端参数Entity 对应数据库表两者不要混用否则前端多传一个字段就可能被直接写进库。RestController RequestMapping(/api/room) public class RoomController { Resource private RoomService roomService; // 查询某日期范围内可售房间 GetMapping(/available) public ResultListRoomVO available(RequestParam String checkIn, RequestParam String checkOut) { return Result.ok(roomService.listAvailable(checkIn, checkOut)); } }RequestParam接收日期字符串在 service 层再转成LocalDate这样 controller 保持轻薄。Result是统一返回体包含 code、msg、data 三个字段前端处理起来一致。把日期解析放在 service 而不是 controller是为了将来换日期格式时只改一处。这套结构看起来朴素但答辩时老师问“你的业务逻辑写在哪”能直接指出来比全堆在 controller 里强得多。3. 从建库到接口联通的完整落地步骤3.1 数据库初始化与房态查询 SQL建库脚本建议单独放一个schema.sql方便换环境时一键重建。除了前面说的room_calendar订单表要留好状态字段和渠道字段。CREATE TABLE order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 订单号, room_id BIGINT NOT NULL, guest_name VARCHAR(50) NOT NULL, guest_phone VARCHAR(20) NOT NULL, check_in DATE NOT NULL, check_out DATE NOT NULL, total_amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已入住 3已完成 4已取消, channel VARCHAR(20) DEFAULT self COMMENT 渠道, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_order_no (order_no) ) COMMENT 订单表;order_no加唯一索引防止重复提交生成两笔订单。status用整型配合枚举类管理比直接存中文状态名更规范。channel字段是为将来接多渠道预留的现在不用但留着不亏。查可售房间的 SQL 是核心思路是先按日期范围查日历表里状态为可售的房间再排除已被订单占用的。SELECT r.id, r.room_no, rc.price FROM room r JOIN room_calendar rc ON rc.room_id r.id WHERE rc.calendar_date #{checkIn} AND rc.calendar_date #{checkOut} AND rc.status 0 GROUP BY r.id HAVING COUNT(rc.calendar_date) DATEDIFF(#{checkOut}, #{checkIn});HAVING COUNT(...) DATEDIFF(...)这句是精髓只有范围内每一天都可售的房间才会被选出来。如果某天被订走count 就会小于天数自动排除。这个写法比在 Java 里循环判断要快也更容易在答辩时讲清楚。3.2 下单接口的并发控制与事务边界下单是民宿平台最容易出问题的地方。两个人同时看中同一间房如果不在数据库层面加锁就会超卖。我一般用“日历表行锁 事务”来解决。Service public class OrderServiceImpl implements OrderService { Resource private RoomCalendarMapper calendarMapper; Resource private OrderMapper orderMapper; Override Transactional(rollbackFor Exception.class) public String createOrder(OrderCreateDTO dto) { // 1. 锁定日期范围内的日历行 ListRoomCalendar calendars calendarMapper .selectForUpdate(dto.getRoomId(), dto.getCheckIn(), dto.getCheckOut()); // 2. 校验是否全部可售 for (RoomCalendar c : calendars) { if (c.getStatus() ! 0) { throw new BizException(房态已被占用); } } // 3. 更新日历状态 calendarMapper.updateStatus(dto.getRoomId(), dto.getCheckIn(), dto.getCheckOut(), 1); // 4. 写入订单 Order order buildOrder(dto); orderMapper.insert(order); return order.getOrderNo(); } }selectForUpdate会对查询到的行加排他锁第二个请求进来时会阻塞等第一个事务提交后再执行此时状态已变成 1校验就会失败。Transactional的rollbackFor Exception.class保证任何异常都回滚避免出现日历改了但订单没写进去的脏数据。这里要注意锁的范围不能太大只锁目标房间和日期范围否则并发一高就全表排队。3.3 前后端联调与跨浏览器兼容处理热搜里“跨浏览器支持的设计与实现”和“vue打包放进springboot中”都指向同一个问题前端怎么和后端一起交付。我的做法是 Vue 打包后把dist目录丢进 SpringBoot 的resources/static后端加一个配置类处理前端路由。Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/**) .addResourceLocations(classpath:/static/); } Override public void addViewControllers(ViewControllerRegistry registry) { // 前端路由刷新不 404 registry.addViewController(/{path:[^\\.]*}) .setViewName(forward:/index.html); } }addResourceHandlers让静态资源能被访问addViewController把非文件路径的请求都转发到index.html解决 Vue history 模式刷新 404。跨浏览器方面主要是日期控件和 flex 布局在旧版浏览器上的差异建议用dayjs替代原生 Date 处理样式上避免用太新的 CSS 属性。联调时先用 Postman 把接口跑通再让前端接能省掉大量“到底是前端还是后端问题”的扯皮。4. 民宿平台开发中最容易踩的五个坑4.1 日期跨天导致房态算错现象用户订 1 月 1 日到 1 月 3 日系统只锁了 1 日和 2 日3 日还能被订。原因退房当天不应该算占用但查询时用了 checkOut。解决统一约定check_in date check_outSQL 里用而不是Java 里用LocalDate的isBefore判断。4.2 事务里调远程接口导致锁超时现象下单接口偶尔报Lock wait timeout exceeded。原因在Transactional方法里调了短信或支付接口事务迟迟不提交行锁一直不释放。解决把远程调用挪到事务提交之后用TransactionSynchronizationManager的afterCommit回调或者先落订单再异步发通知。4.3 SpringBoot 版本和 JDK 不匹配现象启动报Unsupported class file major version。原因SpringBoot 3.x 需要 JDK 17环境里是 JDK 8。解决要么降 SpringBoot 到 2.7.x要么升 JDK。毕设项目建议降版本改pom.xml里的 parent 版本即可别去折腾环境变量。4.4 前端打包后接口 404现象本地开发正常打包放进 SpringBoot 后接口全 404。原因前端 axios 的 baseURL 写的是localhost:8080打包后请求路径不对。解决baseURL 改成相对路径/api配合后端context-path统一前缀开发环境用代理转发。4.5 房态日历表数据没初始化现象查询可售房间永远返回空。原因新建房间后没有生成未来几个月的日历记录。解决在新增房间的 service 里批量插入未来 90 天的日历行状态默认 0价格取房型默认价。这一步很容易漏漏了之后整个查询逻辑都跑不通。5. 答辩演示与源码交付的几个实用技巧走到最后一步很多人卡在“功能都写了但演示时讲不清”。我的习惯是提前准备一条演示主线登录后台 → 新增民宿和房间 → 生成日历 → 前台查可售 → 下单 → 后台改房态 → 订单状态流转。这条线走通基本覆盖了所有核心表和外键关系老师一看就知道系统是活的。源码交付时README 里写清楚三件事JDK 和 MySQL 版本、建库脚本位置、启动命令。别写一大堆功能介绍评审的人只关心能不能跑起来。答辩 PPT 我一般控制在 12 页以内背景 1 页、技术选型 1 页、库表设计 2 页、核心流程 2 页、难点与解决 3 页、演示截图 2 页、展望 1 页。难点那几页就讲房态并发和事务边界这是最能体现你思考深度的地方。还有一个血泪经验演示前一定用干净环境跑一遍。我见过太多在自己电脑上好好的换到答辩教室因为 MySQL 没启动、端口被占、时区不对而当场翻车的。提前把application.yml里的数据库地址、账号密码改成通用配置准备一个docker-compose.yml一键起 MySQL能省掉很多后悔药。# docker-compose.yml 一键起数据库 version: 3 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root MYSQL_DATABASE: homestay TZ: Asia/Shanghai ports: - 3306:3306 command: --character-set-serverutf8mb4TZ设成上海时区避免日期差 8 小时。utf8mb4支持 emoji民宿名称里带表情符号也不会报错。这套配置在答辩现场用 U 盘拷过去docker compose up -d就能起库比现场装 MySQL 稳得多。这个方向值不值得做如果你是想练一套完整的增删改查加业务规则民宿平台比图书管理、商品管理更有嚼头因为房态和订单的耦合是真实存在的难点讲出来也有说服力。但别贪多把房态、订单、权限这三块做扎实比堆十个半成品模块强。希望帮到你。本文还有配套的精品资源点击获取 SpringBoot民宿管理平台实战：房态同步与订单并发控制
简介本资源为基于Spring Boot的民宿管理平台毕业设计全套资料面向计算机相关专业需要完成毕设的本科生尤其适合选择Java Web方向、希望快速搭建可运行系统的同学。包内包含完整论文、项目源码与PPT答辩材料覆盖绪论、关键技术、系统分析、系统设计、系统实现与系统测试等章节涉及Java、Eclipse、Tomcat、Spring Boot及MySQL数据库等知识点并给出管理员、商家用户、普通用户与前台首页四类功能模块的UML用例与流程分析。资源共841个文件以138个java源码、50个vue组件、48个html页面、44个css样式、153个js脚本及1个sql数据库脚本为主另含docx论文、ppt答辩稿与bat启动脚本压缩包约22.16MB目录结构清晰便于按模块查阅。已有57人学习下载可帮助读者获得完整赛题方案、可运行源码、数据库表设计与答辩演示思路适合作为毕设参考与二次开发基础。1. 民宿管理平台为什么总在“房态”这一步翻车做过民宿管理平台的人大多有个共同体会功能列表能写满两页纸真正上线后最先崩的往往是最不起眼的房态同步。房源、订单、入住人、保洁、渠道价这几张表一旦没设计好后面加一个“连住优惠”就能把整个订单模块推倒重来。这个标题讲的就是用 SpringBoot 搭一套能跑起来的民宿管理平台从库表设计到接口联调再到论文、源码、答辩 PPT 这条完整交付链路。它适合正在做课程设计、毕业设计或者想拿一个真实业务练手 SpringBoot 全栈的开发者。核心不是把功能堆多而是把房态、订单、权限这三条主线打通让系统能真正跑起来而不是只停留在演示截图。2. 民宿管理平台的领域建模与 SpringBoot 选型2.1 先想清楚业务边界再决定建几张表民宿和酒店最大的区别在于房源是非标准化的一套院子可能拆成三个独立房间也可能整租同一间房在不同渠道自营、OTA、线下价格不一样入住时间、退房时间、保洁间隔都带业务规则。如果一上来就照着酒店 PMS 抄表结构后面必然要改。我一般会把核心实体收敛到六张主表homestay民宿/房源、room_type房型、room具体房间、order订单、guest入住人、user后台账号。房态不单独建表而是用room上的状态字段加一张room_calendar日历表来记录每天的可售状态。这样查某天有没有房只需要按日期范围扫日历表比实时计算订单占用要快得多。-- 房态日历表一行代表某房间某一天的状态 CREATE TABLE room_calendar ( id BIGINT PRIMARY KEY AUTO_INCREMENT, room_id BIGINT NOT NULL COMMENT 房间ID, calendar_date DATE NOT NULL COMMENT 日期, status TINYINT NOT NULL DEFAULT 0 COMMENT 0可售 1已订 2锁定 3维修, price DECIMAL(10,2) NOT NULL COMMENT 当日价格, order_id BIGINT DEFAULT NULL COMMENT 关联订单, UNIQUE KEY uk_room_date (room_id, calendar_date) ) COMMENT 房态日历;这里的关键是uk_room_date唯一索引。下单时用INSERT ... ON DUPLICATE KEY UPDATE或者先查后改配合数据库唯一约束能挡住并发重复下单。status用整型而不是字符串是为了后续做状态机流转时判断更省事。price放在日历表而不是房型表是因为民宿周末和节假日价格浮动是常态按天存价格比按房型存更贴近真实业务。2.2 SpringBoot 版本和依赖怎么选才不给自己挖坑热搜里“springboot版本太高”是个高频抱怨。我的建议是如果这是毕设或课程项目不要追最新版。SpringBoot 3.x 要求 JDK 17很多学校的实验环境还停在 JDK 8一升级就报NoClassDefFoundError。稳妥组合是 SpringBoot 2.7.x JDK 8 或 11MyBatis-Plus 3.5.xMySQL 8.0。这套组合资料多、报错好搜、答辩时老师也认。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency /dependenciesspring-boot-starter-parent统一管理版本避免自己一个个填版本号填出冲突。MyBatis-Plus 比原生 MyBatis 省掉大量 XML做毕设这种 CRUD 密集的项目性价比很高。注意mysql-connector-java在 MySQL 8 下要配serverTimezoneAsia/Shanghai否则启动时报时区错误这是新手最常见的翻车点之一。2.3 项目结构按职责分层别全塞进 controller热搜里“springboot项目结构”被反复搜说明很多人卡在这一步。我一般用四层controller只做参数校验和返回封装service写业务逻辑mapper管数据库entity和dto分开。DTO 用于接收前端参数Entity 对应数据库表两者不要混用否则前端多传一个字段就可能被直接写进库。RestController RequestMapping(/api/room) public class RoomController { Resource private RoomService roomService; // 查询某日期范围内可售房间 GetMapping(/available) public ResultListRoomVO available(RequestParam String checkIn, RequestParam String checkOut) { return Result.ok(roomService.listAvailable(checkIn, checkOut)); } }RequestParam接收日期字符串在 service 层再转成LocalDate这样 controller 保持轻薄。Result是统一返回体包含 code、msg、data 三个字段前端处理起来一致。把日期解析放在 service 而不是 controller是为了将来换日期格式时只改一处。这套结构看起来朴素但答辩时老师问“你的业务逻辑写在哪”能直接指出来比全堆在 controller 里强得多。3. 从建库到接口联通的完整落地步骤3.1 数据库初始化与房态查询 SQL建库脚本建议单独放一个schema.sql方便换环境时一键重建。除了前面说的room_calendar订单表要留好状态字段和渠道字段。CREATE TABLE order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 订单号, room_id BIGINT NOT NULL, guest_name VARCHAR(50) NOT NULL, guest_phone VARCHAR(20) NOT NULL, check_in DATE NOT NULL, check_out DATE NOT NULL, total_amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已入住 3已完成 4已取消, channel VARCHAR(20) DEFAULT self COMMENT 渠道, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_order_no (order_no) ) COMMENT 订单表;order_no加唯一索引防止重复提交生成两笔订单。status用整型配合枚举类管理比直接存中文状态名更规范。channel字段是为将来接多渠道预留的现在不用但留着不亏。查可售房间的 SQL 是核心思路是先按日期范围查日历表里状态为可售的房间再排除已被订单占用的。SELECT r.id, r.room_no, rc.price FROM room r JOIN room_calendar rc ON rc.room_id r.id WHERE rc.calendar_date #{checkIn} AND rc.calendar_date #{checkOut} AND rc.status 0 GROUP BY r.id HAVING COUNT(rc.calendar_date) DATEDIFF(#{checkOut}, #{checkIn});HAVING COUNT(...) DATEDIFF(...)这句是精髓只有范围内每一天都可售的房间才会被选出来。如果某天被订走count 就会小于天数自动排除。这个写法比在 Java 里循环判断要快也更容易在答辩时讲清楚。3.2 下单接口的并发控制与事务边界下单是民宿平台最容易出问题的地方。两个人同时看中同一间房如果不在数据库层面加锁就会超卖。我一般用“日历表行锁 事务”来解决。Service public class OrderServiceImpl implements OrderService { Resource private RoomCalendarMapper calendarMapper; Resource private OrderMapper orderMapper; Override Transactional(rollbackFor Exception.class) public String createOrder(OrderCreateDTO dto) { // 1. 锁定日期范围内的日历行 ListRoomCalendar calendars calendarMapper .selectForUpdate(dto.getRoomId(), dto.getCheckIn(), dto.getCheckOut()); // 2. 校验是否全部可售 for (RoomCalendar c : calendars) { if (c.getStatus() ! 0) { throw new BizException(房态已被占用); } } // 3. 更新日历状态 calendarMapper.updateStatus(dto.getRoomId(), dto.getCheckIn(), dto.getCheckOut(), 1); // 4. 写入订单 Order order buildOrder(dto); orderMapper.insert(order); return order.getOrderNo(); } }selectForUpdate会对查询到的行加排他锁第二个请求进来时会阻塞等第一个事务提交后再执行此时状态已变成 1校验就会失败。Transactional的rollbackFor Exception.class保证任何异常都回滚避免出现日历改了但订单没写进去的脏数据。这里要注意锁的范围不能太大只锁目标房间和日期范围否则并发一高就全表排队。3.3 前后端联调与跨浏览器兼容处理热搜里“跨浏览器支持的设计与实现”和“vue打包放进springboot中”都指向同一个问题前端怎么和后端一起交付。我的做法是 Vue 打包后把dist目录丢进 SpringBoot 的resources/static后端加一个配置类处理前端路由。Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/**) .addResourceLocations(classpath:/static/); } Override public void addViewControllers(ViewControllerRegistry registry) { // 前端路由刷新不 404 registry.addViewController(/{path:[^\\.]*}) .setViewName(forward:/index.html); } }addResourceHandlers让静态资源能被访问addViewController把非文件路径的请求都转发到index.html解决 Vue history 模式刷新 404。跨浏览器方面主要是日期控件和 flex 布局在旧版浏览器上的差异建议用dayjs替代原生 Date 处理样式上避免用太新的 CSS 属性。联调时先用 Postman 把接口跑通再让前端接能省掉大量“到底是前端还是后端问题”的扯皮。4. 民宿平台开发中最容易踩的五个坑4.1 日期跨天导致房态算错现象用户订 1 月 1 日到 1 月 3 日系统只锁了 1 日和 2 日3 日还能被订。原因退房当天不应该算占用但查询时用了 checkOut。解决统一约定check_in date check_outSQL 里用而不是Java 里用LocalDate的isBefore判断。4.2 事务里调远程接口导致锁超时现象下单接口偶尔报Lock wait timeout exceeded。原因在Transactional方法里调了短信或支付接口事务迟迟不提交行锁一直不释放。解决把远程调用挪到事务提交之后用TransactionSynchronizationManager的afterCommit回调或者先落订单再异步发通知。4.3 SpringBoot 版本和 JDK 不匹配现象启动报Unsupported class file major version。原因SpringBoot 3.x 需要 JDK 17环境里是 JDK 8。解决要么降 SpringBoot 到 2.7.x要么升 JDK。毕设项目建议降版本改pom.xml里的 parent 版本即可别去折腾环境变量。4.4 前端打包后接口 404现象本地开发正常打包放进 SpringBoot 后接口全 404。原因前端 axios 的 baseURL 写的是localhost:8080打包后请求路径不对。解决baseURL 改成相对路径/api配合后端context-path统一前缀开发环境用代理转发。4.5 房态日历表数据没初始化现象查询可售房间永远返回空。原因新建房间后没有生成未来几个月的日历记录。解决在新增房间的 service 里批量插入未来 90 天的日历行状态默认 0价格取房型默认价。这一步很容易漏漏了之后整个查询逻辑都跑不通。5. 答辩演示与源码交付的几个实用技巧走到最后一步很多人卡在“功能都写了但演示时讲不清”。我的习惯是提前准备一条演示主线登录后台 → 新增民宿和房间 → 生成日历 → 前台查可售 → 下单 → 后台改房态 → 订单状态流转。这条线走通基本覆盖了所有核心表和外键关系老师一看就知道系统是活的。源码交付时README 里写清楚三件事JDK 和 MySQL 版本、建库脚本位置、启动命令。别写一大堆功能介绍评审的人只关心能不能跑起来。答辩 PPT 我一般控制在 12 页以内背景 1 页、技术选型 1 页、库表设计 2 页、核心流程 2 页、难点与解决 3 页、演示截图 2 页、展望 1 页。难点那几页就讲房态并发和事务边界这是最能体现你思考深度的地方。还有一个血泪经验演示前一定用干净环境跑一遍。我见过太多在自己电脑上好好的换到答辩教室因为 MySQL 没启动、端口被占、时区不对而当场翻车的。提前把application.yml里的数据库地址、账号密码改成通用配置准备一个docker-compose.yml一键起 MySQL能省掉很多后悔药。# docker-compose.yml 一键起数据库 version: 3 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root MYSQL_DATABASE: homestay TZ: Asia/Shanghai ports: - 3306:3306 command: --character-set-serverutf8mb4TZ设成上海时区避免日期差 8 小时。utf8mb4支持 emoji民宿名称里带表情符号也不会报错。这套配置在答辩现场用 U 盘拷过去docker compose up -d就能起库比现场装 MySQL 稳得多。这个方向值不值得做如果你是想练一套完整的增删改查加业务规则民宿平台比图书管理、商品管理更有嚼头因为房态和订单的耦合是真实存在的难点讲出来也有说服力。但别贪多把房态、订单、权限这三块做扎实比堆十个半成品模块强。希望帮到你。本文还有配套的精品资源点击获取