简介这是一套基于 JSP 与 Struts2 框架的酒店管理系统源码面向学习 Java Web、MVC 分层和数据库应用的初中级开发者可用于课程设计、毕业设计参考或框架入门练习。压缩包共 138 个文件约 2.94MB含 40 个 Java 源文件、42 个编译类、23 个 JSP 页面以及 XML 配置、JS/CSS、SQL 脚本等覆盖控制层、业务层、数据访问层与前端展示。已有 569 人学习作为小型实战案例具有参考价值。读者可了解请求分发、动作类与服务层、数据访问层的协作房间和订单模块的增删查改与分页处理以及 JSP 页面组织方式同时观察控制层向业务层、数据访问层的调用顺序理解数据库表结构、分页参数传递和页面跳转配置并留意常见安全处理与异常流程便于快速定位模块职责适合按模块阅读、对照调试和二次改造。1. 前台还在用 Excel 记房态这套 jsp 酒店管理系统就是来收这个摊子的很多中小酒店的前台值班表上房态是靠一支笔和一张打印的楼层图维护的203 今天退了、507 被电话预订到周五、押金收了多少记在另一个格子里。jsp酒店管理系统的定位就很清楚了——把这套手工动作固化成三样东西一张会变色的房态板、一条从预订到退房不发生跳变的订单状态链、一张能跟现金抽屉对得上的账单。它属于典型的 Java Web 教学级到中小型商用级项目JSP 负责页面渲染Servlet 扛请求分发JavaBean 走数据承载JDBC 直连 MySQL跑在 Tomcat 上不需要 Spring 全家桶。适合两类人要交课程设计又不想交一份假项目的学生以及接手了某酒店内部老系统、还得在上面加功能的开发者。下面按能跑、能改、能排错的顺序把它拆开。2. 技术栈与工程骨架一次房态查询在四层之间怎么流转2.1 为什么这套系统停在 JSP Servlet JDBC这类项目的技术选型不是随手定的而是被部署环境倒逼出来的。某酒店的机房可能就是一台装了 Tomcat 的 Windows 机器运维只会往 webapps 里丢 war 包装个 MySQL 已经是上限。在这个前提下JSP Servlet JavaBean 的组合反而是最稳的不引入额外容器依赖JDBC 直连数据库改一个字重新编译放进去就生效。具体分层上它沿用了经典的 MVC 变体JSP 是视图Servlet 当控制器JavaBean 和 DAO 组成模型层。浏览器的每个请求都走一条固定链路——请求进 Tomcat被 Filter 拦一道先统一编码再校验登录交给对应的 Servlet 解析参数Servlet 调 Service 或直接调 DAO 拿数据把结果塞进 request 或 session最后 forward 到/WEB-INF/jsp/下的页面完成渲染。值得说清楚的一点是页面位置。有经验的做法是把 JSP 全部放在WEB-INF下面浏览器直接敲/room/list.jsp是访问不到的只能由 Servlet 转发进去。这样做的好处是入口收敛权限判断只在 Servlet 层做一次就够不用在每个 JSP 顶部再抄一遍判断逻辑。玄学的地方在于很多人第一次改这类项目发现改了 JSP 页面没反应八成是改的那份在WEB-INF里但 Tomcat 跑的是另一份解压目录里的旧文件。数据承载上JavaBean 承担两件事一是跟表结构一一对应的实体类Room、Booking、Bill二是查询条件对象和分页对象RoomQuery、PageBean。实体类别做成贫血到只有一个 getter/setter 的壳把status从 int 映射成枚举、把checkInDate从字符串解析成LocalDate这类转换放在实体里后面写业务判断会省下大量 if。2.2 目录结构和分层职责工程按标准 Web 项目组织包名可以换但职责划分建议照这个来后面加功能不容易乱hotel-jsp/ ├── src/main/java/com/hotel/ │ ├── bean/ # 实体类 Room、Booking、Customer、Bill │ ├── dao/ # RoomDao、BookingDao、BillDao只写 SQL │ ├── service/ # BookingService、CheckoutService管事务 │ ├── servlet/ # RoomServlet、BookingServlet、CheckinServlet │ ├── filter/ # EncodingFilter、LoginFilter │ └── util/ # DBUtil、PageBean、DateUtil ├── src/main/resources/ │ └── db.properties # 数据库连接四要素 └── src/main/webapp/ ├── static/ # bootstrap、jquery、自定义 css ├── login.jsp └── WEB-INF/jsp/ ├── room/list.jsp # 房态板 ├── booking/create.jsp # 预订表单 └── checkout/detail.jsp# 结账页这套结构里DAO 只做一件事给定参数、返回对象绝不 commit、绝不吞异常。事务边界放在 Service因为一个「预订成功」的动作要同时改订单表和房间表跨了两张表就不再是单条 SQL 的事。Servlet 层的职责被压得很薄只做参数校验、调用 Service、选择转发或重定向这样同一段业务逻辑既可以被网页调用也能被后面加的接口复用。有两点容易被忽略。第一static目录放静态资源别混在WEB-INF里否则 CSS 加载不出来页面会全白排查半天以为是路径写错。第二db.properties放在 resources 下由类加载器读取不要硬编码在 Java 里因为测试环境和现场部署的数据库地址一定不一样写死一次就要改一次源码重新编译血泪经验。2.3 五张核心表撑起房态、订单和账单整个系统的数据模型可以压缩成五张表。房型定价格房间定物理位置和实时状态客户存档案订单存预订意向入住单和账单存已经发生的事实。分开存的原因是状态生命周期完全不同预订可能取消入住必然有退房账单一旦生成就不该被改。表名关键字段说明room_typeid, type_name, price, bed_count, area房型与挂牌价改价改这里roomid, room_no, type_id, floor, statusstatus 是房态核心0 空闲、1 已预订、2 已入住、3 维修、4 脏房customerid, name, id_card, phone, member_level证件号建议加唯一索引防止重复建档bookingid, order_no, customer_id, room_id, check_in_date, check_out_date, status, depositstatus0 待入住、1 已入住、2 已退房、3 已取消billid, booking_id, room_fee, other_fee, total_fee, pay_type, pay_time金额字段统一用 decimal(10,2)别用 floatroom.status和booking.status是两套状态必须成对推进。房间是资源订单是业务单据资源状态跟着单据走但两者的取值不是一一对应的房间的「脏房」在订单里找不到对应项订单的「已取消」也不等于房间回到空闲——保洁没打扫之前脏房不能被再次售卖。金额字段的类型是个高频翻车点。用 double 存房费退房结算时可能出现 233.29999999999998 这种数打印出来前台直接傻眼。统一改成decimal(10,2)Java 侧对应BigDecimal加减乘除走BigDecimal的方法别用。3. 环境搭建Tomcat MySQL 把登录页先跑出来3.1 环境版本与依赖清单这套项目对版本不算挑剔但组合要成对。JDK 8 搭配 Tomcat 8.5 或 9 是最省心的MySQL 用 5.7 或 8.0 都能跑驱动包跟着数据库版本换MySQL 8 用mysql-connector-java 8.x连接串里必须带时区和 SSL 参数。需要放进WEB-INF/lib的依赖一般是这几样mysql-connector-java-8.0.xx.jar # JDBC 驱动 javax.servlet-api-4.0.x.jar # 仅编译期需要Tomcat 自带实现 jstl-1.2.jar # 页面用 c:forEach 就必须有 standard-1.1.2.jar # JSTL 依赖的实现包JSTL 那两个包是新手最常见的 500 来源。页面里写了% taglib prefixc urihttp://java.sun.com/jsp/jstl/core %标签库 uri 能解析但运行到c:forEach就抛异常原因就是只放了 jstl 没放 standard或者把两个包塞进了 Tomcat 的 lib 而不是项目的WEB-INF/lib。数据库连接我一般先用DriverManager跑通链路确认业务逻辑没问题再换连接池。图省事的直接上原生连接但一定要在 DAO 的 finally 里关否则跑两天连接数就打满——这个话题后面单列一节讲。提示JDK 版本高于 Tomcat 支持的编译级别时启动日志里会出现 Unsupported major.minor version不要怀疑代码先对齐 JDK 和 Tomcat。3.2 建库建表和初始房态数据建库语句别只建表不建索引。房态板每次刷新都是按楼层和状态过滤room表上(floor, status)建一个联合索引几十间房看不出来房量上到几百就能感觉到差别。CREATE DATABASE hotel_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE hotel_db; CREATE TABLE room ( id INT PRIMARY KEY AUTO_INCREMENT, room_no VARCHAR(10) NOT NULL UNIQUE COMMENT 房间号如 203, type_id INT NOT NULL, floor INT NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0空闲 1已预订 2已入住 3维修 4脏房, remark VARCHAR(200), KEY idx_floor_status (floor, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; INSERT INTO room (room_no, type_id, floor, status) VALUES (201, 1, 2, 0), (202, 1, 2, 0), (203, 1, 2, 3), (301, 2, 3, 0), (302, 2, 3, 0);字符集统一用utf8mb4不要用utf8。前者支持完整的四字节字符客户姓名里带生僻字或者录入备注时用了个表情符号utf8直接报错或者存成问号而这个问题往往等到月底对账才发现。status用 TINYINT 而不是 VARCHAR 存「空闲/已入住」这类中文理由是代码里要做判断和统计。用中文存SQL 里就得写where status 已入住一旦有人录成「已 入住」中间多个空格数据就成了孤儿。用数字再在 Java 侧做一层枚举映射给前端展示。初始数据至少准备三种房型价格、若干房间、一个管理员账号。管理员密码别存明文用 MD5 加盐或者 BCrypt 都行课程项目里常见做法是 MD5虽然强度一般但比明文强至少不会出现拿到数据库就能登进系统的情况。3.3 部署到 Tomcat 并验证第一个请求把工程打成 war 丢进webapps或者直接在 IDE 里配 Tomcat 跑两条路都行。启动后先别急着点业务菜单按下面三步确认链路是通的能把问题范围缩小到某一层。第一步访问http://localhost:8080/hotel/login.jsp页面能出来说明静态资源和 JSP 编译没问题。出不来就看 Tomcat 日志里有没有 Jasper 编译异常。第二步随便输个错密码登录看返回的是提示还是 500。如果报ClassNotFoundException: com.mysql.cj.jdbc.Driver是驱动包没放对位置如果报Access denied for user是db.properties里的账号密码不对或者是 MySQL 8 的caching_sha2_password认证方式跟老驱动不兼容。第三步登录成功后观察房态板有没有数据。这一步能验证 Servlet 转发、DAO 查询、JSP 渲染三段是否都通。空数据和白屏是两回事空数据通常是 SQL 条件写错或者request.setAttribute的 key 和页面${pb.list}对不上白屏一般是 forward 路径写错或者页面抛了异常被吞掉。// EncodingFilter放在过滤器链最前面解决 POST 中文参数乱码 WebFilter(/*) public class EncodingFilter implements Filter { Override public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { req.setCharacterEncoding(UTF-8); // 只对 POST 请求体生效 resp.setCharacterEncoding(UTF-8); resp.setContentType(text/html;charsetUTF-8); chain.doFilter(req, resp); // 放行到下一个过滤器或 Servlet } }这个过滤器解决的是请求体和响应流的编码管不到 URL 上的 GET 参数——GET 参数的编码由 Tomcat 的server.xml里 Connector 的URIEncoding决定Tomcat 8 以后默认就是 UTF-8所以一般不用动。很多人遇到中文乱码就在页面顶部加pageEncoding加完发现还是乱就是因为只改了 JSP 源码的读取编码没改请求参数的解析编码两件事。4. 核心链路拆解从预订占房到退房结账的事务与状态机4.1 房态与订单状态怎么对应这套系统真正难的不是增删改查是状态推进的一致性。房间有五个状态订单有四个状态两者之间是一张映射表写代码前先把这张表画在纸上比写完之后到处打补丁强得多。业务动作订单状态变化房间状态变化约束条件创建预订无 → 待入住(0)空闲(0) → 已预订(1)房间当前必须为空闲取消预订待入住(0) → 已取消(3)已预订(1) → 空闲(0)未入住才能取消办理入住待入住(0) → 已入住(1)已预订(1) → 已入住(2)到店日期匹配办理退房已入住(1) → 已退房(2)已入住(2) → 脏房(4)账单必须已生成保洁完成不变脏房(4) → 空闲(0)仅内部操作这张表里最容易漏的是「取消预订后房间回到空闲」和「退房后房间进脏房而不是空闲」。前者漏了房间被永久占用房态板上那间房再也卖不出去后者漏了脏房被直接当空闲卖出去客人拎着行李进门看见上一任的毛巾投诉电话当天就到。实现上每个状态变更都写成带条件的 UPDATE而不是先查再改// RoomDao所有状态变更都带上前置状态返回影响行数 public int updateStatus(Connection conn, int roomId, int expectStatus, int targetStatus) throws SQLException { String sql UPDATE room SET status ? WHERE id ? AND status ?; try (PreparedStatement ps conn.prepareStatement(sql)) { ps.setInt(1, targetStatus); // 目标状态 ps.setInt(2, roomId); // 房间主键 ps.setInt(3, expectStatus); // 期望的当前状态不匹配则更新 0 行 return ps.executeUpdate(); } }这里把「期望状态」作为 WHERE 条件的一部分本质上是乐观锁。两个前台同时给同一间房下单只有一个能把status0改成1另一个影响行数为 0业务层拿到 0 就直接返回「房态已变化请刷新后重选」。如果写成先select status判断再update两个请求可能都读到 0然后都去改最后房间上挂着两张订单。这类问题在测试环境复现不了一上线就冒出来属于典型的并发踩坑。4.2 预订接口一个事务里改订单表和房间表预订动作要写两张表booking插一条新记录room改一次状态。这两步必须同时成功或同时失败所以事务边界要卡在 Service 层而且要用同一个 Connection。public class BookingService { private final RoomDao roomDao new RoomDao(); private final BookingDao bookingDao new BookingDao(); public String createBooking(BookingForm form) { Connection conn null; try { conn DBUtil.getConn(); conn.setAutoCommit(false); // 开启事务 // 1. 占房只有空闲房能被预订影响行数为 0 说明已被别人抢走 int locked roomDao.updateStatus(conn, form.getRoomId(), 0, 1); if (locked 0) { conn.rollback(); return 该房间已被预订或不可售请重新选择; } // 2. 写订单order_no 由日期 房间号 随机数拼成 String orderNo BK DateUtil.today() form.getRoomNo() (int) (Math.random() * 900 100); bookingDao.insert(conn, form, orderNo); conn.commit(); // 两步都成功才提交 return OK: orderNo; } catch (Exception e) { DBUtil.rollbackQuietly(conn); // 异常回滚别吞异常不记录 e.printStackTrace(); return 预订失败 e.getMessage(); } finally { DBUtil.close(conn); // 恢复自动提交并归还连接 } } }这段代码有三个参数值得单独说。form.getRoomId()是房间主键而不是房间号因为房间号可能被改比如装修后重编号主键不会。order_no拼接里带房间号和随机数是为了避免同一天同一间房多次预订导致单号重复——如果没有唯一索引兜底重复单号在结账时会关联到错误的账单。conn.rollback()放在 catch 里而不是 finally 里是因为正常提交后再回滚会抛异常。控制器那层要做参数校验不能把校验全推给数据库。到店日期必须早于离店日期日期不能早于今天roomId不能为空或者负数。这些校验如果只在前端 JS 做关掉 JS 或者用接口直接调就绕过去了脏数据会一直沉在库里。WebServlet(/booking/create) public class BookingCreateServlet extends HttpServlet { private final BookingService service new BookingService(); Override protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { BookingForm form new BookingForm(); form.setRoomId(Integer.parseInt(req.getParameter(roomId))); form.setRoomNo(req.getParameter(roomNo)); form.setCustomerName(req.getParameter(customerName)); form.setCheckInDate(req.getParameter(checkInDate)); form.setCheckOutDate(req.getParameter(checkOutDate)); if (!form.dateValid()) { // 日期合法性前置校验 req.setAttribute(msg, 入住日期必须早于离店日期); req.getRequestDispatcher(/WEB-INF/jsp/booking/create.jsp).forward(req, resp); return; } String result service.createBooking(form); if (result.startsWith(OK:)) { resp.sendRedirect(req.getContextPath() /room/list); // 成功后重定向防重复提交 } else { req.setAttribute(msg, result); req.getRequestDispatcher(/WEB-INF/jsp/booking/create.jsp).forward(req, resp); } } }成功后用sendRedirect而不是forward是为了避免用户按 F5 重复提交订单。这个细节很多人不当回事直到有客人真的刷新了三次页面系统里多出三张同房间的预订单前台只能挨个去取消。4.3 退房结算账单金额怎么算、状态怎么收口退房是整条链路上业务最重的一环要算钱、要写账单、要改订单、要改房态四件事。算法本身不复杂房费按实际入住天数乘房型单价加上消费项减去押金。public BigDecimal calcRoomFee(LocalDate in, LocalDate out, BigDecimal price) { long nights ChronoUnit.DAYS.between(in, out); // 按自然晚数算不是按小时 if (nights 0) nights 1; // 当天入当天退按一晚收 return price.multiply(BigDecimal.valueOf(nights)); }计费口径一定要跟前台口头习惯对齐。有的酒店超过中午 12 点退房加收半天有的按 24 小时滚动计费这些规则如果不在需求确认阶段定死写完之后改起来就是牵一发动全身。常见做法是把计费规则抽成一个独立方法参数里带上酒店配置的「退房时间」业务代码只管调规则怎么变都只改这一处。结算的 SQL 序列同样要包在事务里-- 1. 写账单 INSERT INTO bill (booking_id, room_fee, other_fee, total_fee, pay_type, pay_time) VALUES (?, ?, ?, ?, ?, NOW()); -- 2. 关订单只允许已入住的订单被关闭 UPDATE booking SET status 2 WHERE id ? AND status 1; -- 3. 房间转脏房等待保洁 UPDATE room SET status 4 WHERE id ? AND status 2;三条语句的影响行数都要检查。第二步返回 0 行说明这单已经被别人退过了或者根本没入住就点了退房这时候必须回滚否则账单已经插进去但订单还是「已入住」月底统计时这单会重复计入营收。5. 常见问题排查房态不同步、乱码和连接泄漏的踩坑记录5.1 房态和订单对不上现象房态板上某间房显示「空闲」但点进去预订时提示已被占用或者反过来房间显示「已预订」却找不到任何有效订单。原因九成是状态更新没进同一个事务。典型写法是 Servlet 里先调roomDao.updateStatus()再调bookingDao.insert()两次各自打开连接各自提交中间一旦抛异常比如订单号重复触发唯一索引房间状态改了但订单没写进去房态就悬在那了。还有一种情况是取消预订的代码只改了订单状态忘了把房间从 1 改回 0。解决所有跨表的状态变更统一收进 Service 层用同一个 Connection 开事务检查每一步的影响行数任何一步为 0 就整体回滚。上线前跑一遍对账 SQL把不一致的数据捞出来-- 找出状态矛盾和孤儿房态有已预订状态却没有对应待入住订单的房间 SELECT r.id, r.room_no, r.status FROM room r LEFT JOIN booking b ON b.room_id r.id AND b.status 0 WHERE r.status 1 AND b.id IS NULL;这条 SQL 建议做成一个后台小工具每天早上跑一次比等客人投诉再查日志高效得多。5.2 中文乱码与页面取值异常现象表单提交的客户姓名在列表页显示成????或者 EL 表达式${room.roomNo}在页面上原样输出没有被解析。原因乱码的根因是请求体按 ISO-8859-1 解码。JSP 顶部的pageEncoding只管源文件读取编码不管请求参数。EL 不解析通常是两个原因JSTL 的 jar 没放全或者 web.xml 的版本声明太低2.3 及以下默认关闭 EL 求值还有一种是把页面放在了WEB-INF外面但isELIgnored被设成了 true。解决乱码统一交给编码过滤器放在过滤器链的第一位且要在任何读取参数的代码之前执行。EL 问题先看 lib 目录里jstl和standard是不是都在再检查 web.xml 的web-app version3.1声明。如果只用了${}没用c:xxx标签其实不引 JSTL 也能解析但一旦混用就必须两个包都齐。提示数据库字符集、表字符集、连接串字符集、页面编码、过滤器编码这五处必须全部是 UTF-8有一处掉队就会在某个特定入口冒乱码其他入口正常。5.3 连接池耗尽、404 和部署类问题现象系统用着用着所有操作都卡住日志里出现Communications link failure或者Too many connections另一种是本地跑得好好的部署到现场服务器就 404。原因连接泄漏。DAO 里Connection、PreparedStatement、ResultSet只关了其中一两个异常路径下更是一个都不关。MySQL 的wait_timeout默认 8 小时连接被服务端断开后客户端还拿着失效连接用就会报通信失败。404 则多半是 war 包名和访问路径不一致或者 JSP 放在WEB-INF下却直接用浏览器地址访问。解决优先用 try-with-resources 管资源写起来比 finally 干净异常路径也不会漏public Room findById(int id) { String sql SELECT id, room_no, type_id, floor, status FROM room WHERE id ?; // try 括号里的资源会在代码块结束时自动 close包括抛异常的情况 try (Connection conn DBUtil.getConn(); PreparedStatement ps conn.prepareStatement(sql)) { ps.setInt(1, id); try (ResultSet rs ps.executeQuery()) { return rs.next() ? RoomMapper.map(rs) : null; } } catch (SQLException e) { throw new RuntimeException(查询房间失败, id id, e); // 带上参数便于定位 } }访问路径这块把 war 包名改成ROOT.war就能用根路径访问否则所有请求都要带项目名。改路径之后记得把代码里写死的redirect(/room/list)补上req.getContextPath()不然从根路径部署后全跳 404。5.4 日期与金额的类型陷阱现象预订日期存进库里少一天结账金额出现233.29999999999998打印小票上多出一串小数。原因日期用java.util.Date加SimpleDateFormat转换时时区差或者格式串写错MM和mm混用前者是月后者是分金额用double存二进制浮点本身无法精确表示小数。解决日期统一用LocalDateJDBC 8 驱动支持直接ps.setObject(index, localDate)取出来用rs.getObject(col, LocalDate.class)中间不经过字符串。金额全链路用BigDecimal数据库字段用decimal(10,2)展示时用setScale(2, RoundingMode.HALF_UP)统一保留两位。这两个类型问题看起来琐碎但属于改一次就再也不用管的类型早改早省心。6. 二次开发把整页刷新的房态板改成按楼层懒加载这套系统上线后最先撑不住的往往不是数据库是房态板。原始实现是每次刷新把全部房间一次性查出来渲染房量一百间以内还行三百间以上首屏就明显卡顿前台一边接客一边等页面转圈体验直接崩。我一般会从这一处开刀因为它同时练到了接口设计、前端交互和分页边界。改造思路是把「全量渲染」换成「按楼层按需拉取」。后端加一个返回 JSON 的接口复用已有的 RoomDao只是不再走 forward 而是直接写响应流WebServlet(/api/room/list) public class RoomApiServlet extends HttpServlet { private final RoomDao roomDao new RoomDao(); Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException { String floorParam req.getParameter(floor); // 楼层不传则查全部 Integer floor (floorParam null || floorParam.isEmpty()) ? null : Integer.valueOf(floorParam); ListRoom list roomDao.listByFloor(floor); // 复用已有 DAO 方法 resp.setContentType(application/json;charsetUTF-8); PrintWriter out resp.getWriter(); StringBuilder sb new StringBuilder([); for (int i 0; i list.size(); i) { Room r list.get(i); if (i 0) sb.append(,); // 只输出页面需要的字段别把整个实体序列化出去 sb.append(String.format({\id\:%d,\roomNo\:\%s\,\status\:%d}, r.getId(), r.getRoomNo(), r.getStatus())); } out.write(sb.append(]).toString()); } }前端在楼层切换时用fetch换数据房态卡片只重绘局部容器不再整页 reload。验证方法很直接改造前后各用浏览器开发者工具的网络面板对比一次请求的响应体大小和 DOM 重绘次数正常情况下响应体会从几百 KB 降到几 KB 量级。同时必须专门测一次边界——楼层下没有任何房间时接口返回空数组而不是 null前端拿到null去.forEach会直接白屏这个坑我在两个项目里都踩过。我自己后来养成一个习惯任何一次「查询改接口」的重构都先用旧实现跑一遍全量数据存成基线再用新接口跑同样条件做逐字段比对差异为零才允许合并。房态这种一秒都不能错的模块靠肉眼点几下页面是验不出来的。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/26 19:40:27 · 阅读 1.2k JSP酒店管理系统：房态、订单状态机与事务一致性实战
简介这是一套基于 JSP 与 Struts2 框架的酒店管理系统源码面向学习 Java Web、MVC 分层和数据库应用的初中级开发者可用于课程设计、毕业设计参考或框架入门练习。压缩包共 138 个文件约 2.94MB含 40 个 Java 源文件、42 个编译类、23 个 JSP 页面以及 XML 配置、JS/CSS、SQL 脚本等覆盖控制层、业务层、数据访问层与前端展示。已有 569 人学习作为小型实战案例具有参考价值。读者可了解请求分发、动作类与服务层、数据访问层的协作房间和订单模块的增删查改与分页处理以及 JSP 页面组织方式同时观察控制层向业务层、数据访问层的调用顺序理解数据库表结构、分页参数传递和页面跳转配置并留意常见安全处理与异常流程便于快速定位模块职责适合按模块阅读、对照调试和二次改造。1. 前台还在用 Excel 记房态这套 jsp 酒店管理系统就是来收这个摊子的很多中小酒店的前台值班表上房态是靠一支笔和一张打印的楼层图维护的203 今天退了、507 被电话预订到周五、押金收了多少记在另一个格子里。jsp酒店管理系统的定位就很清楚了——把这套手工动作固化成三样东西一张会变色的房态板、一条从预订到退房不发生跳变的订单状态链、一张能跟现金抽屉对得上的账单。它属于典型的 Java Web 教学级到中小型商用级项目JSP 负责页面渲染Servlet 扛请求分发JavaBean 走数据承载JDBC 直连 MySQL跑在 Tomcat 上不需要 Spring 全家桶。适合两类人要交课程设计又不想交一份假项目的学生以及接手了某酒店内部老系统、还得在上面加功能的开发者。下面按能跑、能改、能排错的顺序把它拆开。2. 技术栈与工程骨架一次房态查询在四层之间怎么流转2.1 为什么这套系统停在 JSP Servlet JDBC这类项目的技术选型不是随手定的而是被部署环境倒逼出来的。某酒店的机房可能就是一台装了 Tomcat 的 Windows 机器运维只会往 webapps 里丢 war 包装个 MySQL 已经是上限。在这个前提下JSP Servlet JavaBean 的组合反而是最稳的不引入额外容器依赖JDBC 直连数据库改一个字重新编译放进去就生效。具体分层上它沿用了经典的 MVC 变体JSP 是视图Servlet 当控制器JavaBean 和 DAO 组成模型层。浏览器的每个请求都走一条固定链路——请求进 Tomcat被 Filter 拦一道先统一编码再校验登录交给对应的 Servlet 解析参数Servlet 调 Service 或直接调 DAO 拿数据把结果塞进 request 或 session最后 forward 到/WEB-INF/jsp/下的页面完成渲染。值得说清楚的一点是页面位置。有经验的做法是把 JSP 全部放在WEB-INF下面浏览器直接敲/room/list.jsp是访问不到的只能由 Servlet 转发进去。这样做的好处是入口收敛权限判断只在 Servlet 层做一次就够不用在每个 JSP 顶部再抄一遍判断逻辑。玄学的地方在于很多人第一次改这类项目发现改了 JSP 页面没反应八成是改的那份在WEB-INF里但 Tomcat 跑的是另一份解压目录里的旧文件。数据承载上JavaBean 承担两件事一是跟表结构一一对应的实体类Room、Booking、Bill二是查询条件对象和分页对象RoomQuery、PageBean。实体类别做成贫血到只有一个 getter/setter 的壳把status从 int 映射成枚举、把checkInDate从字符串解析成LocalDate这类转换放在实体里后面写业务判断会省下大量 if。2.2 目录结构和分层职责工程按标准 Web 项目组织包名可以换但职责划分建议照这个来后面加功能不容易乱hotel-jsp/ ├── src/main/java/com/hotel/ │ ├── bean/ # 实体类 Room、Booking、Customer、Bill │ ├── dao/ # RoomDao、BookingDao、BillDao只写 SQL │ ├── service/ # BookingService、CheckoutService管事务 │ ├── servlet/ # RoomServlet、BookingServlet、CheckinServlet │ ├── filter/ # EncodingFilter、LoginFilter │ └── util/ # DBUtil、PageBean、DateUtil ├── src/main/resources/ │ └── db.properties # 数据库连接四要素 └── src/main/webapp/ ├── static/ # bootstrap、jquery、自定义 css ├── login.jsp └── WEB-INF/jsp/ ├── room/list.jsp # 房态板 ├── booking/create.jsp # 预订表单 └── checkout/detail.jsp# 结账页这套结构里DAO 只做一件事给定参数、返回对象绝不 commit、绝不吞异常。事务边界放在 Service因为一个「预订成功」的动作要同时改订单表和房间表跨了两张表就不再是单条 SQL 的事。Servlet 层的职责被压得很薄只做参数校验、调用 Service、选择转发或重定向这样同一段业务逻辑既可以被网页调用也能被后面加的接口复用。有两点容易被忽略。第一static目录放静态资源别混在WEB-INF里否则 CSS 加载不出来页面会全白排查半天以为是路径写错。第二db.properties放在 resources 下由类加载器读取不要硬编码在 Java 里因为测试环境和现场部署的数据库地址一定不一样写死一次就要改一次源码重新编译血泪经验。2.3 五张核心表撑起房态、订单和账单整个系统的数据模型可以压缩成五张表。房型定价格房间定物理位置和实时状态客户存档案订单存预订意向入住单和账单存已经发生的事实。分开存的原因是状态生命周期完全不同预订可能取消入住必然有退房账单一旦生成就不该被改。表名关键字段说明room_typeid, type_name, price, bed_count, area房型与挂牌价改价改这里roomid, room_no, type_id, floor, statusstatus 是房态核心0 空闲、1 已预订、2 已入住、3 维修、4 脏房customerid, name, id_card, phone, member_level证件号建议加唯一索引防止重复建档bookingid, order_no, customer_id, room_id, check_in_date, check_out_date, status, depositstatus0 待入住、1 已入住、2 已退房、3 已取消billid, booking_id, room_fee, other_fee, total_fee, pay_type, pay_time金额字段统一用 decimal(10,2)别用 floatroom.status和booking.status是两套状态必须成对推进。房间是资源订单是业务单据资源状态跟着单据走但两者的取值不是一一对应的房间的「脏房」在订单里找不到对应项订单的「已取消」也不等于房间回到空闲——保洁没打扫之前脏房不能被再次售卖。金额字段的类型是个高频翻车点。用 double 存房费退房结算时可能出现 233.29999999999998 这种数打印出来前台直接傻眼。统一改成decimal(10,2)Java 侧对应BigDecimal加减乘除走BigDecimal的方法别用。3. 环境搭建Tomcat MySQL 把登录页先跑出来3.1 环境版本与依赖清单这套项目对版本不算挑剔但组合要成对。JDK 8 搭配 Tomcat 8.5 或 9 是最省心的MySQL 用 5.7 或 8.0 都能跑驱动包跟着数据库版本换MySQL 8 用mysql-connector-java 8.x连接串里必须带时区和 SSL 参数。需要放进WEB-INF/lib的依赖一般是这几样mysql-connector-java-8.0.xx.jar # JDBC 驱动 javax.servlet-api-4.0.x.jar # 仅编译期需要Tomcat 自带实现 jstl-1.2.jar # 页面用 c:forEach 就必须有 standard-1.1.2.jar # JSTL 依赖的实现包JSTL 那两个包是新手最常见的 500 来源。页面里写了% taglib prefixc urihttp://java.sun.com/jsp/jstl/core %标签库 uri 能解析但运行到c:forEach就抛异常原因就是只放了 jstl 没放 standard或者把两个包塞进了 Tomcat 的 lib 而不是项目的WEB-INF/lib。数据库连接我一般先用DriverManager跑通链路确认业务逻辑没问题再换连接池。图省事的直接上原生连接但一定要在 DAO 的 finally 里关否则跑两天连接数就打满——这个话题后面单列一节讲。提示JDK 版本高于 Tomcat 支持的编译级别时启动日志里会出现 Unsupported major.minor version不要怀疑代码先对齐 JDK 和 Tomcat。3.2 建库建表和初始房态数据建库语句别只建表不建索引。房态板每次刷新都是按楼层和状态过滤room表上(floor, status)建一个联合索引几十间房看不出来房量上到几百就能感觉到差别。CREATE DATABASE hotel_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE hotel_db; CREATE TABLE room ( id INT PRIMARY KEY AUTO_INCREMENT, room_no VARCHAR(10) NOT NULL UNIQUE COMMENT 房间号如 203, type_id INT NOT NULL, floor INT NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0空闲 1已预订 2已入住 3维修 4脏房, remark VARCHAR(200), KEY idx_floor_status (floor, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; INSERT INTO room (room_no, type_id, floor, status) VALUES (201, 1, 2, 0), (202, 1, 2, 0), (203, 1, 2, 3), (301, 2, 3, 0), (302, 2, 3, 0);字符集统一用utf8mb4不要用utf8。前者支持完整的四字节字符客户姓名里带生僻字或者录入备注时用了个表情符号utf8直接报错或者存成问号而这个问题往往等到月底对账才发现。status用 TINYINT 而不是 VARCHAR 存「空闲/已入住」这类中文理由是代码里要做判断和统计。用中文存SQL 里就得写where status 已入住一旦有人录成「已 入住」中间多个空格数据就成了孤儿。用数字再在 Java 侧做一层枚举映射给前端展示。初始数据至少准备三种房型价格、若干房间、一个管理员账号。管理员密码别存明文用 MD5 加盐或者 BCrypt 都行课程项目里常见做法是 MD5虽然强度一般但比明文强至少不会出现拿到数据库就能登进系统的情况。3.3 部署到 Tomcat 并验证第一个请求把工程打成 war 丢进webapps或者直接在 IDE 里配 Tomcat 跑两条路都行。启动后先别急着点业务菜单按下面三步确认链路是通的能把问题范围缩小到某一层。第一步访问http://localhost:8080/hotel/login.jsp页面能出来说明静态资源和 JSP 编译没问题。出不来就看 Tomcat 日志里有没有 Jasper 编译异常。第二步随便输个错密码登录看返回的是提示还是 500。如果报ClassNotFoundException: com.mysql.cj.jdbc.Driver是驱动包没放对位置如果报Access denied for user是db.properties里的账号密码不对或者是 MySQL 8 的caching_sha2_password认证方式跟老驱动不兼容。第三步登录成功后观察房态板有没有数据。这一步能验证 Servlet 转发、DAO 查询、JSP 渲染三段是否都通。空数据和白屏是两回事空数据通常是 SQL 条件写错或者request.setAttribute的 key 和页面${pb.list}对不上白屏一般是 forward 路径写错或者页面抛了异常被吞掉。// EncodingFilter放在过滤器链最前面解决 POST 中文参数乱码 WebFilter(/*) public class EncodingFilter implements Filter { Override public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { req.setCharacterEncoding(UTF-8); // 只对 POST 请求体生效 resp.setCharacterEncoding(UTF-8); resp.setContentType(text/html;charsetUTF-8); chain.doFilter(req, resp); // 放行到下一个过滤器或 Servlet } }这个过滤器解决的是请求体和响应流的编码管不到 URL 上的 GET 参数——GET 参数的编码由 Tomcat 的server.xml里 Connector 的URIEncoding决定Tomcat 8 以后默认就是 UTF-8所以一般不用动。很多人遇到中文乱码就在页面顶部加pageEncoding加完发现还是乱就是因为只改了 JSP 源码的读取编码没改请求参数的解析编码两件事。4. 核心链路拆解从预订占房到退房结账的事务与状态机4.1 房态与订单状态怎么对应这套系统真正难的不是增删改查是状态推进的一致性。房间有五个状态订单有四个状态两者之间是一张映射表写代码前先把这张表画在纸上比写完之后到处打补丁强得多。业务动作订单状态变化房间状态变化约束条件创建预订无 → 待入住(0)空闲(0) → 已预订(1)房间当前必须为空闲取消预订待入住(0) → 已取消(3)已预订(1) → 空闲(0)未入住才能取消办理入住待入住(0) → 已入住(1)已预订(1) → 已入住(2)到店日期匹配办理退房已入住(1) → 已退房(2)已入住(2) → 脏房(4)账单必须已生成保洁完成不变脏房(4) → 空闲(0)仅内部操作这张表里最容易漏的是「取消预订后房间回到空闲」和「退房后房间进脏房而不是空闲」。前者漏了房间被永久占用房态板上那间房再也卖不出去后者漏了脏房被直接当空闲卖出去客人拎着行李进门看见上一任的毛巾投诉电话当天就到。实现上每个状态变更都写成带条件的 UPDATE而不是先查再改// RoomDao所有状态变更都带上前置状态返回影响行数 public int updateStatus(Connection conn, int roomId, int expectStatus, int targetStatus) throws SQLException { String sql UPDATE room SET status ? WHERE id ? AND status ?; try (PreparedStatement ps conn.prepareStatement(sql)) { ps.setInt(1, targetStatus); // 目标状态 ps.setInt(2, roomId); // 房间主键 ps.setInt(3, expectStatus); // 期望的当前状态不匹配则更新 0 行 return ps.executeUpdate(); } }这里把「期望状态」作为 WHERE 条件的一部分本质上是乐观锁。两个前台同时给同一间房下单只有一个能把status0改成1另一个影响行数为 0业务层拿到 0 就直接返回「房态已变化请刷新后重选」。如果写成先select status判断再update两个请求可能都读到 0然后都去改最后房间上挂着两张订单。这类问题在测试环境复现不了一上线就冒出来属于典型的并发踩坑。4.2 预订接口一个事务里改订单表和房间表预订动作要写两张表booking插一条新记录room改一次状态。这两步必须同时成功或同时失败所以事务边界要卡在 Service 层而且要用同一个 Connection。public class BookingService { private final RoomDao roomDao new RoomDao(); private final BookingDao bookingDao new BookingDao(); public String createBooking(BookingForm form) { Connection conn null; try { conn DBUtil.getConn(); conn.setAutoCommit(false); // 开启事务 // 1. 占房只有空闲房能被预订影响行数为 0 说明已被别人抢走 int locked roomDao.updateStatus(conn, form.getRoomId(), 0, 1); if (locked 0) { conn.rollback(); return 该房间已被预订或不可售请重新选择; } // 2. 写订单order_no 由日期 房间号 随机数拼成 String orderNo BK DateUtil.today() form.getRoomNo() (int) (Math.random() * 900 100); bookingDao.insert(conn, form, orderNo); conn.commit(); // 两步都成功才提交 return OK: orderNo; } catch (Exception e) { DBUtil.rollbackQuietly(conn); // 异常回滚别吞异常不记录 e.printStackTrace(); return 预订失败 e.getMessage(); } finally { DBUtil.close(conn); // 恢复自动提交并归还连接 } } }这段代码有三个参数值得单独说。form.getRoomId()是房间主键而不是房间号因为房间号可能被改比如装修后重编号主键不会。order_no拼接里带房间号和随机数是为了避免同一天同一间房多次预订导致单号重复——如果没有唯一索引兜底重复单号在结账时会关联到错误的账单。conn.rollback()放在 catch 里而不是 finally 里是因为正常提交后再回滚会抛异常。控制器那层要做参数校验不能把校验全推给数据库。到店日期必须早于离店日期日期不能早于今天roomId不能为空或者负数。这些校验如果只在前端 JS 做关掉 JS 或者用接口直接调就绕过去了脏数据会一直沉在库里。WebServlet(/booking/create) public class BookingCreateServlet extends HttpServlet { private final BookingService service new BookingService(); Override protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { BookingForm form new BookingForm(); form.setRoomId(Integer.parseInt(req.getParameter(roomId))); form.setRoomNo(req.getParameter(roomNo)); form.setCustomerName(req.getParameter(customerName)); form.setCheckInDate(req.getParameter(checkInDate)); form.setCheckOutDate(req.getParameter(checkOutDate)); if (!form.dateValid()) { // 日期合法性前置校验 req.setAttribute(msg, 入住日期必须早于离店日期); req.getRequestDispatcher(/WEB-INF/jsp/booking/create.jsp).forward(req, resp); return; } String result service.createBooking(form); if (result.startsWith(OK:)) { resp.sendRedirect(req.getContextPath() /room/list); // 成功后重定向防重复提交 } else { req.setAttribute(msg, result); req.getRequestDispatcher(/WEB-INF/jsp/booking/create.jsp).forward(req, resp); } } }成功后用sendRedirect而不是forward是为了避免用户按 F5 重复提交订单。这个细节很多人不当回事直到有客人真的刷新了三次页面系统里多出三张同房间的预订单前台只能挨个去取消。4.3 退房结算账单金额怎么算、状态怎么收口退房是整条链路上业务最重的一环要算钱、要写账单、要改订单、要改房态四件事。算法本身不复杂房费按实际入住天数乘房型单价加上消费项减去押金。public BigDecimal calcRoomFee(LocalDate in, LocalDate out, BigDecimal price) { long nights ChronoUnit.DAYS.between(in, out); // 按自然晚数算不是按小时 if (nights 0) nights 1; // 当天入当天退按一晚收 return price.multiply(BigDecimal.valueOf(nights)); }计费口径一定要跟前台口头习惯对齐。有的酒店超过中午 12 点退房加收半天有的按 24 小时滚动计费这些规则如果不在需求确认阶段定死写完之后改起来就是牵一发动全身。常见做法是把计费规则抽成一个独立方法参数里带上酒店配置的「退房时间」业务代码只管调规则怎么变都只改这一处。结算的 SQL 序列同样要包在事务里-- 1. 写账单 INSERT INTO bill (booking_id, room_fee, other_fee, total_fee, pay_type, pay_time) VALUES (?, ?, ?, ?, ?, NOW()); -- 2. 关订单只允许已入住的订单被关闭 UPDATE booking SET status 2 WHERE id ? AND status 1; -- 3. 房间转脏房等待保洁 UPDATE room SET status 4 WHERE id ? AND status 2;三条语句的影响行数都要检查。第二步返回 0 行说明这单已经被别人退过了或者根本没入住就点了退房这时候必须回滚否则账单已经插进去但订单还是「已入住」月底统计时这单会重复计入营收。5. 常见问题排查房态不同步、乱码和连接泄漏的踩坑记录5.1 房态和订单对不上现象房态板上某间房显示「空闲」但点进去预订时提示已被占用或者反过来房间显示「已预订」却找不到任何有效订单。原因九成是状态更新没进同一个事务。典型写法是 Servlet 里先调roomDao.updateStatus()再调bookingDao.insert()两次各自打开连接各自提交中间一旦抛异常比如订单号重复触发唯一索引房间状态改了但订单没写进去房态就悬在那了。还有一种情况是取消预订的代码只改了订单状态忘了把房间从 1 改回 0。解决所有跨表的状态变更统一收进 Service 层用同一个 Connection 开事务检查每一步的影响行数任何一步为 0 就整体回滚。上线前跑一遍对账 SQL把不一致的数据捞出来-- 找出状态矛盾和孤儿房态有已预订状态却没有对应待入住订单的房间 SELECT r.id, r.room_no, r.status FROM room r LEFT JOIN booking b ON b.room_id r.id AND b.status 0 WHERE r.status 1 AND b.id IS NULL;这条 SQL 建议做成一个后台小工具每天早上跑一次比等客人投诉再查日志高效得多。5.2 中文乱码与页面取值异常现象表单提交的客户姓名在列表页显示成????或者 EL 表达式${room.roomNo}在页面上原样输出没有被解析。原因乱码的根因是请求体按 ISO-8859-1 解码。JSP 顶部的pageEncoding只管源文件读取编码不管请求参数。EL 不解析通常是两个原因JSTL 的 jar 没放全或者 web.xml 的版本声明太低2.3 及以下默认关闭 EL 求值还有一种是把页面放在了WEB-INF外面但isELIgnored被设成了 true。解决乱码统一交给编码过滤器放在过滤器链的第一位且要在任何读取参数的代码之前执行。EL 问题先看 lib 目录里jstl和standard是不是都在再检查 web.xml 的web-app version3.1声明。如果只用了${}没用c:xxx标签其实不引 JSTL 也能解析但一旦混用就必须两个包都齐。提示数据库字符集、表字符集、连接串字符集、页面编码、过滤器编码这五处必须全部是 UTF-8有一处掉队就会在某个特定入口冒乱码其他入口正常。5.3 连接池耗尽、404 和部署类问题现象系统用着用着所有操作都卡住日志里出现Communications link failure或者Too many connections另一种是本地跑得好好的部署到现场服务器就 404。原因连接泄漏。DAO 里Connection、PreparedStatement、ResultSet只关了其中一两个异常路径下更是一个都不关。MySQL 的wait_timeout默认 8 小时连接被服务端断开后客户端还拿着失效连接用就会报通信失败。404 则多半是 war 包名和访问路径不一致或者 JSP 放在WEB-INF下却直接用浏览器地址访问。解决优先用 try-with-resources 管资源写起来比 finally 干净异常路径也不会漏public Room findById(int id) { String sql SELECT id, room_no, type_id, floor, status FROM room WHERE id ?; // try 括号里的资源会在代码块结束时自动 close包括抛异常的情况 try (Connection conn DBUtil.getConn(); PreparedStatement ps conn.prepareStatement(sql)) { ps.setInt(1, id); try (ResultSet rs ps.executeQuery()) { return rs.next() ? RoomMapper.map(rs) : null; } } catch (SQLException e) { throw new RuntimeException(查询房间失败, id id, e); // 带上参数便于定位 } }访问路径这块把 war 包名改成ROOT.war就能用根路径访问否则所有请求都要带项目名。改路径之后记得把代码里写死的redirect(/room/list)补上req.getContextPath()不然从根路径部署后全跳 404。5.4 日期与金额的类型陷阱现象预订日期存进库里少一天结账金额出现233.29999999999998打印小票上多出一串小数。原因日期用java.util.Date加SimpleDateFormat转换时时区差或者格式串写错MM和mm混用前者是月后者是分金额用double存二进制浮点本身无法精确表示小数。解决日期统一用LocalDateJDBC 8 驱动支持直接ps.setObject(index, localDate)取出来用rs.getObject(col, LocalDate.class)中间不经过字符串。金额全链路用BigDecimal数据库字段用decimal(10,2)展示时用setScale(2, RoundingMode.HALF_UP)统一保留两位。这两个类型问题看起来琐碎但属于改一次就再也不用管的类型早改早省心。6. 二次开发把整页刷新的房态板改成按楼层懒加载这套系统上线后最先撑不住的往往不是数据库是房态板。原始实现是每次刷新把全部房间一次性查出来渲染房量一百间以内还行三百间以上首屏就明显卡顿前台一边接客一边等页面转圈体验直接崩。我一般会从这一处开刀因为它同时练到了接口设计、前端交互和分页边界。改造思路是把「全量渲染」换成「按楼层按需拉取」。后端加一个返回 JSON 的接口复用已有的 RoomDao只是不再走 forward 而是直接写响应流WebServlet(/api/room/list) public class RoomApiServlet extends HttpServlet { private final RoomDao roomDao new RoomDao(); Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException { String floorParam req.getParameter(floor); // 楼层不传则查全部 Integer floor (floorParam null || floorParam.isEmpty()) ? null : Integer.valueOf(floorParam); ListRoom list roomDao.listByFloor(floor); // 复用已有 DAO 方法 resp.setContentType(application/json;charsetUTF-8); PrintWriter out resp.getWriter(); StringBuilder sb new StringBuilder([); for (int i 0; i list.size(); i) { Room r list.get(i); if (i 0) sb.append(,); // 只输出页面需要的字段别把整个实体序列化出去 sb.append(String.format({\id\:%d,\roomNo\:\%s\,\status\:%d}, r.getId(), r.getRoomNo(), r.getStatus())); } out.write(sb.append(]).toString()); } }前端在楼层切换时用fetch换数据房态卡片只重绘局部容器不再整页 reload。验证方法很直接改造前后各用浏览器开发者工具的网络面板对比一次请求的响应体大小和 DOM 重绘次数正常情况下响应体会从几百 KB 降到几 KB 量级。同时必须专门测一次边界——楼层下没有任何房间时接口返回空数组而不是 null前端拿到null去.forEach会直接白屏这个坑我在两个项目里都踩过。我自己后来养成一个习惯任何一次「查询改接口」的重构都先用旧实现跑一遍全量数据存成基线再用新接口跑同样条件做逐字段比对差异为零才允许合并。房态这种一秒都不能错的模块靠肉眼点几下页面是验不出来的。希望帮到你。本文还有配套的精品资源点击获取