酒店管理系统课程设计：从数据库设计到订单状态机的完整避坑指南

简介面向软件工程课程设计的酒店管理系统项目完整源码与文档包适合高校学生、课程设计开发者以及需要快速搭建酒店业务管理系统的初学者。系统覆盖用户权限、客房标准、客房状态、预订结算等核心模块并配有需求分析、数据库设计等资料可帮助理解从需求分析到编码实现的完整流程。RAR压缩包共195个文件大小约17.85MB。其中以C源代码为主包括40个.h头文件与39个.cpp源文件另有Visual C工程文件dsp/dsw/sln、界面图标与背景图ico/bmp/jpg、数据库mdb文件以及课程设计报告doc/docx和答辩PPT类型覆盖编码、调试、文档与汇报各环节。目前已有1227人学习下载。资源附带可直接运行的exe程序与完整工程环境便于对照演示、二次开发或学习MFC界面与数据库操作适合作为课程设计参考、答辩素材或毕业设计扩展基础。1. 软件工程课程设计选酒店管理系统为什么这个题目年年有人做年年有新坑每年软件工程课程设计选题酒店管理系统都是出现频率最高的那一个。原因很直接它足够“像”一个真实业务系统——有房间资源、有客人、有订单、有入住退房、有财务统计能撑得起需求分析、概要设计、数据库设计、测试用例这些课程要求的全套文档同时它又足够小一个小组在一个学期内能用 Java、Python 或任意主流技术栈从零写出来。但正因为人人都做课程设计答辩现场翻车最多的也是它并发订房把库存扣成负数、日期跨天时订单状态算错、房间类型与价格改了之后历史订单对不上账。这些坑不是代码难写而是课程设计里最容易被忽略的几个环节在作怪——需求边界没划清、数据库约束没建对、状态机没设计。这篇笔记不打算给你一份“标准答案”式的完整代码而是把我自己带课程设计和做代码审查时反复强调的一条路径拆开怎么把需求文档变成数据模型怎么把业务流程变成代码怎么让演示时不会在答辩老师面前当场翻车。全程用一套常见的 Spring Boot MySQL 技术方案来讲因为这是目前多数本科课程设计里最稳的组合如果你用的是 Python Flask/Django 或是 C#思路完全一样只是框架语法不同。适合什么人看正在写软件工程课程设计文档但还没动手写代码的同学代码写了一半但发现订单和库存对不上账的同学以及带毕业设计的助教或指导者想找一套可复用的检查清单。下面直接从“课程设计最该写清楚的那张需求表”开始。2. 先画清楚边界酒店管理系统的需求拆分与角色权限2.1 从“酒店管理系统”到“能为答辩讲清楚的功能清单”很多小组拿到题目第一件事就是建工程、写登录注册然后做到一半发现功能太多收不住。酒店管理系统往大了说可以接 PMS、接门锁、接OTA平台、做会员营销但课程设计只需要覆盖一条主线顾客从预订到退房的完整生命周期外加管理员对房间、价格、订单的维护。我一般会让学生在需求分析阶段做一个“必须实现 / 可选实现 / 明确不做”的三列清单放进软件工程课程设计文档里的“项目范围”一节。必须实现的部分通常是这样前台/顾客端注册登录、浏览房间按类型、状态筛选、在线订房、取消订房、查看自己的订单。后台管理端房间类型与房间管理增删改查、设置价格、订单接单/拒单、入住登记、退房结算、查询所有订单。基础数据房间类型、房间、用户、订单四张核心表外加一份操作日志表用于记录关键动作。可选实现但容易加分也容易挖坑的部分会员等级与折扣、每日营收统计图表、房间图片上传。这些功能不是不能做而是要放在主流程跑通之后再做。明确不做的部分对接真实支付网关、对接短信验证、多酒店连锁管理、复杂的计费规则比如钟点房、凌晨特价。把这些写清楚课程设计文档会显得很专业而且能堵住答辩时“你为什么不支持在线支付”这类问题——你先回答“本项目定位是单体酒店内部管理支付属于外部接口集成不作为课程设计范围”。这不是推卸这是软件工程里最基本的范围管理。2.2 角色权限模型三种角色和一套最短权限矩阵权限设计不需要上 RBAC 框架但必须区分角色。我见过最直接的翻车现场是后台管理页面没有任何权限校验普通用户登录后手动输入/admin/orders就能看到所有订单。这个在答辩演示时如果被要求换普通账号试试基本当场扣分。最小可用权限矩阵如下功能点顾客前台操作员管理员注册/登录是是是浏览房间是是是在线预订/取消是是是订单接单/拒单否是是入住登记/退房结算否是是房间/房间类型管理否是可订为不可用是价格修改否否是营收统计/报表否是仅看是操作日志查看否否是实现上Spring Boot 里我用拦截器HandlerInterceptor按路径前缀校验角色。后端必须校验不能只靠前端隐藏按钮。前端根据角色动态渲染菜单只是体验问题后端接口权限是安全底线。2.3 需求文档落到用例图别画 20 个用例画 9 个就够课程设计文档要求用例图很多组画了二十几个看起来丰富但每个用例之间关系混乱。软件工程导论里的用例图本质是帮助分清参与者和目标不是越多越好。我建议画 9 个核心用例顾客注册、登录、浏览房间、预订房间、取消预订操作员处理预订、办理入住、办理退房管理员房间管理、查看经营报表每个用例写一个简短的用例描述包括前置条件、主流程、异常流程。比如“办理入住”的前置条件是订单状态为“已确认”主流程是核对身份证号录入、创建入住记录、将房间状态改为“占用”异常流程是订单不存在或已被取消。别小看这一段它直接决定你后面代码里的状态枚举和事务边界。3. 数据库设计是关键四张表还是六张表用 ER 图定下来3.1 最稳的六表结构以及为什么不用“订单内嵌房间类型”酒店管理系统课程设计的核心数据库表我推荐六张用户表、房间类型表、房间表、订单表、入住记录表、操作日志表。有的人会用一张订单表同时记录预订和入住退房省事但到了统计营收和核对历史时很容易混乱。先看建表语句。MySQL 8.0 环境字符集utf8mb4引擎InnoDB。下面是一份可复用的核心建表示例注释掉的地方是答辩时容易被追问的字段CREATE TABLE room_type ( id INT PRIMARY KEY AUTO_INCREMENT, type_name VARCHAR(50) NOT NULL UNIQUE COMMENT 如大床房、双床房、套房, base_price DECIMAL(10,2) NOT NULL COMMENT 基准价元/晚, bed_info VARCHAR(100) DEFAULT NULL COMMENT 床型说明仅展示用, area INT DEFAULT NULL COMMENT 面积平方米, status TINYINT NOT NULL DEFAULT 1 COMMENT 1启用0停用停用后不可订, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE room ( id INT PRIMARY KEY AUTO_INCREMENT, room_number VARCHAR(20) NOT NULL UNIQUE COMMENT 门牌号如 801, room_type_id INT NOT NULL COMMENT FK - room_type.id, floor INT DEFAULT NULL, room_status TINYINT NOT NULL DEFAULT 0 COMMENT 0空闲1占用2打扫中3维修中, remark VARCHAR(200) DEFAULT NULL, CONSTRAINT fk_room_type FOREIGN KEY (room_type_id) REFERENCES room_type(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password_hash VARCHAR(100) NOT NULL COMMENT 存bcrypt或sha256加盐别存明文, real_name VARCHAR(50) DEFAULT NULL, phone VARCHAR(20) DEFAULT NULL, id_card VARCHAR(20) DEFAULT NULL COMMENT 入住登记需要, role TINYINT NOT NULL DEFAULT 0 COMMENT 0顾客1操作员2管理员, member_level TINYINT DEFAULT 0 COMMENT 0普通1银卡2金卡可选功能 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE order ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(30) NOT NULL UNIQUE COMMENT 业务编号用于查看和统计, customer_id INT NOT NULL COMMENT FK - user.id, room_type_id INT NOT NULL COMMENT 预订的是房间类型而非具体房间, check_in_date DATE NOT NULL, check_out_date DATE NOT NULL, room_count INT NOT NULL DEFAULT 1 COMMENT 同一类型的房间数, order_status TINYINT NOT NULL DEFAULT 0 COMMENT 0待确认1已确认2已取消3已入住4已完成5已拒单, total_price DECIMAL(10,2) NOT NULL COMMENT 取消/拒单后冗余保留原价, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_order_customer FOREIGN KEY (customer_id) REFERENCES user(id), CONSTRAINT fk_order_room_type FOREIGN KEY (room_type_id) REFERENCES room_type(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE stay_record ( id INT PRIMARY KEY AUTO_INCREMENT, order_id INT NOT NULL COMMENT FK - order.id一个订单最多一条入住记录, room_id INT NOT NULL COMMENT FK - room.id实际分配的房间, actual_check_in_time DATETIME NOT NULL, actual_check_out_time DATETIME DEFAULT NULL, deposit DECIMAL(10,2) DEFAULT 0 COMMENT 押金, settle_price DECIMAL(10,2) DEFAULT NULL COMMENT 退房时实际结算金额, CONSTRAINT fk_stay_order FOREIGN KEY (order_id) REFERENCES order(id), CONSTRAINT fk_stay_room FOREIGN KEY (room_id) REFERENCES room(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE operation_log ( id INT PRIMARY KEY AUTO_INCREMENT, operator_id INT NOT NULL, action_type VARCHAR(30) NOT NULL COMMENT 如 CREATE_ORDER / CANCEL_ORDER / CHECK_IN / CHECK_OUT, target_order_id INT DEFAULT NULL, detail VARCHAR(500) DEFAULT NULL COMMENT 记录修改前后关键字段, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这套结构的关键决策有两处。第一订单表只关联room_type_id不关联具体的room_id。原因是顾客预订时可选的是“大床房”不是“801房间”具体分配房间的动作发生在入住登记时写入stay_record。这样设计让订单和房间解耦否则一旦调房订单里的room_id要跟着改还会导致历史统计失真。第二订单表加了order_status状态枚举并且把“已入住”和“已完成”分开。很多翻车案例会用“订单状态 已完成”来表示退房这会让入住期间的订单查询变得混乱。我的建议是预订、确认、入住、退房完成至少四个状态再加上取消和拒单两个旁路。3.2 金额与日期字段类型选错会让统计报表直接算错价格字段必须用DECIMAL(10,2)不要用FLOAT或DOUBLE。课程设计里可能显示不出来差异但业务上这是红线。日期方面入住退房用DATE保存当天不存DATETIME入住与退房发生时刻才用DATETIME记到stay_record。价格计算规则用“按间夜”算订单总价 晚数 × 房间数 × 每晚价格。晚数的计算是check_out_date - check_in_date注意 6 月 1 号入住 6 月 2 号退房是 1 晚不是 2 晚。这里顺便提一个课程设计里最常见的日期坑用DATEDIFF(check_out_date, check_in_date)时如果数据库里存的是DATETIME且退房时间是当天 00:00跨月计算会出偏差。所以我一直严格区分业务日期和时间戳日期比较只发生在订单表里时间戳记录只用于入住/退房动作。3.3 用 ER 图自检把关系画出来能发现 80% 的锤子活写完建表语句不代表数据库设计结束还需要画 ER 图放进课程设计文档。自检方法很土但有效把每张表和主外键关系画在纸上然后沿着“顾客 - 订单 - 订单包含房间类型 - 入住记录关联具体房间”这条线走一遍。如果发现“具体房间”从预订阶段就绑死就会看到一条不需要的外键链。这条链在课程设计答辩时被问到概率极高老师会问“如果用户下单时预订大床房到店时只剩另一间大床房订单怎么处理”你的表结构如果订单直接关联房间号就答不上来上面的拆解可以答“订单只锁定房型前台在入住时分配具体房间”。除了画线还要检查字段是否有可能为空的逻辑。order_status 3已入住时stay_record必须已有对应记录order_status 4已完成时stay_record.settle_price不能为空。这些约束在表创建语句里很难全部用外键表达但在业务代码里要写成服务层校验。这就是软件工程课程设计文档里所谓的“业务规则”落地的位置——它不是写在文档里给老师看的而是要转换成代码里的 if。4. 从需求到可运行代码Spring Boot 分层实现与订单状态机4.1 项目分层Controller、Service、Mapper 三层够用别为分层而分层酒店管理系统课程设计如果用 Spring Boot我建议按经典的 Controller-Service-Mapper 三层拆分再补一个config包放拦截器和全局异常处理。不要上 DDD 那套课程设计本来就是要让代码结构能对着软件工程文档讲清楚。一个典型的包结构如下com.example.hotel ├── controller // REST接口只做参数接收和结果包装 ├── service // 业务逻辑事务边界在这层 ├── mapper // MyBatis-Plus或MyBatis的DAO接口 ├── entity // 对应数据库表的实体类 ├── dto // 前端传参和返回参数的封装可选 ├── config // 拦截器、跨域配置 └── common // 统一返回结果、异常枚举我经常看到学生把业务逻辑写在 Controller 里Service 层空荡荡答辩时问“事务加在哪一层”答不上来。事务一定要加在 Service 层方法上比如“接单”这个方法内部可能要同时改订单状态、房间状态、写操作日志这三步要么都成功要么都失败所以Transactional必须放在 Service 层接单方法上。4.2 核心业务之一预订房间扣库存的 SQL 要写对预订房间是最能体现系统设计能力强弱的功能。常见做法是查一下该房型在目标日期段内剩余房间数如果够就创建订单。但这里有个并发问题两个人同时预订同一房型的最后一间都查到“剩余1间”然后都创建订单导致超卖。课程设计演示时不会真的有人并发下单但答辩老师可能问“如何处理并发”。解决思路是用数据库行锁或乐观锁。我的做法是加一张“房型每日库存”表或者在room_type表加一个total_rooms字段但更稳的是单独建一张room_type_inventory表记录日期和剩余间数预订时用带FOR UPDATE的 SQL 锁行SELECT id, available_count FROM room_type_inventory WHERE room_type_id #{roomTypeId} AND inventory_date BETWEEN #{startDate} AND #{endDate} AND available_count 0 ORDER BY inventory_date FOR UPDATE;在 Service 层加事务锁住这些日期行再逐行检查available_count - order_count是否小于 0小于 0 则抛异常回滚。不过对课程设计而言这个实现可能过了头。更常见的简化方案是不加锁只在 Service 层用一个synchronized块保证同一 JVM 内串行并给库存表加一个version字段做乐观锁。两种方案我在课程设计辅导中都给学生讲过最后多数选了乐观锁因为代码量少且能讲清楚。这里给一段乐观锁更新的核心 SQL也是我推荐在 Service 层里用的UPDATE room_type_inventory SET available_count available_count - #{count} WHERE room_type_id #{roomTypeId} AND inventory_date #{date} AND available_count #{count};MyBatis 的 update 方法返回值如果是 1表示当前行的可用间数没有被其他事务改成更小更新成功如果返回 0说明并发时库存不够或行已被改过此时抛异常订单回滚。我不建议在课程设计里把并发做得太复杂比如引入 Redis 分布式锁。课程设计的时间预算有限把状态机做好比引入一个根本没法演示分布式的“分布式锁”更实在。4.3 核心状态机订单状态流转必须是一张不许乱跳的图订单状态字段我习惯用整数枚举但在代码里一定要定义常量别直接写魔法数字。常量类示例public class OrderStatus { public static final int PENDING 0; // 待确认 public static final int CONFIRMED 1; // 已确认 public static final int CANCELLED 2; // 已取消 public static final int CHECKED_IN 3;// 已入住 public static final int COMPLETED 4; // 已完成 public static final int REJECTED 5; // 已拒单 }状态机允许的合法流转是待确认 - 已确认操作员接单待确认 - 已拒单操作员拒单待确认/已确认 - 已取消顾客取消或管理员取消已确认 - 已入住前台办理入住已入住 - 已完成退房结算除此之外的跳转都算非法。在代码里状态流转不能用“谁想改谁就 set 一下”而是要做成服务方法。比如退房时先检查当前状态是不是CHECKED_IN不是就直接抛业务异常。我写过最简版本如下Transactional public void checkOut(Long orderId, BigDecimal settlePrice) { Order order orderMapper.selectById(orderId); if (order null) { throw new BizException(订单不存在); } if (order.getOrderStatus() ! OrderStatus.CHECKED_IN) { throw new BizException(只有当订单已入住时才能退房当前状态 order.getOrderStatus()); } // 1. 更新订单状态 order.setOrderStatus(OrderStatus.COMPLETED); orderMapper.updateById(order); // 2. 更新入住记录的结算金额与退房时间 stayRecordMapper.settle(orderId, settlePrice, new Date()); // 3. 释放房间把订单关联的room_id状态改为空闲 roomMapper.releaseRoomByOrderId(orderId); // 4. 记日志 operationLogMapper.insert(...); }这段代码很短但每一行都对应状态机里的一个动作对应软件工程文档里“退房流程”的每一步。逻辑说明先查订单再校验状态再依次修改订单、入住记录、房间。注意顺序先更新订单状态再结算最后释放房间。顺序倒过来可能导致房间已释放但订单还没完成中途异常能让房间白白空着被其他窗口看到。4.4 权限拦截器三行配置拦住未登录和跨角色访问权限拦截用 Spring MVC 的HandlerInterceptor最简单的实现是放行登录接口和静态资源其他路径都要先检查 token课程设计可以用 Session再用一个RequireRole注解或者按 URL 前缀判断。我选按前缀判断简单直接。比如public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session request.getSession(); User user (User) session.getAttribute(user); if (user null) { response.setStatus(401); response.getWriter().write(请先登录); return false; } String uri request.getRequestURI(); if (uri.startsWith(/admin/) user.getRole() ! 2) { response.setStatus(403); response.getWriter().write(无权限); return false; } if (uri.startsWith(/operator/) user.getRole() ! 1 user.getRole() ! 2) { response.setStatus(403); response.getWriter().write(无权限); return false; } return true; } }在WebMvcConfigurer里注册这个拦截器并配置addPathPatterns(/**)、excludePathPatterns(/login, /register, /room/list, /static/**)。别忘了/room/list要放行不然游客没登录连房间都看不到。课程设计里做登录功能时最容易犯的错就是拦截器把所有接口都拦住导致前端页面加载不出来这属于自己能排查的初级问题。5. 必踩的五个坑从并发超卖到日期跨月一条条对应现场5.1 房间库存扣成负数原因与加锁解决现象演示时连续提交两个相同房型、相同日期的订单第二个订单居然也成功了数据库里available_count变成负数。原因Service 层先select查库存得到“有房”然后执行insert订单但中间没有任何机制防止另一个请求也查到同一份剩余库存。解决把扣库存 SQL 写成UPDATE room_type_inventory SET available_count available_count - #{count} WHERE room_type_id #{roomTypeId} AND inventory_date #{date} AND available_count #{count}利用数据库行锁保证原子更新。如果 update 影响行数为 0直接抛“该日期房间不足”。这是代码层面最容易修复但影响最大的问题。5.2 退房日期计算少一天所有订单价格贵了一晚现象顾客订 6 月 1 日入住、6 月 2 日退房系统算出 2 晚的价格。原因价格计算用了(check_out_date - check_in_date) / 86400000或者更简单的日历算法时把当天也算了一晚。解决把日期差值公式统一为check_out_date.getTime() - check_in_date.getTime()再除以一天的毫秒数并且要求数据库字段只存日期不存时间。如果前端是字符串传参务必LocalDate.parse然后再计算避免使用java.sql.Date的getTime()带来的时区偏移。这个坑在课程设计文档里要写清楚“间夜数 退房日期 - 入住日期”。5.3 取消订单后库存不恢复用户反复下单导致房间被幽灵占用现象顾客预订了两间大床房随后取消但库存表里的可用间数没加回。原因创建订单时改了库存但取消逻辑只改了order_status没有反向更新库存。解决把“创建订单扣库存”和“取消订单回补库存”放在同一个事务里。取消接口的 Service 方法写回补逻辑UPDATE room_type_inventory SET available_count available_count #{count} WHERE room_type_id #{roomTypeId} AND inventory_date #{date}。注意日期范围也要套回原本订单的check_in_date到check_out_date。我见过有同学只回补了第一天导致后半段库存还是空的。5.4 状态任意跳转用户手动修改订单状态地址现象演示时用户在自己的订单页通过修改请求参数或直接调用接口把待确认订单改成了已完成系统没有拦截。原因Controller 里提供了updateOrderStatus接口前端调用时直接把目标状态传进来Service 层没有任何校验。解决把状态更新收敛成acceptOrder、rejectOrder、cancelOrder、checkIn、checkOut方法内部各自校验当前状态。对外只暴露这些行为方法不暴露通用改状态接口。这是软件工程里封装思想的落地答辩时也能讲清楚。5.5 操作日志查不出责任人没有记录操作人现象管理员改了一个房间的价格事后查不到是谁改的。原因修改方法没有写日志。解决在管理员修改房间类型价格的地方插入一条operation_log记录operator_id、action_type为UPDATE_ROOM_TYPE_PRICE、以及修改前后的old_price和new_price。日志表可以简单但关键修改动作必须有记录。课程设计的重点在于“有日志”这个设计意识。上面五个坑是我在带课程设计代码审查时遇到最高频的问题前两个是逻辑错误后三个偏向设计缺失。你对照自己的代码查一遍基本能避免答辩翻车。6. 从可运行到能演示测试用例设计、验收清单与两个加分技巧6.1 给答辩老师看的测试用例别写“测试登录成功”这种废话软件工程课程设计文档要求测试部分很多学生写“登录测试输入正确用户名密码登录成功”。这不是测试用例这是描述。我建议用下面的格式写一段表格足够覆盖核心业务用例编号前置条件操作步骤期望结果TC-01无注册用户用户名重复提示“用户名已存在”不创建新用户TC-02已登录顾客预订大床房 2 间入住 6/1退房 6/3订单状态为待确认库存中该房型 6/1-6/2 的可用间数减 2TC-03订单状态为待确认顾客取消订单订单状态变为已取消库存回补TC-04订单状态为已确认前台办理入住选择房间 801订单状态变为已入住801 变为占用生成入住记录TC-05订单状态为已入住前台退房结算金额 800订单状态变为已完成801 变为空闲日志表新增退房记录TC-06无顾客访问/operator/orders返回 403 无权限每条用例要能对应到一个具体接口和一段完整业务流程。答辩老师喜欢问“你怎么验证流程是闭环的”你就拿 TC-02 和 TC-03 来说下单扣库存、取消回库存两个用例互为验证。6.2 演示前的三个准备种子数据、状态复原脚本、慢网速兜底第一次带课程设计答辩时我见过一个组演示中途订单表里全是测试垃圾数据房价被改得乱七八糟最后老师问“这个房间价格 199 是怎么来的”答不上来。所以演示前一定要准备种子数据和复位脚本。做法很简单写一份data.sql插入 3 个房型、每房型 5 间房、2 个测试用户、1 个操作员、1 个管理员。- 用户密码统一用固定的初始密码在文档里说明。订单数据不要预置太多现场演示从预订到退房一整条线更好。另外准备一个复位脚本reset.sql把所有业务表清空重插种子数据。一旦演示中途状态乱了直接执行脚本重启应用一秒钟回到初始状态。这是课程设计演示的后悔药。还要注意演示时的网络环境。如果你做的是前后端分离前端调后端接口时 CORS 或代理配置没搞好会导致“页面打开了但数据一直加载不出来”。演示前把前端打包后的静态文件放到 Spring Boot 的static目录下以单工程方式启动就不用担心本地起了两个端口导致跨域问题被现场放大。6.3 两个加分技巧报表用一条 SQL 出图权限用注解升级第一个技巧经营统计报表不用额外做图表库在管理端展示一个“最近 7 日每日营收”很好用。SQL 写法SELECT DATE(create_time) AS day, SUM(total_price) AS revenue FROM order WHERE order_status IN (3, 4) -- 已入住和已完成都算收入口径 AND create_time DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY DATE(create_time) ORDER BY day DESC;前端可以只用前端模板渲染成一个简单表格没必要用 ECharts但如果用 ECharts 画成柱状图答辩时观感会好很多。注意口径已确认但未入住的订单不能算收入因为顾客可能取消已取消的订单更不算。这个 SQL 背后就是业务口径答辩时主动讲出来能加分。第二个技巧权限拦截器升级成自定义注解。在方法上写RequireRole(2)通过 AOP 校验角色代码会更优雅。但课程设计时间有限如果前缀拦截器已经写好就不要为了优雅而重构。我更推荐把精力花在验证状态机上——用 JUnit 写一个简单的状态流转测试在答辩时展示“持久层状态异常会抛出业务异常”这比任何花哨框架都更能体现软件工程的严谨性。6.4 最后一个习惯把文档和代码一起提交课程设计交付通常要求软件工程文档、数据库设计文档、源码、测试报告。我有一次整理自己的旧项目时发现当初文档里写的“房间状态包含维修中”但在代码里根本没有实现维修状态流转这属于文档与代码不一致答辩时被发现会造成系统性不信任。所以我会在最后一天做一次“文档回读”把代码里每个 Service 方法名列出来和文档中的用例描述对照把数据库表字段列出来和 ER 图对照。不用改文档也不用来回重写只要保证文档里的核心逻辑状态枚举、权限矩阵、库存规则和代码一致即可。这件事花不了一个晚上但它是对“软件工程”这四个字最好的落笔。酒店管理系统这个课程设计题目天花板不高但全流程走完一遍等于把需求分析、设计、编码、测试、部署都过了一遍。我每年都会带学生从头到尾盯一遍最深刻的教训就是不要在前期文档上追求漂亮要把时间压在订单状态机、库存事务和权限拦截这三个点上。这三个点稳了系统骨架就稳了。希望这篇笔记里的表结构、状态枚举和那五个坑能让你少走几段弯路答辩时心里有底。本文还有配套的精品资源点击获取