企业官网建设流程全解析

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 的自动配置能省掉大量 XML，MyBatis-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`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

订单表是第二张核心表，主要记录每一次入住、退房的过程。它的字段要包含订单号、房间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 统一返回结构与异常处理

后端接口如果每个方法返回不同的结构，小程序端解析起来会非常痛苦。我定义了一个统一返回对象Result<T>，包含code、msg、data三个字段。code=200表示成功，code=400表示业务异常，code=401表示未登录，code=500表示系统异常。所有接口都返回这个结构，小程序端request.js只需要判断一次code就能统一处理。

异常处理用@RestControllerAdvice加上全局异常类。业务中手动throw new BusinessException("房间已被占用")，全局异常处理器捕获后返回code=400和提示消息。这样 Controller 里不需要大量try-catch，代码干净很多，文档中也好描述“异常处理采用全局拦截方式”。

5.2 关键接口列表与权限设计

接口按功能分组，我整理了一个接口文档表：

权限设计这里要明确：不是所有人都能访问全部接口。前台和管理员可以开房退房，保洁员只能查任务、完成任务。我用的最简单可行的方案是自定义注解@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，更新房间状态时使用带条件的 SQL：

UPDATE 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-size=10MB；二是保存到本地的图片，如果后端 IP 变化，前端图片地址就失效了。稳妥做法是在配置类里定义一个静态资源映射，把/upload/**映射到本地磁盘目录，这样图片 URL 与后端地址关联，不会随项目移动而失效。

6.4 请求域名与调试端口

小程序真机调试只能访问 HTTPS 域名，但开发阶段一般没有域名，怎么办？临时办法是使用开发者工具“详情-本地设置-不校验合法域名”，只适用于工具内预览。如果你手头有已经备案的域名，可以配置 Nginx 反向代理，把/api/路径转发到本地的 8080 端口。这个过程不复杂：安装 Nginx，修改配置文件，重启服务，再把小程序端BASE_URL改为https://你的域名/api，真机就能稳定联调了。

6.5 答辩演示前必须检查的清单

最后再分享一份实操检查清单。这些坑我全踩过，每次演示前我都会按这个顺序过一遍：

• 检查 MySQL 服务是否启动，数据库连接是否正常；
• 检查后端服务端口是否被占用，启动日志有没有报错；
• 用局域网 IP 访问一次后端接口，确认网络通；
• 小程序开发者工具中确认“不校验合法域名”勾选状态；
• 准备一个“演示专用房间数据”，先造好几间不同状态的房间；
• 提前预演一次完整的入住、退房、清扫流程，确认没有状态卡住。

6.6 文档写作与资料整理的经验

源码做好之后，配套文档别匆匆忙忙乱写。我的建议是边写代码边记录决策点，比如“为什么房间状态用整数不用字符串”“为什么接口采用统一返回结构”。这些记录最终直接变成文档里的“系统设计说明”，非常真实可信。文档里的截图尽量自己重新截一次，不要复用网上的图，答辩老师如果发现图文不对应，问题会很难回答。

我个人整理过一段时间的思路是：把数据库建表 SQL、接口 Postman测试用例、页面截图都放在项目根目录下的docs文件夹里，写文档时直接引用。这样既方便自己复盘，也方便代码跑不通时快速定位问题。如果时间实在紧张，优先保证“房间管理、入住退房、清扫任务”三个模块能完整演示，这三个模块已经覆盖了项目标题的核心关键词“酒店客房管理”，也足以支撑一次高质量的答辩。

最后分享一个我做这个项目时最深的体会：不要一开始就埋头写代码，先画一张房态流转表，把每种状态从哪来、到哪去标清楚。这张表既能指导你写事务和状态更新逻辑，又能在答辩时直接展示，一举两得。如果你打算对这个小程序做二次扩展，建议下一步把“线上预订”和“会员储值”加进去，这样项目就从内部管理系统变成了完整的酒店业务闭环，难度和含金量都会再上一个台阶。