SpringBoot民宿预订系统：从数据库设计到并发控制实战解析

做毕设选型的时候一眼看到“springboot民宿在线预订系统”这个题目很多同学脑子里蹦出来的第一个念头就是“又是一个增删改查”。说实话这个评价对一半但不全对。民宿预订系统如果只做到“房间列表提交订单”这种程度那确实只能算一个管理系统的换皮。但如果把预订流程里最核心的“房态控制”和“订单状态流转”想清楚再把并发场景下可能出现的超卖问题处理掉这个项目的含金量完全可以对标企业级的中台订单系统。我这次要分享的就是这套基于SpringBoot的民宿在线预订系统从技术选型、数据库设计到核心接口实现把整个项目的骨架逻辑和实操细节一次说透给正在做同类课题的同学一条可以直接落地的完整路径。这个系统能做什么一句话概括面向C端用户的民宿搜索、预订、支付模拟、订单管理以及面向B端运营者的房源管理、房态维护、订单处理和数据概览。适合计算机专业的毕业设计选题也适合想通过一个完整Web项目把SpringBoot、MyBatis-Plus、Vue、MySQL等串起来的初学者。我会按实际开发顺序拆解从设计思路讲到字段设计再讲接口实现和常见坑尽量把每一步背后的原因也说明白。1. 项目整体设计与思路拆解1.1 需求范围界定别把系统做成大杂烩拿到这种题目第一件事不是写代码而是界定范围。民宿预订系统看似简单但如果不控制边界很容易做成一个又大又空的项目。常见的失控表现是加了一堆“智能推荐”“社区论坛”“优惠券秒杀”的功能结果每个模块都只有半吊子答辩时一问细节就露馅。我的建议是严格锁定核心闭环用户从浏览房源开始到搜索筛选、查看详情、提交订单、模拟支付、管理订单最后到店入住确认和退房评价。后台侧则围绕“房源管理、房间管理、订单管理、轮播图配置、用户管理”五个基础模块展开。把这套闭环做扎实功能上已经不比市面上的中小型民宿SaaS差多少。至于“在线支付”考虑到毕设环境通常没有真实的商户资质我采用模拟支付的方式前端调起支付确认弹窗后后端直接把订单状态从“待支付”改为“已支付”并记录一个模拟交易流水号。这个方案既避开了第三方SDK接入的繁琐又能把订单状态机讲清楚答辩时可以顺带说明如果换成真实支付如何改造比硬接一个虚假的支付接口更让人信服。1.2 技术栈选型SpringBoot为核心的优势后端核心用SpringBoot 2.7.x理由不用多说生态成熟、自动配置减少大量样板代码、内置Tomcat开箱即用。持久层我配的是MyBatis-Plus 3.5.x用它来做单表CRUD非常高效少写大量XML分页插件直接搞定列表查询。但注意多表关联和复杂统计查询仍建议写原生SQL这样在答辩讲“SQL优化”时也更有话说。前端我用的是Vue 2 Element UI Axios。Vue 2虽然官方已不再维护但毕设环境里它依然是最稳妥的选择教程多、排查问题的资料多、Element UI组件成熟。如果你有余力换成Vue 3 Element Plus也完全没有问题只要接口约定不变前端切换成本很低。这里想强调一件事前后端分离是当前Web开发的主流模式毕设用前后端分离比传统的Thymeleaf模板方案更能体现你对现代工程化开发的理解。数据库我选MySQL 8.0版本选择上注意8.0的窗口函数和JSON能力比5.7强很多如果你要做一些统计报表窗口函数会非常方便。数据库连接池用Druid一来是它的监控页面很方便在答辩时展示SQL执行情况二来它内置了防SQL注入的Wall Filter。另外加上Redis用于存储验证码和短时高频数据比如房源浏览数这是加分点但Redis用法不要过度设计保持几个明确的场景就好。1.3 为什么用RESTful接口而不是RPC这个问题在答辩时被问到的概率很高。我的理解是民宿预订系统的调用方是浏览器端Vue应用天然适合走HTTP JSON的RESTful风格。RESTful的核心优势是资源语义清晰——把“房源”“订单”“用户”作为资源用GET/POST/PUT/DELETE表达动作对前端调用的理解成本极低。比如获取某个房源的详情就是GET /api/room/{id}创建订单就是POST /api/order。接口风格统一之后前后端联调变得非常顺畅。我在项目里要求所有接口返回统一的Result对象结构code、message、data。前端Axios拦截器统一处理code非200的情况比如登录失效时自动跳转登录页。这个设计在毕设中看起来不起眼但它是项目工程化的一个重要细节如果你的接口返回值东一个样西一个样后期调试会非常痛苦。2. 核心细节解析数据库设计与状态机建模2.1 数据表设计从业务名词到字段落地表结构是整个系统最核心的部分很多代码问题追根溯源都是表设计不合理导致的。我这套系统最终沉淀了8张核心表下面挑重点说。用户表user除了常规的自增id、用户名、密码之外我加了一个role字段区分C端用户和后台管理员用0和1表示。这样做避免单独建一张管理员表省事且合理。密码存储必须用BCrypt加密不要用MD5这一点几乎每个老师都会问。民宿表homestay存民宿基本信息包括名称、地址、所属城市、经度纬度、封面图、简介、设施标签、评分、状态上架/下架。这里有个设计细节民宿和房间是一对多关系一个民宿下有多个房间类型比如“大床房”“双床房”“复式loft”等。房间表room字段包括所属民宿id、房间名称、房间编号、面积、可住人数、床型、图片列表、房价每日价格、库存数量。注意这里的“库存数量”不是无限库存而是酒店民宿中“每日可用房间数”的概念。比如某民宿有3间“大床房”那么库存就是3同一个日期每个房间只能被一个订单占用。订单表order这是全局最核心的表。字段包括订单编号、下单用户id、民宿id、房间id、入住日期、退房日期、入住天数、每晚单价、总金额、支付状态、订单状态、下单时间、支付时间、入住人姓名、手机号、备注。订单编号我使用时间戳随机数的方案避免用自增id直接对外暴露订单量。此外还有订单-房间日期明细表order_room_date记录订单占用了哪些日期。这个表是处理“同一房间同一日期不能重复预订”的关键单独拿出来建表而不是用字符串存储日期列表是为了方便查询某个日期范围内的房态占用情况。点赞记录表、收藏记录表、轮播图表、评论表、浏览记录表这几张辅助表不展开说它们的逻辑都是标准的用户-内容关联表结构比较直观。2.2 订单状态机用状态字段管理整个生命周期订单状态字段我设计为status取值0待支付1已支付待入住2已入住3已退房4已取消5已退款。很多人做订单管理时只用一个状态字段但从不定义状态流转规则导致代码里到处写魔数判断逻辑混乱。我建议用状态机思维来约束订单变化待支付0可以取消到4可以支付到1。已支付1到入住时间后可以办理入住到2可以申请退款/取消到5。已入住2退房后变为已退房到3。已退房3可以发评论状态终态。已取消4终态。已退款5终态。代码层面我在OrderServiceImpl里写了一个私有方法checkOrderStatusTransition每次状态变更前先校验当前状态是否允许目标状态。比如不允许从“已退房”再次变为“已支付”这属于逻辑兜底。状态机的好处是代码逻辑清晰、答辩时有东西讲、也方便以后接真实支付回调时做幂等处理。2.3 日期可用性判断为什么不能只比较“入住-退房”民宿房间预订的时间冲突判断是面试官最爱追问的点。新手最常见的错误写法是只要新订单的入住日期晚于某条已存在订单的退房日期或者新订单的退房日期早于某条已存在订单的入住日期就认为不冲突。这个逻辑单独看没问题但很快你会发现一个漏洞如果房间A在“2025-06-01到2025-06-03”有一个订单此时新订单是“2025-06-01到2025-06-02”用上面那个条件判断会认为“新退房日期06-02 早于已有订单退房日期06-03”所以不冲突但事实上6月1日和6月2日已经被占用了。正确的冲突判断是新订单的入住日期小于已有订单的退房日期且新订单的退房日期大于已有订单的入住日期两者同时成立则冲突。翻译成SQL逻辑就是SELECT COUNT(*) FROM order_room_date WHERE room_id #{roomId} AND status IN (0, 1, 2) AND check_date #{checkIn} AND check_date #{checkOut}这条SQL的意思就是查这个房间在某些状态下有没有落在新订单入住日期区间内的日期记录。只要count大于0就说明该时间段内有被占用的日期不能接受下单。这里我特意用了和保持“入住当天可用、退房当天释放”的酒店行业惯例避免日期边界争议。3. 实操过程核心模块的实现与配置3.1 项目初始化别在环境配置上浪费时间创建一个SpringBoot项目时我建议直接使用阿里云的Initializr服务生成基础骨架这样依赖版本已经帮你对齐过尤其是SpringBoot和MyBatis-Plus的兼容性。记得勾选Web、MySQL Driver、Lombok。Lombok在写实体类时能减少大量getter/setter样板代码但注意一个点一个合格的毕设不能完全依赖Lombok实体类中的核心业务方法还是要手写不然答辩时老师让你说某个字段含义你脑子里只有注解没有业务概念。application.yml的配置有几个关键点数据库连接串必须加useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai否则中文乱码和MySQL驱动时区报错能折腾你半天。MyBatis-Plus的逻辑删除配置global-config.db-config.logic-delete-field: deleted。逻辑删除比物理删除更符合酒店订单场景因为我们需要保留历史订单数据做统计分析。Jackson序列化时区问题SpringBoot默认序列化LocalDateTime可能格式不对增加一个全局配置统一输出yyyy-MM-dd HH:mm:ss格式前端展示时少很多坑。Druid连接池初始化后打开Druid的Web监控页面路径是/druid/index.html。用这个页面可以在答辩时直观展示SQL执行次数和慢查询统计这比口头上说我做了SQL优化有说服力得多。3.2 登录鉴权JWT还是Session我推荐用JWT。思路是用户登录成功后后端生成一个包含userId、role的token返回给前端前端存到localStorage之后每次请求在Authorization头带上。后端用一个拦截器解析token把用户信息放入ThreadLocal方便在Service层获取当前登录用户。这里有一个实际踩过的坑如果直接使用JJWT库默认生成的token一旦服务端重启所有已登录用户都会失效。解决办法是给JWT设置一个合理的过期时间比如7天同时把密钥写在配置文件里不要硬编码在代码中。另外要注意token虽然能解决“登录态”问题但无法解决“用户被删除”的问题。所以在查询当前用户时要判断一下用户是否仍然有效。权限控制方面管理员接口上用HandlerInterceptor做角色判断。比如添加民宿、修改房间价格这类操作要求role1普通用户调用则返回403。用拦截器统一处理的好处是业务代码里不用每个Controller都去判断当前用户角色干净利落。3.3 发布房源与房间管理后台核心功能后台管理端做民宿和房间的CRUD这类功能本身没什么技术含量但有几个细节要注意。上传图片我采用本地磁盘存储图片路径存储在数据库前端通过一个映射路径直接访问。在WebMvcConfig中配置addResourceHandlers把本地目录映射到/upload/**访问路径。这个方案比存在数据库BLOB字段更合理也比接OSS少了很多麻烦。发布房间时要处理“房间图片”多图上传。Element UI的Upload组件可以用列表形式维护图片URL数组提交时用逗号拼接成一个字符串存到数据库。读取时再split成数组返回。这种简单粗暴的存储方式在数据量不大的场景下完全够用不需要专门建一张图片表。民宿地址的经纬度我推荐用高德地图的JavaScript API做地图选点取值后存经纬度字段。前端详情页用经纬度渲染地图标记这个功能视觉效果好且实现不复杂能显著提升系统在答辩现场的演示效果。3.4 用户端预订流程从筛选到下单的链路用户端浏览房源时我提供了一个综合搜索接口。支持按城市、入住日期、退房日期、可住人数、关键词、价格区间、评分排序等条件组合筛选查询用MyBatis-Plus的LambdaQueryWrapper动态拼接条件。注意一个细节当用户选择了入住和退房日期时需要先查出这两个日期之间所有可用房间id作为附加条件过滤。这里的实现可以复用之前的时间冲突查询逻辑把“所有被占用的房间id”查出来再用not in过滤。我实际实现是先创建一个临时查询查order_room_date表中在选定日期范围内所有已被占用的roomId列表。然后房源列表查询条件中加入if (!occupiedRoomIds.isEmpty()) { query.notIn(id, occupiedRoomIds); }。如果没有被占用的房间就不过滤。这样实现的性能在数据量小的时候没问题如果未来数据量大可以改成SQL子查询版本。提交订单是一个典型的事务操作。我在方法上加Transactional先后校验房间库存和日期冲突再生成订单主记录和订单日期明细记录。如果校验失败直接抛出业务异常由全局异常处理器捕获并返回友好提示。这里千万不要在事务方法里try-catch吞掉异常否则事务不会回滚这是很多同学容易犯的严重错误。库存扣减逻辑这么设计民宿房间的“库存”是一个静态约束更准确的表达是“同一日期同一房间不能重复售卖”。所以我并没有在room表设计库存增减字段而是完全依赖order_room_date的冲突检测。库存字段只用来描述“这个房型总共有几间”在下单校验时用“预占数量”辅助判断是否还有余量但真正拦路的是日期明细冲突表。有的同学会尝试用UPDATE ... SET stock stock - 1 WHERE stock 0的乐观锁写法但在一晚一间房的民宿业务里这个库存模型不适合容易造成“明明房间空闲却提示没有库存”的尴尬。3.5 订单超时未支付定时任务还是延迟消息订单创建后如果一直不支付占用的房态会一直锁住影响其他用户预订。这个问题每个做预订系统的同学都要考虑。最简单的方案是SpringBoot自带的Scheduled定时任务。我写了一个定时方法每30秒扫描一次订单表查到“创建时间超过15分钟且状态为待支付”的订单将其状态改为已取消并删除对应的订单日期明细记录。定时任务在单机环境下没有问题毕设答辩也够用但如果以后想让系统更健壮可以换成RabbitMQ延迟队列或者Redisson延迟队列。答辩时提到这一点老师会觉得你对生产级方案也有认知。还有一个坑定时任务运行时要加分布式锁的讨论。如果你只是单机部署不加锁没问题。但如果你为了演示在一台机器上同时跑了两个实例那么定时任务会重复执行。为了避免重复写订单明细或重复取消建议在订单取消的方法中再查一次当前订单状态只有status0的订单才执行取消逻辑这个二次校验是免费的幂等保护。3.6 支付回调模拟与订单状态更新模拟支付流程是前端点击“立即支付”弹出确认框用户点确认后向后端发起POST /api/order/pay参数是订单号。后端逻辑很简单校验订单属于当前用户、状态为待支付然后更新订单状态为已支付写入支付时间生成一条模拟支付流水流水号规则PAY 时间戳 4位随机数。这里我额外做了一件事在订单表上加了支付流水号和支付方式字段。这三个字段在答辩时能让你讲很多——讲真实业务中的支付对账、幂等性、回调通知等。而且如果后续要接微信支付只需要新增一个回调接口把“模拟支付”替换为“调用微信下单并等待回调”订单主流程不用改动。这个扩展点说出来整个系统架构的灵活性和前瞻性就体现出来了。3.7 评论与评分动态更新民宿评分用户完成入住状态变为已退房后可以对该民宿发表评论并评分1-5分。评论表记录的内容包括订单id、用户id、民宿id、评分、评论文本、图片、回复内容、评论时间。用户只能对“已退房”状态的订单发起评论且一个订单只能评论一次我在评论表给order_id加了唯一索引来硬性保证。这个细节体现的是数据库约束思维比在代码里各种if判断可靠。评论提交后我实时更新民宿表的评分字段查询该民宿所有评论的评分平均值更新到homestay.score字段。同时累计评论数量。民宿列表页的排序——按评分优先——就直接使用这个冗余字段。这种做法是典型的“读多写少”场景下的冗余设计牺牲一点写操作的代价换取读列表时的性能。在答辩时提到这个点能展示你对反范式设计的理解。4. 生产级细节并发控制与数据一致性4.1 高并发下如何防止超卖锁与事务的正确姿势民宿系统虽然并发量不高但这个知识点必须掌握。如果在答辩时被问到“同一房间同一时间被两个人同时下单怎么办”你不能只说“用synchronized锁”那是大忌——synchronized只在单机有效而且锁的范围要设计对。我最终实现的下单逻辑是在事务开启后先对room表中的对应房间行执行悲观锁查询SELECT ... FROM room WHERE id ? FOR UPDATE。这一步会把这一行锁住让同一个房间的下单请求串行化。然后继续执行后续日期冲突校验和订单创建事务提交后锁自动释放。这个方案在MySQL InnoDB下才能生效MyISAM不支持行锁。所以在建表时必须指定ENGINEInnoDB。另外FOR UPDATE必须放到事务中执行且查询条件必须是主键或索引否则锁的是全表性能直接崩。如果你的数据库表已经用了MyBatis-Plus的普通selectById那么调整方法是单独写一个mapper方法Select(SELECT * FROM room WHERE id #{id} FOR UPDATE) Room selectRoomForUpdate(Param(id) Long id);这样在事务内先调用这个方法锁行再走后续逻辑。我实测下来极端并发下这个方案能保证不会超卖而且实现简单。4.2 订单幂等接口防重与状态流转校验用户在前端可能因为网络慢双击提交按钮导致同一订单生成两条。我的处理方案是前端提交后立即禁用按钮这是第一层防护后端层面创建订单方法内增加一个幂等key机制即前端在打开下单页时向后端申请一个下单token提交订单时携带token后端用Redis的SETNX判断这个token是否已被使用未被使用则放行并写入token已被使用则直接返回“订单已提交请勿重复操作”。token每次下单页面刷新时重新申请有效期5分钟。这个方案虽然写起来多几十行代码但答辩时讲解“接口幂等性设计”非常有分量。另外订单状态流转时我强调过要使用状态机校验这也是幂等的一部分——当重复支付回调到达时如果订单状态不是待支付直接忽略保证不会重复修改订单状态。4.3 前端跨域与Axios封装前后端分离必然涉及跨域。我在后端配置了CorsFilter允许指定来源的跨域请求配置项包括允许的域名、请求头、请求方法。生产环境建议把allowCredentials设为true并限制Origin为具体的前端地址。如果答辩老师问CORS原理你就解释这是浏览器同源策略下的服务端授权机制浏览器先发OPTIONS预检请求服务端返回允许的跨域头之后才发起真实请求。Axios封装的核心在于统一处理错误码。我在响应拦截器里做三件事正常业务码返回datatoken过期码跳转登录页并清空本地缓存其他错误码用Element UI的Message显示后端返回的消息。这样一来Controller里只需要专注于返回业务数据不需要每个接口都写错误捕获逻辑。4.4 数据统计模块用SQL而不是代码计算后台首页搞了一个统计面板今日订单数、本月销售额、注册用户数、民宿总数、热门民宿TOP5、近7日订单趋势。这类统计功能我最反感在Java代码里循环查数据库再相加那样数据库查询次数会爆炸。正确的姿势是写聚合SQL。比如近7日订单趋势可以这样查SELECT DATE(create_time) AS day, COUNT(*) AS order_count, SUM(total_amount) AS amount FROM order WHERE create_time DATE_SUB(CURDATE(), INTERVAL 6 DAY) GROUP BY DATE(create_time)热门民宿排行用订单明细join得到每个民宿的订单数和销售额排序取前5。一个统计页面上总共5条SQL性能非常好。同时配合Druid的SQL监控可以清楚看到每条SQL的执行时间和行数这在答辩展示中是很加分的细节。5. 常见问题与排查技巧实录5.1 前端传时间字符串后端报错这个几乎每个人都遇到过。前端日期选择器默认传的是“2025-06-01T00:00:00.000Z”这种带T的ISO格式而后端用LocalDateTime接收时如果Jackson没配置JavaTimeModule会直接报错无法反序列化。解决方案是在启动类或者配置类里注册JavaTimeModule并设置日期格式Bean public Jackson2ObjectMapperBuilderCustomizer jsonCustomizer() { return builder - { builder.simpleDateFormat(yyyy-MM-dd HH:mm:ss); builder.serializers(new LocalDateTimeSerializer(DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss))); builder.deserializers(new LocalDateTimeDeserializer(DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss))); }; }同时前端在提交订单时先对入住和退房日期做格式转换统一转为“yyyy-MM-dd”再传给后端。这样前后格式完全一致能避免后期排查时间偏移。5.2 跨日订单导致房态计算错误一个订单如果从6月1日住到6月3日那么它占用的是6月1日、6月2日两晚3日中午退房。如果只存了入住和退房两个字段在查询6月3日当天是否有房时就容易误判。我通过order_room_date明细表在创建订单时用一个循环把入住日期到退房日期前一天的所有日期逐条插入这样查询房态时直接按日期匹配明细即可彻底绕开跨日歧义。生成日期明细的工具方法不复杂用一个while循环LocalDate start order.getCheckIn(); LocalDate end order.getCheckOut(); while (start.isBefore(end)) { // 插入一条明细 start start.plusDays(1); }这个逻辑虽然简单却将整个预订系统的房态判断统一了标准是项目中最值得写进博客的一个细节。5.3 懒加载导致JSON序列化失败用MyBatis-Plus的关联查询有时会在实体类中加关联对象比如订单中包含民宿信息。如果你在本地开启了懒加载而Jackson序列化时访问了未加载的关联属性轻则返回null重则抛出LazyInitializationException。我的做法是实体类不设复杂关联需要展示关联数据时在VO层拼装。即在Controller返回数据之前手动查询所需关联信息并封装为VO对象返回。这个设计虽然多写了一点代码但避免了懒加载坑也让实体类的职责更专注。答辩时讲一句“我把查询视图对象和数据库实体分开减少耦合”比讲一堆都听不懂的“懒加载策略”更有说服力。5.4 定时任务重复执行前面提到过单机部署没有大问题。但如果你为了图方便在同一个应用里既开了前台端口又开了后台管理端口两个端口共享同一个定时任务就会导致同一时间可能执行两次取消动作。我在取消逻辑中加了状态判断作为兜底即使重复执行第二次会发现订单状态不是待支付而直接返回。这个兜底逻辑是处理定时任务幂等性的通用方案。5.5 处理删除用户与历史订单的关联用户如果被管理员从后台删除历史订单怎么办如果你直接物理删除用户订单表中外键会失效而且统计报表也会缺数据。我的做法是设计一个deleted字段做逻辑删除并且在订单表不建物理外键只保存userId。查询订单时需要显示用户昵称的join用户表并把deleted0作为条件。这样历史用户被删除后订单记录仍然保留只是不再被统计为有效注册用户。这个取舍思路可以好好消化一下很多商业系统都是这样处理的。6. 部署上线与演示准备6.1 打包部署从IDE直接启动到服务器运行毕设系统建议部署到云服务器演示时直接访问公网地址效果远好于本地跑localhost。后端使用Maven的package命令打成jar包运行命令是nohup java -jar homestay.jar log.out 21 。注意打包前要把application.yml中的数据库地址和环境配置改为服务器的实际值同时注意资源文件里不要包含本地绝对路径。前端项目使用npm run build构建产物是dist目录。在服务器上安装Nginx把dist目录指向Nginx的root路径并将/api路径反向代理到后端服务。Nginx配置中有一个容易忽略的点代理时加proxy_set_header Host $host; 防止后端获取不到正确域名。跨域配置也可以在Nginx层解决而不必在后端开CORS。不过如果后端已经配置了CORS两者同时存在可能会重复携带跨域头要注意一致性。6.2 答辩演示路线先流程后亮点演示系统时我建议按照真实用户旅程走一遍从首页轮播图点进热门民宿搜索并筛选房源查看房间详情选日期提交订单模拟支付在“我的订单”中查看状态商家后台处理订单完成入住后用户评价。这条演示路径把系统所有核心功能串起来是最清晰的讲述方式。之后如果有时间再展示几个额外亮点Druid监控页面的慢SQL查询、定时任务日志中的订单自动取消记录、并发测试时用Postman模拟两个相同请求只有一个成功的截图。这些实打实的呈现比口头讲一百个“我用了Redis缓存”都更让人信服。6.3 扩展方向自己给自己加题如果能把这个系统融会贯通扩展方向其实非常多。比如接入真实第三方登录微信扫码把支付模块换成真实支付订单加入短信通知服务民宿端增加日历房态的可视化操作界面管理端增加按民宿维度统计的报表。每一个扩展方向都能在答辩时引导老师提问因为你的回答是基于已经跑通的代码而不是空谈概念。在毕设答辩现场这种“我做过”的自信才是最大的加分项。我个人在实际开发中最大的体会是毕设项目不一定要追求“酷炫新技术”把基础技术用得恰当、用得到位才是更重要的能力。SpringBoot Vue MySQL这套组合配合清晰的表设计和严谨的状态流转已经可以支撑一个逻辑完整的民宿预订系统。若能再融入一点并发控制、幂等处理的工程思维无论答辩还是后续面试这些技能都会成为你有说服力的谈资。把每一条关键SQL、每一个状态判断都吃透你会发现这个毕设不只是一个作业而是一座连接校园代码和企业工程思维的桥梁。