1. 酒店客房管理小程序毕设怎么做需求拆解与功能规划提到“基于微信的酒店客房管理小程序”这种毕业设计选题很多同学的第一反应是“又一个管理系统老套路了”。但真正动手之后才会发现它并不是单纯的增删改查因为有微信小程序端所以牵扯到登录态、页面授权、真机调试因为业务是酒店客房所以房间状态、入住退房、押金账目这些环节环环相扣。把这些逻辑理顺再把代码和配套文档写完整就是一个能拿出来讲清楚、能演示、能答辩的完整毕设项目。这个项目适合谁呢主要是计算机相关专业、需要完成毕业设计或课程设计的同学。它既能体现微信生态开发能力又能覆盖Web后端、数据库设计、接口联调这些计算机专业核心技能。往大了说它还可以作为中小型酒店、民宿、公寓的前台管理原型后续扩展线上预订、扫码入住都不难。我做这个项目时整体规划是小程序端负责客房展示、开房退房、清扫上报和基础统计后端负责用户鉴权、房间状态管理、订单流水和报表数据配套文档则说明需求分析、数据库设计、接口定义和测试结果。这里先给出一个功能地图后面所有代码和流程都围绕这几条线展开酒店管理端管理员/前台共用房间信息维护、房型价格设置、入住登记、退房结账、换房续住、清扫任务指派。客房部员工端查看今日清扫任务、上报房间清洁状态、提交维修申请。住客/访客小程序端可选扩展查看房型、提交预订意向、查询订单状态。如果毕设时间紧张这个端可以弱化为“在线预订订单查询”只要保证能演示即可。公共模块微信登录、图片上传、消息通知、数据统计。这个功能地图看起来多但真到编码阶段核心就是两张表的事房间表和订单表。把这两张表的状态字段设计好80%的业务逻辑都不会乱。2. 微信小程序端与后端技术选型为什么这么搭2.1 小程序端的技术选择与页面结构微信小程序端我选择的是原生小程序框架而不是用第三方跨端框架。原因很简单毕设项目要稳定、要少踩坑原生框架编译简单、开发者工具调试最顺畅官方文档和社区例子最多答辩时老师一眼就能看懂页面结构。如果你的项目想做得更“工程化”后面接一个用 Vue 写的小程序框架也是可以的但对毕设来说收益不大反而增加构建配置的复杂度。小程序页面我划分成了五个主包页面登录页、首页客房列表与房间状态看板、开房/登记页、订单详情页、我的页面角色切换入口。房态页要重点做好视觉区分比如绿色代表“空净房”、黄色代表“已预订”、红色代表“脏房/维修房”。这个颜色状态非常直观是答辩演示时最容易加分的点。从代码层面看每个页面由四个文件组成.wxml负责结构、.wxss负责样式、.js负责逻辑、.json负责页面配置。公共请求封装放在utils/request.js里统一处理 baseURL、token 注入和错误提示避免每个页面重复写wx.request。示例封装如下const BASE_URL http://127.0.0.1:8080/api; const request (url, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL url, method, data, header: { Content-Type: application/json, Authorization: wx.getStorageSync(token) || }, success(res) { if (res.data.code 200) { resolve(res.data.data); } else { wx.showToast({ title: res.data.msg || 请求失败, icon: none }); reject(res.data); } }, fail(err) { wx.showToast({ title: 网络异常, icon: none }); reject(err); } }); }); }; module.exports { request };2.2 后端框架选型与理由后端我选择的是 Spring Boot配合 MyBatis-Plus 操作数据库。之所以不用 SSH 那套老架构是因为 Spring Boot 的自动配置能省掉大量 XMLMyBatis-Plus 又能把单表 CRUD、分页查询直接封装好代码量至少少一半。数据库用 MySQL 8.0本地开发用 Navicat 管理表结构。如果你更熟悉 Node.js用 Express 或 NestJS 也可以因为毕设的核心是业务逻辑的完整性和文档的规范性语言本身不是评分重点。但我的建议是如果学校课程里教过 Java就尽量用 Spring Boot教师答辩时接受度最高。后端整体分层我拆成四层Controller接收参数、Service处理业务、Mapper操作数据库、entity做数据映射。这套分层写熟了写配套文档的时候直接按层描述职责就行。2.3 为什么一定要有配套设计文档很多同学以为“LW文档”就是随便写写、凑字数这是大错特错。毕业设计的评分体系中文档往往占一半比例。评审老师不一定会立刻跑你的代码但一定先翻文档看你的需求分析是否清楚、ER 图是否完整、接口设计是否规范。更重要的是答辩时的提问基本都是从文档里抽出来的文档里写明白的内容回答时可以“照着自己的思路讲”比临场编答案靠谱得多。我写文档时采用的结构是绪论、需求分析、系统设计、数据库设计、系统实现、系统测试、总结。其中数据库设计和接口设计是核心章节需要画 ER 图、建表说明、核心接口用例表。做完项目再写文档时你会发现文档和代码是互相校验的代码里实现不了的逻辑文档里也别硬写文档里设计了的功能代码里务必跑通。3. 数据库表设计与房间状态机整个项目的命脉3.1 核心表结构设计酒店客房管理系统的核心数据表有这几张房间表、房型表、订单表、客户表、清扫记录表、操作日志表。房间表和房型表分开是因为同一房型会有多间房比如“大床房A101、A102”共用“大床房”这个价格与设施定义避免每间房重复存价格信息。房间表可以这样设计CREATE TABLE t_room ( id int NOT NULL AUTO_INCREMENT, room_no varchar(10) NOT NULL COMMENT 房间号, type_id int NOT NULL COMMENT 房型ID, floor int DEFAULT NULL COMMENT 楼层, status tinyint NOT NULL DEFAULT 0 COMMENT 0空闲(干净) 1已入住 2脏房 3维修 4预留, remark varchar(255) DEFAULT NULL COMMENT 备注, PRIMARY KEY (id), UNIQUE KEY uk_room_no (room_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;订单表是第二张核心表主要记录每一次入住、退房的过程。它的字段要包含订单号、房间ID、住客姓名、手机号、房价、押金、入住时间、预计退房时间、实际退房时间、订单状态、操作人。订单状态建议用数字表示0表示待入住、1表示入住中、2表示已退房、3表示已取消。3.2 房间状态机为什么要“锁状态”这里的重点来了房间状态的变化不是随便改的要严格按照状态机来流转。比如一间房的合法状态路径是空闲干净房 - 入住中客人办理入住入住中 - 脏房客人退房等待清扫脏房 - 空闲干净房保洁上报已完成空闲干净房 - 维修房保修维修房 - 空闲干净房维修完成状态机存在的意义是防止脏数据。比如保洁员在“已入住”状态下点“清扫完成”业务上是不合理的客人还没退房房间怎么可能被打扫干净所以后端接口里不能只做一个通用的updateRoomStatus而是要根据当前状态判断下一个合法状态是什么。如果请求的状态跳变不合法直接返回错误码提示而不是默默修改成功。这个设计在答辩时非常加分。很多同学的管理系统都是想改就改完全没有流转控制而你的系统把状态机画清楚了就体现了“领域建模”的意识。写配套文档时状态图可以直接用表格描述合法状态迁移不需要复杂的画图工具。3.3 订单与房间的关联设计开房操作本质上是新建订单 修改房间状态这两个动作必须在一个事务里。如果订单插进去了但房间状态没改会出现“一房多卖”如果房间状态改了但订单没插进去会出现“有房没人住”。Spring Boot 中可以用Transactional注解保证这两个操作要么都成功、要么都失败。退房操作则是修改订单状态为已退房 房间状态改为脏房 计算消费金额 记录操作日志。消费金额的计算规则也要提前定义清楚按时长计费、按天计费、是否有钟点房规则。我做的是按“实际退房时间减去入住时间”计算天数不满半天按半天计费再减去已缴押金得出补缴金额。这个规则在文档的需求分析里必须写清楚否则答辩时被问“你们的计费规则是什么”会答得含糊。4. 核心功能实现与页面联调从登录到退房的全流程4.1 微信登录与身份绑定小程序端最麻烦的地方就是登录态。微信小程序有自己的wx.login接口可以拿到临时code后端拿这个code去微信接口换取openid。这里有一点要特别注意2021年后微信调整了登录接口策略直接在后端用code换取openid并生成自定义 token 的方式依然可行但更推荐的做法是小程序端通过wx.login拿到 code 后传给后端后端调用微信接口解析出 openid再根据 openid 找到对应的用户记录生成自己的会话 token。这个 token 放在请求头Authorization字段里后端用拦截器统一校验。如果用户没登录返回 401小程序端检测到 401 后跳转登录页。注意如果后端部署在本地小程序开发者工具必须勾选“不校验合法域名”否则请求会被拦截。真机调试时还要在微信公众平台里配置 request 合法域名且域名必须为 HTTPS 地址。这块是新手最容易卡住的地方后面我会单独写排查方法。4.2 房态看板与房间查询实现首页的核心接口是“房间列表 房态统计”。小程序端进入页面时调用GET /room/list后端返回每个房间的房间号、房型名、楼层、状态值、状态文本。为了减少请求次数这个接口可以同时把房态统计返回回来比如空闲多少间、入住多少间、脏房多少间首页顶部直接展示数字卡片。接口返回结构我设计为{ code: 200, msg: success, data: { stat: { free: 12, occupied: 18, dirty: 5, repair: 1 }, list: [ { roomId: 1, roomNo: A101, typeName: 大床房, floor: 1, status: 0 } ] } }小程序端拿到数据后通过wx:for循环渲染房间卡片不同状态绑定不同class实现颜色区分。这里有个小技巧卡片上不要只显示“空闲/入住”要带上“电脑能直接看的编号可点击动作”比如空闲房点击后直接弹出“办理入住”按钮脏房点击后弹出“清扫完成”按钮。这样演示时会非常流畅评委不需要知道内部逻辑就能看到房间状态的变化是实时的。4.3 入住、退房、续住的流程闭环入住流程是小程序端的核心操作。前台员工在房态页选一间空闲房点击“办理入住”进入开房表单页。表单包含住客姓名、手机号、证件号模拟、押金金额、房型价格自动带出、预计退房日期。提交后后端在事务里完成“插入订单 房间状态改为已入住”两个动作并生成订单号。订单号我用的是日期随机数例如202506011530123456避免并发冲突。退房流程相对简单但要注意补缴金额的计算。后端根据订单的实际入住时长计算总房价再减去已收押金得到“应补”金额。如果押金大于房费还要展示“应退”金额。退房成功后订单状态更新为已退房房间状态自动变为脏房同时插入一条清扫任务记录。续住流程本质上就是修改订单的预计退房时间同时可能加收费用。这个模块往往被初学者忽略但酒店业务里非常常见。如果不做续住客人延住一天就无法处理。我在订单详情页加了一个“续住”按钮点击后弹窗输入新的退房日期后端更新预计退房时间并生成一笔加收流水记录到日志表里。4.4 清扫任务与统计报表清扫任务这块是体现完整性的关键功能。入住和退房之外如果没有员工任务模块整个系统就只是“前台点两下按钮”缺少多角色协作。我的设计是客人退房后系统自动生成一条清扫任务任务状态为“待清理”分配给客房部员工这里简单做成按楼层分配。保洁员登录后能看到自己负责的清扫任务点击“开始清扫”再点“完成清扫”房间状态从脏房变为空闲干净房。统计报表我放在“我的”页面里提供今日入住数、今日退房数、当前入住率、今日营收四个指标。后端写一个汇总查询接口用 SQL 的COUNT和SUM搞定。如果想做得更精致可以按日期做折线图小程序端用ec-canvas组件绘制。但要注意ec-canvas插件体积较大加载慢如果只是毕设演示用数字卡片展示即可。5. 后端接口设计与联调细节代码之外的关键点5.1 统一返回结构与异常处理后端接口如果每个方法返回不同的结构小程序端解析起来会非常痛苦。我定义了一个统一返回对象ResultT包含code、msg、data三个字段。code200表示成功code400表示业务异常code401表示未登录code500表示系统异常。所有接口都返回这个结构小程序端request.js只需要判断一次code就能统一处理。异常处理用RestControllerAdvice加上全局异常类。业务中手动throw new BusinessException(房间已被占用)全局异常处理器捕获后返回code400和提示消息。这样 Controller 里不需要大量try-catch代码干净很多文档中也好描述“异常处理采用全局拦截方式”。5.2 关键接口列表与权限设计接口按功能分组我整理了一个接口文档表模块接口路径请求方式说明认证/api/loginPOST微信登录获取token房间/api/room/listGET房间列表房态统计房间/api/room/changeStatusPOST状态变更内部校验状态机订单/api/order/createPOST创建订单并办理入住订单/api/order/checkoutPOST退房结账订单/api/order/renewPOST续住清扫/api/task/listGET清扫任务列表清扫/api/task/completePOST完成清扫统计/api/stats/todayGET今日经营数据权限设计这里要明确不是所有人都能访问全部接口。前台和管理员可以开房退房保洁员只能查任务、完成任务。我用的最简单可行的方案是自定义注解RequireRole在 Controller 方法上标注角色编码拦截器里校验当前登录用户的角色是否有权限。这样代码直观文档里也容易解释。5.3 本地部署与真机预览注意事项本地跑通整个项目需要注意几点。第一MySQL 字符集要设成utf8mb4否则中文和 emoji 可能乱码第二Spring Boot 的配置文件里要把server.address设为0.0.0.0否则真机无法访问电脑上的后端第三小程序端BASE_URL不要写localhost要写你电脑在局域网中的 IP比如http://192.168.1.100:8080/api真机和小程序开发者工具才能同时访问。真机预览时开发者工具上传代码后在手机上打开体验版。这里如果页面白屏或请求失败八成是合法域名没配置。如果还没有域名可以暂时在开发者工具里勾选“不校验合法域名”但正式提交审核时必须配置 HTTPS 域名。这类问题很常见下面我统一整理。6. 常见问题与排查技巧实录毕设答辩前的坑6.1 登录态失效与 openid 获取失败这是问得最多的问题。表现是开发者工具里能正常登录真机上却一直跳登录页。原因一般是后端调用微信接口获取openid时code已经过期或已被使用。wx.login获取的 code 只能用一次有效期为五分钟拿到后要立刻传给后端。另一个原因是后端服务器时间不准与微信服务器的时间偏差过大也会导致验签失败。排查时可以先把后端日志打开看wechat.api的返回参数如果返回errcode: 40029说明 code 无效如果返回40163说明 code 已被复用。6.2 房态不同步与并发订房两个前台同时操作同一间空闲房可能出现重复入住。解决办法是在t_room表加一个乐观锁字段version更新房间状态时使用带条件的 SQLUPDATE t_room SET status 1, version version 1 WHERE id #{roomId} AND status 0 AND version #{oldVersion}如果影响行数为 0说明房间已被别人抢住后端直接抛出业务异常提示“该房间已被占用”。这个点在文档中可以作为“并发控制”章节重点写能体现你的系统设计不是玩具级别。6.3 图片上传与临时文件存储如果房间模块需要上传房间照片小程序端可以用wx.chooseMedia选择图片再通过wx.uploadFile传到后端。后端接收文件后保存到服务器本地目录并在数据库里记录 URL。这里有两个坑一是默认 Spring Boot 上传文件大小上限只有 1MB需要配置spring.servlet.multipart.max-file-size10MB二是保存到本地的图片如果后端 IP 变化前端图片地址就失效了。稳妥做法是在配置类里定义一个静态资源映射把/upload/**映射到本地磁盘目录这样图片 URL 与后端地址关联不会随项目移动而失效。6.4 请求域名与调试端口小程序真机调试只能访问 HTTPS 域名但开发阶段一般没有域名怎么办临时办法是使用开发者工具“详情-本地设置-不校验合法域名”只适用于工具内预览。如果你手头有已经备案的域名可以配置 Nginx 反向代理把/api/路径转发到本地的 8080 端口。这个过程不复杂安装 Nginx修改配置文件重启服务再把小程序端BASE_URL改为https://你的域名/api真机就能稳定联调了。6.5 答辩演示前必须检查的清单最后再分享一份实操检查清单。这些坑我全踩过每次演示前我都会按这个顺序过一遍检查 MySQL 服务是否启动数据库连接是否正常检查后端服务端口是否被占用启动日志有没有报错用局域网 IP 访问一次后端接口确认网络通小程序开发者工具中确认“不校验合法域名”勾选状态准备一个“演示专用房间数据”先造好几间不同状态的房间提前预演一次完整的入住、退房、清扫流程确认没有状态卡住。6.6 文档写作与资料整理的经验源码做好之后配套文档别匆匆忙忙乱写。我的建议是边写代码边记录决策点比如“为什么房间状态用整数不用字符串”“为什么接口采用统一返回结构”。这些记录最终直接变成文档里的“系统设计说明”非常真实可信。文档里的截图尽量自己重新截一次不要复用网上的图答辩老师如果发现图文不对应问题会很难回答。我个人整理过一段时间的思路是把数据库建表 SQL、接口 Postman测试用例、页面截图都放在项目根目录下的docs文件夹里写文档时直接引用。这样既方便自己复盘也方便代码跑不通时快速定位问题。如果时间实在紧张优先保证“房间管理、入住退房、清扫任务”三个模块能完整演示这三个模块已经覆盖了项目标题的核心关键词“酒店客房管理”也足以支撑一次高质量的答辩。最后分享一个我做这个项目时最深的体会不要一开始就埋头写代码先画一张房态流转表把每种状态从哪来、到哪去标清楚。这张表既能指导你写事务和状态更新逻辑又能在答辩时直接展示一举两得。如果你打算对这个小程序做二次扩展建议下一步把“线上预订”和“会员储值”加进去这样项目就从内部管理系统变成了完整的酒店业务闭环难度和含金量都会再上一个台阶。
