每年到了毕业设计集中开题的时间后台咨询量最大的方向之一就是“基于Spring Boot Vue的酒店预订系统”。这个题目能见度这么高不是没有原因的技术栈主流、业务场景贴近生活、前后端分工清晰几乎是给计算机专业学生量身定做的全栈模板。但同样是这个题目有人能拿优秀有人差点没通过。差别不在框架熟不熟而在需求有没有想清楚、数据库有没有设计干净、核心业务逻辑有没有写严密。这篇分享主要写给两类人一类是准备拿这个题目做毕业设计的Java方向学生一类是想快速体验“Spring Boot Vue前后端分离开发”完整流程的入门开发者。我会把选题思路、表结构设计、后端接口、前端页面、文档整理到答辩准备整个链路过一遍顺便把我在指导和评审过程中比较常见的坑单拎出来讲。看完之后你不一定能马上写出惊艳的代码但至少可以照着这个思路完整复现一套可运行、可答辩、可交差的全栈系统。1. 这个毕设题目到底在考察什么1.1 选题价值与技术栈组合逻辑为什么很多老师默认这个题目“好做、不容易低分”因为它天然覆盖了答辩时评委最爱问的三个层次。第一业务层次。酒店预订系统涉及用户登录注册、酒店和房型检索、日期选择、订单生成、支付状态流转、订单管理、入住评论任何一条线都能展开讲十分钟。第二技术层次。Spring Boot把后端的基础设施封装得比较到位路由、事务、参数校验、异常处理都有成熟解法Vue负责前端交互和组件化开发前后端通过JSON接口通信这是当下Web开发最主流的分工方式。第三工程层次。一个完整的毕设不只是代码还包括数据库脚本、接口文档、测试用例、部署说明。这些这个题目都能覆盖到。还有一个容易被忽略的隐藏价值岗位认可度。招聘市场上Java后端要求熟悉Spring Boot几乎是标配前端要求熟悉Vue也是常态。一个毕设把两者都练过简历上写“独立完成基于Spring Boot Vue的酒店预订系统开发”说服力比堆课程设计项目高不少。选型细节也值得说清楚。后端Spring Boot版本我的习惯是默认2.7.x加JDK8因为网上资料最全几乎所有报错都能搜到现成答案如果你用JDK17及以上可以选3.x但要留意部分老教程里的依赖写法已经不兼容容易踩版本坑。前端Vue建议Vue2配Element UI或者Vue3配Element Plus新手不要混用否则组件文档和教程对不上调试起来极其痛苦。1.2 系统功能边界与用户角色设计动手写代码前先做一件事把功能画成一张“角色-功能”对照表。这张表决定了数据库要建哪些表、后端要写哪些接口、前端要做哪些页面。前台用户这边核心功能包括注册登录、浏览酒店列表、按城市或星级筛选、查看房型和价格、选择入住和离店日期、生成订单、模拟支付、查看我的订单、取消订单、入住后发表评价。后台管理员这边核心功能包括登录后台、酒店信息管理、房型与价格维护、订单审核与状态调整、用户管理、评论管理、以及基础的订单和营业额统计。这里有一个非常常见的误区不少同学一上来就想把权限设计成多对多角色表RBAC、菜单权限、按钮权限全套往上堆。我建议毕设阶段做到“用户角色分离”就够了。管理员和普通用户分表或者分字段标识后台接口统一做管理员校验把时间留给真正核心的预订流程而不是花在不加分也不容易讲好的权限模型上。提示功能边界宁小勿大。酒店预订系统的核心是“预订闭环”先把预订主流程做到无bug、逻辑自洽再考虑优惠券、会员等级、积分等扩展点。扩展功能可以作为论文里的“后期展望”写不必全部实现。2. 数据库设计与核心表关系2.1 表结构设计五张核心表就够了数据库是整个系统的地基。地基没打稳后面写接口、写页面都会反复返工。酒店预订系统最合理的做法是围绕五张核心表展开用户表、酒店表、房型表、订单表、评论表。我直接给一套可以跑通的MySQL建表结构字段命名尽量语义化方便映射到实体类。为了提高查询性能订单表里冗余了酒店名称和房型名称字段这是典型的“空间换时间”思路。-- 用户表 CREATE TABLE user ( id bigint(20) NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL COMMENT 登录名, password varchar(100) NOT NULL COMMENT BCrypt加密后的密码, nickname varchar(50) DEFAULT NULL COMMENT 昵称, phone varchar(20) DEFAULT NULL, email varchar(100) DEFAULT NULL, avatar varchar(255) DEFAULT NULL COMMENT 头像地址, role tinyint(1) NOT NULL DEFAULT 0 COMMENT 0普通用户 1管理员, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 酒店表 CREATE TABLE hotel ( id bigint(20) NOT NULL AUTO_INCREMENT, name varchar(100) NOT NULL, city varchar(50) NOT NULL COMMENT 所在城市, address varchar(255) DEFAULT NULL, star tinyint(1) DEFAULT NULL COMMENT 星级 3/4/5, description text, image varchar(255) DEFAULT NULL COMMENT 封面图, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 房型表 CREATE TABLE room_type ( id bigint(20) NOT NULL AUTO_INCREMENT, hotel_id bigint(20) NOT NULL COMMENT 所属酒店, name varchar(50) NOT NULL COMMENT 大床房/双床房/套房, price decimal(10,2) NOT NULL COMMENT 每晚价格, area int(11) DEFAULT NULL COMMENT 面积 平方米, bed_type varchar(20) DEFAULT NULL, max_people int(11) DEFAULT NULL, stock int(11) NOT NULL DEFAULT 5 COMMENT 该房型总间数, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_hotel (hotel_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 订单表 CREATE TABLE orders ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单编号, user_id bigint(20) NOT NULL, hotel_id bigint(20) NOT NULL, hotel_name varchar(100) DEFAULT NULL COMMENT 冗余字段, room_type_id bigint(20) NOT NULL, room_type_name varchar(50) DEFAULT NULL COMMENT 冗余字段, check_in_date date NOT NULL COMMENT 入住日期, check_out_date date NOT NULL COMMENT 离店日期, days int(11) NOT NULL COMMENT 入住晚数, total_price decimal(10,2) NOT NULL COMMENT 订单总价, status tinyint(1) NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已入住 3已退房 4已取消, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user (user_id), KEY idx_hotel (hotel_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 评论表 CREATE TABLE comment ( id bigint(20) NOT NULL AUTO_INCREMENT, order_id bigint(20) NOT NULL COMMENT 关联订单, user_id bigint(20) NOT NULL, content varchar(500) DEFAULT NULL, score tinyint(1) DEFAULT NULL COMMENT 1~5分, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这套结构里的外键关系很简单酒店一对多房型用户一对多订单订单一对一评论。实际开发中我不建议在数据库层强加外键约束逻辑外键就够用删除和更新更灵活也避免一些入门阶段容易踩的插入顺序问题。2.2 房间余量与订单状态的业务约定这里解释一个设计决策为什么不给每个独立房间建表而是用“房型加库存”的简化模型真实的酒店管理系统确实有房间表每个房间有房号、楼层、朝向但毕设阶段为了让复杂度可控用房型库存模型完全够用。room_type表中的stock字段代表该房型的总间数下单时判断“已占用数量小于stock”就可以生成订单。判断某段时间是否可订核心是日期重叠查询。新订单的入住日期早于已有订单的离店日期同时新订单的离店日期晚于已有订单的入住日期说明预订区间存在重叠不能接受该笔预订。对应SQL长这样SELECT COUNT(*) FROM orders WHERE room_type_id #{roomTypeId} AND status IN (0, 1, 2) AND check_in_date #{newCheckOut} AND check_out_date #{newCheckIn}状态用数字而不是字符串0待支付、1已支付、2已入住、3已退房、4已取消。用数字的好处是前端映射简单、后端判断可靠也方便以后接支付回调时做状态机流转。订单表里冗余hotel_name和room_type_name字段是为了订单列表展示时不需要回表查询两家表。days和total_price冗余存储同理报表统计直接取订单表就好。我见过不少学生在这个问题上纠结“违反第三范式怎么办”其实业务系统里适度冗余非常普遍答辩时能讲清楚取舍逻辑反而是加分项。注意金额字段一律用decimal(10,2)不要用float或double。浮点数在累加和比较时会有精度问题这在涉及钱的场景里是不可接受的。这是我从实际开发里带回来的教训。3. 后端Spring Boot骨架搭建与核心实现3.1 初始化工程与统一返回体、异常处理后端骨架我建议用Spring Initializr生成依赖选择Spring Web、Validation、MySQL Driver、Lombok然后手动加入MyBatis-Plus。MyBatis-Plus可以省掉大量单表CRUD代码内置分页插件非常适合毕设这种需要快速出活又要有规范性的项目。pom.xml里关键依赖如下dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-api/artifactId version0.11.5/version /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-impl/artifactId version0.11.5/version scoperuntime/scope /dependencyapplication.yml里的基础配置我习惯这样写server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/hotel_system?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: id-type: automap-underscore-to-camel-case这个配置建议打开它可以把数据库的check_in_date自动映射成Java实体里的checkInDate少写很多字段映射代码。所有接口统一返回同一个结构体这是前后端联调省心的重要前提。我定义了一个Result类包含code、message、data三个字段。成功时code为200业务失败时code为400或500前端只看code就能决定是否弹错误提示。配合全局异常处理用RestControllerAdvice捕获业务异常、参数校验异常和兜底异常接口里就不需要到处写try-catch。这是Spring Boot项目里很标准也很值得在答辩时讲一讲的实践。3.2 JWT登录鉴权与接口权限控制登录鉴权这块我建议直接使用JWT不要用Session。原因很简单前后端分离项目把前端部署在一个端口后端在另一个端口Session跨域处理很麻烦而JWT是无状态方案后端只需要在拦截器里校验签名不需要保存会话状态。登录流程走一遍用户提交用户名和密码后端查出用户后校验BCrypt密码是否正确正确则生成JWT返回前端前端拿到token存到localStorage后续请求在拦截器里放到Authorization头后端登录拦截器拦截所有需要登录的接口解析token成功后放行并把用户信息放到ThreadLocal或RequestAttribute里供业务代码使用。核心代码可以精简成这样Component public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (OPTIONS.equals(request.getMethod())) { return true; } String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { throw new BusinessException(401, 未登录或登录已过期); } Claims claims JwtUtil.parseToken(token.replace(Bearer , )); Long userId Long.valueOf(claims.get(userId).toString()); Integer role (Integer) claims.get(role); // 存入request后续Controller里直接取 request.setAttribute(userId, userId); request.setAttribute(role, role); return true; } }给后台管理员接口做单独校验时我会在接口方法上加一个自定义注解比如RequireRole(role 1)然后通过另一个拦截器或AOP判断角色。毕设阶段用这个方法就够了不用上Spring Security全家桶因为Security的过滤链和授权配置学习成本不低答辩时也不容易讲透。还有一个细节密码存储一定要用BCrypt加密不要用MD5。MD5是散列算法撞库风险高BCrypt自带盐值每次加密结果不同是目前行业内的主流选择。Spring Security的crypto包里有现成的BCryptPasswordEncoder单独引这个模块就行不需要引入整个Security。3.3 订单核心逻辑余量判断、价格计算与事务订单模块是整个系统的技术核心。我见过很多学生把下单逻辑写在Controller里一个方法几十行又是查库存又是算价格又是插入订单出了问题很难定位。正确做法是把下单流程放到Service层用事务包起来每一步都可能失败任何一个环节出问题都要整体回滚。订单Service的核心逻辑可以这样组织Transactional(rollbackFor Exception.class) public Long createOrder(OrderCreateDTO dto) { // 1. 校验房间类型是否存在 RoomType roomType roomTypeMapper.selectById(dto.getRoomTypeId()); if (roomType null) { throw new BusinessException(所选房型不存在); } // 2. 校验日期合法性 if (!dto.getCheckOutDate().isAfter(dto.getCheckInDate())) { throw new BusinessException(离店日期必须晚于入住日期); } // 3. 查询重叠订单数判断余量是否充足 long occupied orderMapper.countOverlapping( dto.getRoomTypeId(), dto.getCheckInDate(), dto.getCheckOutDate(), Arrays.asList(0, 1, 2) ); if (occupied roomType.getStock()) { throw new BusinessException(该时间段房间已满); } // 4. 计算晚数和总价 long days ChronoUnit.DAYS.between(dto.getCheckInDate(), dto.getCheckOutDate()); BigDecimal totalPrice roomType.getPrice().multiply(BigDecimal.valueOf(days)); // 5. 生成订单并插入 Order order new Order(); order.setOrderNo(generateOrderNo()); // ... 省略其他赋值 orderMapper.insert(order); return order.getId(); }generateOrderNo我习惯用“日期加随机数”的方式生成比如202506081530001234这样可读性好也方便在订单列表页展示。也可以用UUID但UUID太难看不够专业。价格计算要注意days的计算方式。入住当天算第一天离店当天不算比如6月1日入住、6月3日离店days就是2。使用ChronoUnit.DAYS.between可以精确得到这个值不需要自己写循环遍历日期。订单的取消逻辑也要用事务。已支付订单取消时直接更新订单状态为4即可不需要真的做支付退款毕设阶段在注释或文档里说明“生产环境需要对接支付网关退款的实现思路”就行。已入住或已退房状态的订单不能取消这种状态约束放在Service里判断不要指望前端按钮去控制。4. 前端Vue页面组织与前后端联调4.1 Vue项目初始化与axios封装前端我习惯用Vite初始化Vue3项目命令就一行npm create vuelatest。随后安装element-plus、axios、vue-router、dayjs这几个依赖。很多初学者在这里直接开始写页面结果写了几百行才发现请求要统一处理然后又回头补。正确做法是先封装axios再写业务页面。axios封装要做三件事设置baseURL、请求拦截器加token、响应拦截器统一处理code。封装好之后所有页面里的请求代码会非常干净。import axios from axios import { ElMessage } from element-plus import router from ../router const request axios.create({ baseURL: /api, timeout: 10000 }) request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer token } return config }) request.interceptors.response.use( response { const res response.data if (res.code ! 200) { ElMessage.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } return res.data }, error { if (error.response error.response.status 401) { localStorage.removeItem(token) router.push(/login) } ElMessage.error(error.message || 网络异常) return Promise.reject(error) } ) export default request请求封装好后调用一个“获取酒店列表”的接口就变成这样const list await request.get(/hotel/list, { params: { city, star } })注意封装里我用了baseURL为“/api”前端在开发环境需要把/api代理到后端的8080端口这个在4.3节细说。4.2 核心页面酒店列表、预订与订单前端页面我建议分成四块酒店列表页、酒店详情页、订单确认页、我的订单页。后台管理单独一组页面包括酒店管理、房型管理、订单管理。酒店列表页看起来简单实则有两个容易出问题的地方。一是筛选条件联动城市、星级、价格区间都要拼成查询参数传给后端这个用Element Plus的表单组件加一个“查询”按钮就能实现二是空数据处理后端返回空数组时页面不能白屏要展示“暂无可预订酒店”的提示信息。预订流程是重点。用户从房型列表点击“预订”后跳转到订单确认页页面需要选择入住日期和离店日期。这里我用el-date-picker的daterange类型同时设置disabledDate把今天之前的日期禁掉。离店日期自动强制要求晚于入住日期Element Plus的range组件已经内置了这个限制。日期选好之后前端要实时显示晚数和总价const days computed(() { if (!dateRange.value || dateRange.value.length ! 2) return 0 const start dayjs(dateRange.value[0]) const end dayjs(dateRange.value[1]) return end.diff(start, day) }) const totalPrice computed(() { return days.value * roomType.price })这个computed写法很直观用dayjs做日期差计算做完后展示在页面上用户确认无误点击提交。我的订单页面核心是“状态机驱动按钮显示”。订单状态是数字前端做成映射表0显示“去支付”、1显示“取消订单”、2显示“评价”、3和4只展示状态标签。按钮的显隐必须由状态计算出来不要写死。这个习惯在答辩时也能体现工程意识。4.3 联调中的跨域与接口约定前后端分离项目在联调阶段碰到的第一个问题基本就是跨域。开发环境我用Vite的代理解决在vite.config.js里加一个server.proxy配置export default defineConfig({ server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true, rewrite: path path.replace(/^\/api/, ) } } } })这样前端页面里请求“/api/hotel/list”Vite开发服务器会把请求转发到后端8080端口的“/hotel/list”浏览器层面不存在跨域问题因为请求是同源的。如果不用代理打开浏览器的控制台看到“Access-Control-Allow-Origin”相关的报错就是跨域没处理好。后端双保险可以加一个CORS配置类。两个方案选一个就能解决问题但我的经验是代理更适合开发因为后端代码不用依赖请求头Origin的处理逻辑。除了跨域联调阶段还要统一几个契约否则会出现“前端传了createTime后端返回createTime两边字段对不上”的尴尬日期格式统一为yyyy-MM-dd日期时间格式统一为yyyy-MM-dd HH:mm:ss金额统一用元前端展示不用额外换算分页统一用current和pageSize两个参数所有接口返回Result结构体前端只处理后端返回的data字段契约最好在前后端各写一份简短的接口文档哪怕是一个Markdown文件也能少走很多弯路。很多学生在联调阶段浪费大量时间问题不在编码能力而在接口字段没有提前对齐。5. 源码、数据库与文档怎么整理才加分5.1 源码结构与数据库脚本的交付规范标题里写了“源码数据库文档”说明这个题目本质上是交付三个东西。很多学生的源码写得不错但交付物一塌糊涂这里很吃亏。我建议交付目录这么组织hotel-reservation-system/ ├── backend/ # Spring Boot后端 │ ├── src/ │ └── pom.xml ├── frontend/ # Vue前端 │ ├── src/ │ └── package.json ├── sql/ │ └── hotel_system.sql # 完整建库建表脚本和初始数据 ├── docs/ │ ├── 需求分析.docx │ ├── 系统设计.docx │ └── 使用说明.docx ├── README.md └── 演示视频.mp4README一定要写清楚三件事运行环境要求、启动步骤、初始账号密码。评委拿到代码的第一件事就是看README能不能跑起来。如果你不写初始管理员账号评委可能连后台都进不去印象分直接打折扣。SQL脚本里要包含建库语句、建表语句和初始数据。初始数据建议放两个测试用户、三到五家酒店、每家对应的房型以及一条示例订单。演示的时候不愁没有数据可看。仓库里的target目录、node_modules目录一定要清掉提交前记得加.gitignore这是最基本的工程素养。5.2 设计文档与论文储备毕设文档一般包括开题报告、需求分析、系统设计、数据库设计、系统实现、系统测试这几个部分。酒店预订系统的论文框架可以这样对应需求分析章节直接引用角色-功能对照表把前台和后台的需求列成表格系统设计章节画总体架构图强调前后端分离的部署结构数据库设计章节放上面那五张表的建表SQL和ER图系统实现章节按模块写每个模块放一张页面截图加一段关键代码配三段文字描述。写论文时一个很常见的错误是把源码整段复制进去。不要这么干论文是给老师看的不是给编译器看的。每个模块挑出最核心的10到20行代码就够了比如订单事务方法、日期重叠查询SQL把配套的设计思路写清楚。评审老师想看的是你“有没有想清楚”不是你的代码能不能编译。测试部分不要只写“功能测试通过”这种空话。给出测试用例表格例如用例编号测试模块操作步骤预期结果实际结果TC001用户登录输入正确账号密码登录成功返回token与预期一致TC002用户登录输入错误密码提示账号或密码错误与预期一致TC003订单创建选择重叠日期提示该时间段房间已满与预期一致TC004取消订单对已入住订单取消提示当前状态不可取消与预期一致这样一份测试表既体现了你做了系统测试又给答辩准备提供了素材。5.3 编排演示与答辩自检演示环节很多学生是临时打开项目现场跑一旦数据库连接失败或者端口被占用整个人就慌了。我建议提前录制演示视频或者至少准备一条完整的演示动线反复走三遍。演示动线建议前台注册登录选城市搜索酒店浏览房型选择入住日期生成订单模拟支付查看我的订单取消待支付订单然后切换到管理员账号查看订单列表修改酒店信息。整个流程控制在三分钟内。答辩环节最常被问到的问题提前把答案组织好为什么用前后端分离而不是单体架构密码为什么不存明文订单并发操作怎么保证不超卖数据库为什么这么设计订单表为什么要冗余字段如果用户量大了系统怎么优化前三个问题在本文前面已经讲到了实现思路第四个和第五个可以从索引、Redis缓存、负载均衡等方向去答。不需要真的实现讲清楚思路就行。提示答辩不要背代码要讲思路。评委更关注你能不能把“为什么这么做”讲明白。6. 实操中遇到的坑与排查记录6.1 高频问题的排查速查表带项目过程中学生反馈最多的问题就那几个我把它们整理成一张速查表你遇到类似情况可以对照排查。现象可能原因处理思路前端请求返回401token过期或未携带检查axios拦截器是否带Authorization头前端请求返回403权限不足检查接口的角色校验是否匹配当前用户跨域报错未配置代理或CORS确认vite.config.js里proxy是否生效日期字段差8小时服务器时区不是北京时间检查连接串是否配置serverTimezoneAsia/Shanghai中文乱码数据库字符集不匹配建库时指定utf8mb4连接串加characterEncodingutf8MyBatis-Plus不生效依赖缺失或版本冲突确认starter版本与Spring Boot兼容npm安装报错依赖版本冲突删除node_modules和package-lock.json后重新install这里边时间差8小时是国人的老熟人了。MySQL连接串里如果不加serverTimezoneAsia/Shanghai默认用服务器的本地时区中文字符串和日期都会出问题。这个配置我一般在建项目的第一时间就写好避免后期排查。6.2 防并发超卖与数据一致性的处理酒店房间数量有限高并发下容易出现两个用户同时看到同一间房都可以预订、最后订单数超过库存的情况。这个问题在答辩时几乎是必问的所以提前把方案想清楚很重要。最直接的方案是悲观锁在查询重叠订单数量时使用SELECT ... FOR UPDATE把对应房型记录锁住事务提交或回滚后其他请求才能进入。这个方法实现简单缺点是并发性能一般。毕设阶段数据量小用悲观锁完全没问题。方案是乐观锁。给room_type表加一个version字段更新库存前先比较version如果版本号不匹配说明数据已经被其他事务修改更新失败重试。我更推荐毕设阶段把两种方案都了解一下实现上选悲观锁或者乐观锁都行因为答辩时你能讲清楚“为什么这么选”的取舍关系。比如你可以说酒店预订场景并发量不像秒杀那么极端悲观锁的锁冲突影响不明显而且实现直观适合当前规模。除了锁还要注意事务边界。把“查重叠订单数”“判断库存”“插入订单”这几步放进同一个事务方法里保证要么全部成功要么全部回滚。6.3 关于这个系统的最后分享我实际带项目时发现最终拉开差距的不是代码量而是闭环完整性。所谓闭环就是从用户打开页面到完成预订、到后台看到订单、再到数据落库的完整链路是否自洽。很多学生花了大量时间做炫酷的动效和花哨的图表结果订单状态流转里有Bug这才是真正的得不偿失。时间分配上我建议按这个节奏安排数据库设计一到两天后端接口三到四天前端页面三到四天联调和修Bug两天文档和论文四到五天答辩准备一天。整体周期两到三周完全可以搞定。最后分享一个我自己习惯的小技巧开发全程用Git管理代码每完成一个功能模块就提交一次commit信息写清楚是“feat: 完成用户登录接口”还是“fix: 修复日期重叠判断”。这个习惯短期内看不出优势但当你在某个版本里改坏了代码时git diff能帮你快速定位问题git log能让答辩时讲清楚开发过程这个小习惯能在关键时候救你一命。
