企业官网建设流程全解析

距离交毕设终稿还有不到一个月，室友的选题是民宿预定系统，天天在宿舍对着电脑挠头——不是功能写不出来，而是不知道从哪儿下手。订单表怎么设计？房间状态怎么同步？用户下单和房东接单的状态机怎么流转？这些问题如果不提前想清楚，等到写代码的时候就会变成一个无底洞。我当初做这个选题的时候也踩了不少坑，所以这次干脆把整个“基于SpringBoot的Web端民宿预定系统”从题目拆解、技术选型到核心模块实现、常见问题排雷，完整梳理一遍，给正准备做类似选题的同学一个可以直接上手的参考。

先把这个项目的核心内容说清楚：这是一个面向民宿场景的在线预订管理系统，围绕“游客找房—在线下单—房东确认—入住结算”这条完整业务链展开，包含用户端（微信扫码也好、网页访问也好）和管理端两大部分。前端用Web页面呈现，后端基于SpringBoot构建RESTful接口，数据库用MySQL存储业务数据，整体是一个标准的B/S架构项目。做这个选题收获最大的一点是：它几乎覆盖了Java后端开发最常考的高频知识点——SpringBoot自动装配、MyBatis持久层操作、MySQL表关系设计、Session或JWT登录态管理、还有订单并发处理这类稍进阶的场景。不管你是用来应付答辩，还是想借毕业设计把自己的后端基础打牢固，这个题目都很值得认真做一遍。

1. 项目整体设计与需求拆解

1.1 为什么选民宿预定系统当毕业设计

选毕业设计题目有个很现实的原则：难度要可控，但要能抻出技术含量。太简单的选题目（比如图书馆管理系统、学生信息管理系统）虽然能轻松完成，但是答辩时老师一问“你这系统解决了什么难点”，容易哑口无言；太偏算法的题目（比如推荐系统、图像识别）虽然听着高大上，但是基础不够的话容易把自己做成一个造轮子失败现场。

民宿预定系统正好卡在一个舒服的位置上。从业务上说，它足够日常，评委老师都能理解——游客要看房、下单、付款，房东要管理房源、处理订单，平台方要处理数据统计。从技术上说，它又不只是增删改查这么简单，里面藏着几个值得讲的点：民宿房源和房间的多级关系、日期区间的库存冲突判断、订单状态的状态机流转、多条件组合查询（区域、价格、评分、设施），这些模块写出来之后，答辩时可以讲的东西就很扎实了。

同时这个题目有天然的展示优势：民宿系统的页面往往比较出效果，图集轮播、地图定位、评价列表，视觉观感比普通的管理系统好看不少，做演示的时候很加分。

1.2 题目细读之后，核心模块应该怎么切

拿到“基于Web的民宿预定系统”这个题目，第一件事不是写代码，而是把业务角色和功能边界画清楚。民宿预定系统和酒店管理系统的最大区别在于：酒店系统的房源往往是标准化的（房间类型固定），而民宿系统通常房东和房源数量更多、房间信息更非标，所以会更强调“房东入驻”和“平台审核”的环节。

从最终实现的功能清单来看，大致可以拆成四个模块：

• 用户端（C端）：注册登录、民宿搜索、民宿详情（图集、设施、评价、地图位置）、下单预订、订单管理、个人中心。
• 房东端（B端）：房源管理（新增、上下架、编辑房型）、房价和库存设置、订单接单/拒绝/确认入住、营收统计。
• 管理后台（Admin端）：用户管理、民宿审核（上架/下架/封禁）、分类管理、区域管理、基础数据统计。
• 公共支撑模块：登录鉴权、文件上传（民宿图片）、数据校验、全局异常处理。

上面这个切分方式非常关键。很多同学做毕设，容易把前后台完全混在一起，用户能登录进去就直接改房源数据，权限没有边界，答辩时被问“你的系统怎么保证房东不能修改别人的房源”就会很被动。所以我一贯的建议是：哪怕前端页面简单一点，后台的接口权限和角色控制也一定要做清楚，这是给答辩老师看的系统设计功底。

1.3 项目的作用和适合人群

这套系统做出来后，能覆盖的实际场景比较明确：民宿经营者将房源信息发布到平台，游客通过Web端浏览和筛选房源，确认入住日期后生成订单，民宿主审核订单，最终在线下完成入住。整个过程用数据表和状态流转完整记录下来，既是一个可演示的项目，也是一个能跑通的业务闭环。

这个选题适合的人群很广：Java基础已经入门、但还不清楚一个完整Web项目怎么组织的在校生；想从单体管理型系统往业务型系统跨一步的同学；以及工作中想补一补SpringBoot全栈开发能力、拿一个完整案例练手的开发者。只要把下面这些模块吃透，你再回头看那些所谓的“xxx管理系统”选题，基本就是手到擒来。

2. 技术栈选型与项目架构设计

2.1 为什么是SpringBoot，不是SSH也不是SSM

说到Java后端，很多教材还在讲SSH（Struts2 + Spring + Hibernate）或者SSM（Spring + SpringMVC + MyBatis），但你现在去任何一家互联网公司看Java后端的新项目，大概率就是SpringBoot，甚至SpringCloud Alibaba那套微服务体系。毕业设计做SpringBoot，一是因为这套技术栈以后工作真的用得上，二是SpringBoot本身把SpringMVC、Jackson、Tomcat这些组件自动组装好了，省去大量繁琐的XML配置，适合在有限的时间内把精力放到业务实现上。

SpringBoot最核心的思想是“约定大于配置”。你只需要引入spring-boot-starter-web，一个@SpringBootApplication注解，内嵌的Tomcat就直接启动了。这意味着你不用再去折腾外部Tomcat的配置，不用写一堆web.xml和spring-mvc.xml，项目结构干净利落。对于答辩展示来说，项目结构清晰本身就是加分项。

如果说SpringMVC是“手动挡”，那SpringBoot就是“自动挡”，但底层还是同一台发动机。所以我的建议是：SpringBoot可以做，但Spring的核心概念（IOC、AOP、Bean生命周期）还是要认真看，因为面试官和答辩老师会很自然地追问“你了解自动配置原理吗”这类问题。

2.2 整体架构：前后端分离还是服务端渲染

这个选择题，直接影响你做项目的工时和难度。

第一种方案是前后端不完全分离，也就是后端用SpringBoot + Thymeleaf模板引擎，控制层返回页面视图，配合一些AJAX请求做局部数据更新。这种方案好处是项目结构简单，一个IDEA工程搞定所有事情，部署也方便，非常适合一个人短时间完成的毕设。缺点是页面和后端逻辑耦合度高，界面表现力一般。

第二种方案是前后端完全分离，后端SpringBoot提供JSON接口，前端用Vue（或React）独立开发，通过Axios调用后端API。这种方案更贴合企业真实开发流程，页面效果也能做得很好看。缺点是工程复杂度上升，你需要同时维护两个项目，还得考虑跨域问题，部署时要处理静态文件和服务接口的联调关系。

我做这个项目时采用的是前后端分离但前端不引入复杂脚手架的方案：后端是标准的SpringBoot工程，前端用Vue2 + Element UI（或原生HTML + Bootstrap 模板），构建后的静态文件直接放到SpringBoot的resources/static目录下，最终打包成一个jar包部署。这样既有前后端分离的开发体验，又避免了分布式部署的复杂度，属于一个很成熟的折中方案。

2.3 后端项目目录结构设计

一个好的项目结构，能让代码逻辑清楚、答辩讲解也有条理。我的推荐结构如下：

com.example.minsu ├── controller // 接口层，接收前端请求 │ ├── UserController.java │ ├── HouseController.java │ ├── OrderController.java │ └── AdminController.java ├── service // 业务逻辑层，核心业务处理 │ ├── UserService.java │ ├── HouseService.java │ ├── OrderService.java │ └── impl/ ├── mapper // MyBatis数据访问层 │ ├── UserMapper.java │ ├── HouseMapper.java │ └── OrderMapper.java ├── entity // 数据库实体类 ├── dto // 前端请求/响应参数对象 ├── vo // 视图对象，用于接口返回数据 ├── config // 配置类（拦截器、跨域配置等） ├── common // 通用工具类、统一返回结果、异常处理 └── MinsuApplication.java

这个分层结构的核心思想是单向依赖：Controller只调Service，Service只调Mapper，Entity作为数据载体贯穿各层。千万不要在Controller里写一大段SQL逻辑，也不要让Service层直接去操作HttpServletRequest，各层各司其职，后续出Bug的时候定位也快。

2.4 数据库设计：民宿系统的关系模型

数据库设计是毕设的重中之重。民宿预定系统的核心表，我整理成了这样一张清单：

有几个设计细节我想特别强调：

• 订单状态不能只存一个整数，建议用状态机 + 日志表的方式，把每次状态流转都记录下来。这样一旦出现纠纷，可以回溯到底是谁在什么时候改了状态。
• 民宿和房型是一对多关系，因为同一个房源可能有大床房、双床房、套房，价格和库存都不一致，订单要落在线下的房间级别。
• 订单号和订单主键分离，主键是自增ID用于内部关联，订单号用于展示给用户和生成支付流水，通常用时间戳加随机数生成。

2.5 核心表结构示例：订单表的DDL

订单表是整个系统的核心资产，我把它的核心DDL贴出来，你们建表的时候可以直接参考：

CREATE TABLE `orders` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '订单编号', `user_id` bigint(20) NOT NULL COMMENT '下单用户ID', `house_id` bigint(20) NOT NULL COMMENT '民宿ID', `room_id` bigint(20) NOT NULL COMMENT '房型ID', `check_in_date` date NOT NULL COMMENT '入住日期', `check_out_date` date NOT NULL COMMENT '离店日期', `nights` int(11) NOT NULL COMMENT '住宿晚数', `total_price` decimal(10,2) NOT NULL COMMENT '总价', `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0待确认 1已确认 2已入住 3已完成 4已取消 5已退款', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_user_id` (`user_id`), KEY `idx_house_id` (`house_id`), KEY `idx_room_id` (`room_id`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='订单表';

这里有几个很实际的选择：

• 订单号加了唯一索引，避免重复。
• check_in_date和check_out_date用的是date类型而不是datetime，因为民宿业务是按天计价的，不需要时分秒。
• total_price用decimal(10,2)而不是float，涉及金额的字段坚决不用浮点数，否则会出现0.1+0.2不等于0.3的尴尬问题。

3. 核心功能实现与重难点解析

3.1 用户注册登录：从Session到JWT

用户模块是入口，任何系统都绕不开。在民宿预定系统里，用户角色分三种：普通游客（可注册）、房东（可注册并发布房源）、管理员（后台内置账号）。注册登录的实现方式有两种主流的方案：

第一种是Session方案：用户登录成功后，后端把用户信息存到Session中，后续请求通过Cookie携带SessionID来识别用户。这个方案简单直观，适合单体项目，缺点是后端需要维护会话状态，前后端分离时还要处理Cookie跨域问题。

第二种是JWT方案：用户登录成功后，后端生成一个Token返回给前端，前端后续请求在Header中携带Token，后端通过解析Token来识别用户。优点是天然适合前后端分离和无状态服务，缺点是Token无法在服务端主动失效，处理用户封禁时要额外做黑名单控制。

在毕设阶段，我推荐直接用JWT方案，理由很现实：现在的公司项目尤其是微服务架构，已经很少用Session做登录态了，JWT几乎是面试必问，你写在简历上和答辩PPT里，都能体现出你接触过真实项目的技术选型风格。JWT的核心代码如下：

// 登录成功后生成Token String token = Jwts.builder() .setSubject(user.getUsername()) .claim("userId", user.getId()) .claim("role", user.getRole()) .setExpiration(new Date(System.currentTimeMillis() + 1000 * 60 * 60 * 24)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();

生成Token后，还需要写一个拦截器统一校验：拦截所有需要登录的接口，从请求头中取出Token解析用户信息，放到ThreadLocal中方便后续业务逻辑获取当前用户。

3.2 民宿搜索与筛选：SQL怎么写才不僵硬

民宿首页不能只是一个静态列表，得支持用户按关键词、城市/区域、入住日期、价格区间、设施要求做组合筛选。搜索功能最直白的实现方式是写一个动态SQL，用MyBatis的<if>标签判断条件是否存在，拼装查询语句。我在项目中实际使用的是MyBatis-Plus的LambdaQueryWrapper，代码比XML动态SQL更简洁：

LambdaQueryWrapper<House> wrapper = new LambdaQueryWrapper<>(); // 关键词模糊搜索 if (StringUtils.isNotBlank(keyword)) { wrapper.and(w -> w.like(House::getTitle, keyword).or().like(House::getAddress, keyword)); } // 城市筛选 if (StringUtils.isNotBlank(city)) { wrapper.eq(House::getCity, city); } // 价格区间 if (minPrice != null && maxPrice != null) { wrapper.between(House::getPrice, minPrice, maxPrice); } // 价格排序 wrapper.orderByAsc(House::getPrice);

这里最值得注意的细节是按入住日期筛选库存：用户选了“8月20日入住、8月22日离店”，系统应该只展示这个时间区间内有空房的民宿。这个需求不能只查民宿主表，得反查订单表——排除那些在指定日期区间内已经有重叠订单的房型。SQL大致可以写成：

SELECT h.* FROM house h WHERE h.status = 1 AND EXISTS ( SELECT 1 FROM room r WHERE r.house_id = h.id AND r.id NOT IN ( SELECT o.room_id FROM orders o WHERE o.status IN (1, 2) AND o.check_in_date < #{endDate} AND o.check_out_date > #{startDate} ) )

注意，这里判断订单冲突用的是区间交叉判定：新订单的入住时间小于已有订单的离店时间，且新订单的离店时间大于已有订单的入住时间，说明两个区间有重叠。这个逻辑虽然简单，但是非常容易写反，建议自己在纸上画几条时间线验证一下。

3.3 订单流程与状态机设计

民宿订单和电商订单最大的区别是：电商订单一般是付款后直接生效，民宿订单需要房东确认。整个订单的生命周期可以做这样的设计：

待确认（0） → 已确认（1） → 已入住（2） → 已完成（3） ↓ ↓ 待确认可取消（4） 已确认可取消（4）/ 退款（5）

具体流转规则是：

• 用户提交订单后，状态为“待确认”，此时用户可以取消，房东可以确认。
• 房东确认后状态为“已确认”，此时用户可以申请取消，房东也可以拒绝。
• 用户到店办理入住后（用户端点击“确认入住”或房东点击“办理入住”），状态变为“已入住”。
• 离店日期之后，系统自动或用户手动点击“完成订单”，状态变为“已完成”，此时用户可以发表评价。
• 订单取消后变成“已取消”，如果用户已经支付过费用，需要考虑退款状态“已退款”。

这个状态流转用一张订单状态日志表记录之后，整个订单模块的可解释性就会很强。在代码层面，我推荐用一个独立的OrderStatusHandler类来管理状态转换，而不是在Controller里到处写if (order.getStatus() == 1) { ... }。将状态流转规则收拢到一个类中，后续扩展状态时只需要改一个地方。

3.4 并发下单与库存超卖问题

如果民宿一共只有5间大床房，但同一时间有10个人同时下单，系统要保证不会超卖。这是并发编程在Web项目里的一个经典场景。最简单的防超卖方案是在数据库层面用条件更新控制：

UPDATE room SET stock = stock - 1 WHERE id = #{roomId} AND stock > 0

这一步操作是原子性的，InnoDB引擎会锁行。执行后判断影响行数：如果影响行数为1，说明扣减成功；如果为0，说明库存不足，直接返回“该房型已满房”。这个方案比先在Java层查库存再更新要安全得多——因为“先查后改”在并发情况下必然出现竞态条件。

当然，这个方案在单体应用里已经够用了。如果你想在项目里体现更高级的技术点，可以在订单模块引入Redis，把房型库存预加载到Redis中，用decr原子操作扣减库存。答辩时能讲清楚“为什么不用数据库锁，而用Redis+Lua脚本实现分布式锁”，会是一个不小的加分项。

3.5 管理后台的数据统计

管理后台除了常规的CRUD，最好还能有一些简单的数据可视化内容。民宿平台比较关心的指标有：每日订单量、销售额Top5民宿、各城市房源数量分布、各房型预订数量等。这些统计在MySQL里用GROUP BY加日期函数就能完成，比如：

SELECT DATE(create_time) AS day, COUNT(*) AS order_count, SUM(total_price) AS amount FROM orders WHERE create_time >= DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY DAY(create_time)

前端用ECharts渲染折线图或柱状图，展示效果比纯表格好很多。这块内容作为系统的“辅助亮点”存在，工作量不大，但对整体答辩评分帮助很明显。

4. 开发环境搭建与项目部署

4.1 本地开发环境准备

工欲善其事，必先利其器。开发民宿预定系统需要的基础环境如下：

JDK的安装和环境变量配置是很多新手第一个卡住的点。我的建议是：JDK8去Oracle官网下载，安装时记住安装路径；Windows下需要配置JAVA_HOME、PATH两个环境变量；配置完成后在命令行执行java -version验证。如果显示'java' 不是内部或外部命令，优先检查PATH里是否引用了%JAVA_HOME%\bin。

4.2 用Spring Initializr快速创建项目

创建SpringBoot项目不要手动导包，直接用IDEA内置的Spring Initializr，选好Maven、Java版本，然后添加Web、MyBatis、MySQL Driver、Lombok这几个依赖。我建议还加上Spring Boot DevTools，这样改了代码能自动重启，省去手动重启的时间。

关键的pom.xml依赖如下：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency>

注意，MyBatis-Plus不是Spring官方的东西，需要手动指定版本号。它的好处是提供了通用的BaseMapper，很多单表CRUD不需要写SQL，只写一个接口继承BaseMapper<T>就自动有了增删改查方法，能帮你省掉非常多的重复代码。

4.3 项目配置文件详解

创建好工程后，application.yml是核心配置文件，主要配置数据源和MyBatis相关参数：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/minsu?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 servlet: multipart: max-file-size: 10MB max-request-size: 50MB mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl map-underscore-to-camel-case: true global-config: db-config: id-type: auto

注意几个容易踩坑的地方：

• 数据库连接URL中的serverTimezone不能少，否则会报时区错误。
• characterEncoding=utf8一定要写在URL参数中，否则存储中文可能乱码。
• map-underscore-to-camel-case设置为true后，数据库字段的下划线命名会自动映射为Java属性的驼峰命名，比如create_time自动映射到createTime。
• MyBatis的StdOutImpl日志打印在开发阶段非常有用，可以直接看到每次执行的SQL语句。

4.4 前后端联调与跨域问题处理

如果采用前后端分离开发，前端代码运行在http://localhost:8081之类的端口，后端提供服务在http://localhost:8080，两者端口不一致必然触发跨域问题。解决方式是在后端写一个全局配置类处理CORS：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

这里有一个细节：allowCredentials(true)表示允许携带Cookie或Authorization请求头，但此时allowedOrigins不能直接配置为*，只能用allowedOriginPatterns("*")来实现所有来源放行。很多同学在这里踩坑，前端明明加了withCredentials还是报跨域，就是这两个配置不匹配导致的。

4.5 打包部署：从jar打包到云服务器

项目开发完成后，需要打包部署。在IDEA右侧Maven面板中执行package命令，就能在target目录下生成一个可执行的jar包。部署时用命令行启动：

java -jar minsu-0.0.1-SNAPSHOT.jar

如果服务器内存有限，可以限制JVM内存：

java -Xms256m -Xmx512m -jar minsu-0.0.1-SNAPSHOT.jar

推荐用nohup后台运行，避免关掉终端进程就结束：

nohup java -jar minsu-0.0.1-SNAPSHOT.jar > minsu.log 2>&1 &

部署时开发环境数据库密码和线上环境密码通常不一致，不要硬编码在代码里，可以使用启动参数动态覆盖：

java -jar minsu.jar --spring.datasource.password=yourProdPassword

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

5.1 数据库中文乱码问题

现象：前端提交的中文数据存入数据库后变成问号或者乱码。

排查路径：先看数据源URL是否带characterEncoding=utf8参数，再看MySQL表默认字符集是否为utf8mb4。我遇到过一个很隐蔽的情况：表和字段都是utf8mb4，但数据库连接池配置的URL漏了字符集参数，导致连接层发生编码转换问题。建议在建表时就显式指定引擎和字符集，而不要依赖数据库默认配置。

5.2 SpringBoot启动失败：端口被占用

现象：启动时报Port 8080 was already in use。

处理：开发环境大概率是后台进程没关干净。Windows下用netstat -ano | findstr 8080找到占用进程PID，然后用taskkill /F /PID 进程号强制杀掉。如果8080经常被莫名占用，也可以在application.yml里换一个端口，比如8081。

5.3 前后端联调时的400/415错误

现象：前端用Axios提交JSON数据，后端接口报HttpMessageNotReadableException或直接400。

原因：这是非常经典的提交数据格式不匹配问题。大多数情况是前端没有设置正确的Content-Type请求头，或者后端接收参数的注解用错了。推荐一个最简单的约定：前端统一使用axios.post(url, data)传对象，后端统一用@RequestBody接收JSON对象，两边字段名保持完全一致，能省掉大量联调时间。

5.4 数据库连接失败：Access denied for user

现象：启动项目时报Access denied for user 'root'@'localhost' (using password: YES)。

排查：先用Navicat等客户端工具确认能不能用账号密码连接成功。如果客户端能连上、项目连不上，检查application.yml中的url、username、password是否有空格或者特殊字符被转义的问题。另外MySQL8.0默认的密码加密方式为caching_sha2_password，部分旧版本驱动不兼容，需要替换连接驱动版本或者修改用户的加密规则。

5.5 订单时间判断的经典Bug：日期边界

这是我在开发中踩过一个非常典型的坑：用户在8月20日入住、8月22日离店，那么8月20日和8月21日两个晚上是需要住房的，8月22日中午退房。计算住宿晚数时，正确逻辑是离店日期 - 入住日期得到2晚；在判断库存冲突时，判定条件是check_in_date <= 该订单离店日期 且 check_out_date >= 该订单入住日期。如果小于等于号写成小于号，就会出现“8月20日入住的订单和8月20日离店的订单”互不冲突的错误。边界条件务必来回测试，建议写个单元测试覆盖日期重叠的所有情况。

5.6 文件上传大小限制

现象：上传民宿图片时后台报错，提示MaxUploadSizeExceededException。

原因：SpringBoot默认限制单文件大小为1MB，编辑民宿图片往往超过这个大小。处理方式是在配置文件中调大限制。同时前端multipart/form-data的传输大小也要同步调整。

6. 一点补充：关于答辩演示和后续扩展

到最后阶段了，你们的论文和系统基本完成，有精力的话可以给系统添加一两个差异化功能，让答辩更有亮点。我看过太多“标准版”的民宿系统，功能齐全但毫无记忆点。那些拿到高分的同学，往往只多做了一件事——在某个点上做得比其他人深，比如：

把民宿图片存到七牛云或阿里云OSS，而不是本地磁盘，答辩时可以讲“生产环境文件不能存本地，要做对象存储和CDN加速”。在订单支付环节挂一个模拟支付页面，完整跑一遍“下单—支付—确认—完成”链路，效果比只做“下单后状态直接变为已确认”好得多。用ECharts给房东端增加“近7日营收趋势图”和“房型入住率分布”，可视化数据在演示时天然有吸引力。

我在实际做这个选题的过程中最深的一点体会是：毕业设计比拼的不是谁用了更冷门的技术，而是谁能把一个常见的业务场景做得完整、严谨、能自圆其说。民宿预定系统这个题目之所以每年都有人选，就是因为它业务场景清晰、可扩展性强，既有技术深度可以挖掘，又有直观的展示效果。把上面这些内容吃透，你的民宿预定系统不只会是一个“能跑的毕设”，更会是一份拿得出手的作品。