简介一套面向毕业设计及中小型酒店信息化场景的完整微信小程序酒店管理系统涵盖前台管理、后台运营与用户端小程序三条业务线可实现在线预订、客房管理、客户管理、订单处理、财务核算及员工管理等核心流程适合计算机专业学生作为毕设参考也适合开发者快速搭建酒店管理原型。压缩包共1091个文件大小约33.19MB以png/svg界面素材、vue/java/js前后端源码、wxss/wxml小程序页面、json配置、sql数据库脚本及bat部署脚本为主目录结构清晰。附带的三个批处理脚本分别承担环境初始化、运行启动与项目打包能有效降低本地部署门槛。已有275人浏览学习对需要理解前后端分离结构、小程序与后台联调以及角色权限设计的读者是一份高参考价值的实操范例。1. 微信小程序酒店管理系统一套能直接跑起来的毕业设计源码如果你正在找一份能写进简历、能应付毕业答辩的“管理系统”类项目这套基于微信小程序的酒店管理系统值得花一个晚上拆一遍。它不是单薄的页面Demo而是把酒店前台管理、后台运营管理和用户手机端小程序三端都装进了一个压缩包员工能办理预订和入住登记管理者能看统计数据、管房间和员工顾客在小程序里查房、下单、支付。对做毕业设计或课程设计的人来说这套系统最大的价值是给你一条完整可跑通的业务链路不用自己从零搭框架。后文我会按部署顺序拆解它的架构、关键代码和最容易翻车的地方让你拿到手能顺利跑起来。2. 三端架构与代码结构从 .bat 到 .bak 看这套系统的真实分工2.1 三端如何分工数据又是怎么流起来的这套酒店管理系统在业务上被拆成了三个独立却又互相依赖的部分这一点在摘要描述里已经说得很明确前台管理系统、后台管理系统、用户手机端小程序。先说前台管理系统它是给酒店前台员工用的。员工在电脑上打开管理页面完成客户的入住登记、退房结算、更换房型这些日常操作。它的特点是操作频率高、流程短所以界面设计上更强调“一个页面内完成一件事”。比如入住登记页面通常就是把客户信息、房型选择、入住时间、押金金额放在同一屏内不需要跳来跳去。后台管理系统则是给酒店老板或运营经理看的它关心的是数据而不是操作。房间状态总数、今日入住率、订单收入趋势、员工工作量排名这些信息都会被汇总成图表和报表。它和前台管理系统的关键区别在于前台是“干活的人用”后台是“看结果的人用”。同一个订房动作在前台产生一条订单记录在后台就变成统计数据的一部分。用户手机端的小程序是面对C端顾客的。顾客进入小程序后能看到房型列表、当前可订状态选择入住日期和离店日期后生成订单再完成支付。小程序端的业务逻辑最简单但它却是整个系统里最容易出问题的一段因为房间库存的判断、订单状态的变更都要通过接口和后端进行联动。三条链路最终汇合在后端服务上小程序下单产生订单数据前台员工办理入住时把订单状态从“已支付”改成“已入住”退房时改成“已完成”后台管理端则不断从订单表、房间表、员工表中读取数据生成统计结果。理解这条数据流比记住某个页面的写法重要得多后面所有排错都是围绕这条链路展开的。2.2 从压缩包里的文件特征先判断这套系统是什么技术栈拿到压缩包后先别急着双击看页面看一眼文件列表就能猜出七八分技术栈。比如压缩包里有 3-build.bat、2-run.bat、1-install.bat 这三个批处理文件这种命名方式在前端项目里出现频率极高一看就是给 Vue 或 React 工程准备的快捷启动脚本。再看文件列表里还有 main.css.bak、update-password.vue.bak、IndexAsideStatic.vue.bak、BreadCrumbs.vue.bak、IndexHeader.vue.bak 这些 .vue 后缀文件基本可以确定后台管理和前台管理这两个端是 Vue 技术栈实现的。我拿到这套资源时的文件结构大体如下酒店管理系统/ ├── 1-install.bat # 安装前端项目依赖 ├── 2-run.bat # 启动前端开发服务 ├── 3-build.bat # 打包前端生产版本 ├── .classpath # Eclipse Java 工程配置 ├── org.eclipse.wst.common.component # Eclipse Web 工程组件配置 ├── src/ │ ├── main/ │ │ ├── java/ # 后端 Java 源码 │ │ └── resources/ # 数据库脚本、配置文件 │ └── ... ├── hotel-admin/ # 后台管理系统源码Vue ├── hotel-front/ # 前台管理系统源码Vue └── miniprogram/ # 微信小程序端源码其中 .classpath 和 org.eclipse.wst.common.component 这两个文件强烈暗示后端是 Java 技术栈而且是 Eclipse 环境下创建的动态 Web 工程或 Spring Boot 工程。结合“毕业设计”“管理系统”这类场景这大概率是一套 Spring Boot MyBatis MySQL 的后端前台和后台各是一个 Vue 工程小程序端是原生微信小程序框架。.bak 后缀文件的存在其实是个好消息。它说明作者在开发过程中留过旧版本备份比如修改密码页面重写过、侧边栏组件调整过。对你有用的不是去恢复备份而是可以通过对比 .bak 文件和当前文件看出哪些功能改动过当你需要二次开发时能更快定位到“这段逻辑为什么这样写”。2.3 数据模型与接口约定的常见设计三端共享同一个后端数据的口径就非常重要。这种课设级酒店管理系统数据库表的设计一般会遵循最经典的范式房型表、房间表、客户表、订单表、员工表、财务流水表外加管理员角色表。房型表和房间表分离是为了支持“一个房型对应多间房”的场景比如豪华双床房有8间每间有独立的房间号、状态字段。订单表是整个系统的核心表字段通常包括订单号、关联客户ID、关联房间ID、入住时间和离店时间、订单状态、支付金额、创建时间。订单状态是整个系统里最需要统一约定的地方常见做法是定义成数字枚举1代表待支付2代表已支付待入住3代表已入住4代表已完成退房5代表已取消。接口设计上这类系统的路由命名习惯是 RESTful 风格加模块前缀比如 /api/room/list 查房间列表、/api/room/status 改房间状态、/api/order/create 创建订单、/api/order/checkin 执行入住登记、/api/stats/overview 拉运营总览。小程序端和 Vue 管理端都只认这一套接口所以后端接口的稳定性决定了三端联调是否顺利。后面部署时会看到端口配置和跨域处理是这里最容易踩坑的地方。3. 本地部署与跑通安装依赖、初始化数据库、启动三端的完整流程3.1 第一步初始化数据库并调整后端配置无论哪一端最先要处理的都是数据库。这套系统用的是 MySQL压缩包里通常会附带一个 .sql 脚本文件存放在后端工程 src/main/resources 目录下。建议不要用图形化工具直接双击导入而是通过命令行导入这样可以减少字符集问题带来的乱码风险。mysql -u root -p hotel_db.sql这条命令会把 SQL 文件中的建表语句和初始数据一次性执行。如果 SQL 文件里有 CREATE DATABASE 语句执行前建议先确认数据库名是否和你后端配置文件中的名称一致。导入完成后检查三张最重要的表room、orders、sys_employee确认里面数据是否正常。然后打开后端配置文件 application.yml或 application.properties这是启动后端前必须修改的文件。server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/hotel_db?useUnicodetruecharacterEncodingutf-8serverTimezoneAsia/Shanghai username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.hotel.entity这里的 url 里带了 useUnicode 和 characterEncoding 参数服务器时区也强制指定为 Asia/Shanghai这两项都是血泪经验换来的不指定时区MySQL 8.x 会报时区错误不指定编码查询中文数据时很容易出现问号。密码字段一定要改成你自己数据库的密码。3.2 第二步用三个 bat 脚本跑通前端工程这套资源里的 1-install.bat、2-run.bat、3-build.bat 就是给前端准备的快捷命令分别对应安装依赖、启动开发服务、打包生产版本。它们的实际内容通常是这样的:: 1-install.bat call npm install echo 依赖安装完成 pause:: 2-run.bat call npm run serve pause:: 3-build.bat call npm run build pause执行顺序是先双击 1-install.bat等 npm install 跑完再双击 2-run.bat 启动开发服务。如果 npm install 网络太慢可以换用淘宝镜像源npm install --registryhttps://registry.npmmirror.com2-run.bat 启动后Vue 开发服务默认跑在 8080 端口但这个端口和后端接口端口冲突的概率非常高。此时需要从前端工程根目录找到 vue.config.js修改 devServer 里的 port 字段比如改成 8081 或 8082。修改后重启 2-run.bat 才能生效。如果不做改动你大概率会看到一个端口占用报错。3.3 第三步小程序端的 AppID 与请求地址配置小程序端的配置是三端里最容易让人犯迷糊的地方。用微信开发者工具导入 miniprogram 目录后第一步不是看代码而是先在 project.config.json 里检查 appid 字段。这套资源里大概率写着测试号或占位符你需要改成自己小程序账号下的 AppID如果没有注册小程序账号可以勾选“测试号”模式本地开发完全够用。然后是请求地址的配置。小程序代码里通常会有一个全局配置段一般是 app.js 或一个独立的 config.js 文件里面维护所有 wx.request 接口的 baseURL。// app.js 或 config.js globalData: { baseURL: http://localhost:8080/api, token: }这里的 baseURL 必须指向你本机后端服务的地址。第一次调试时如果发现小程序请求全部报“request:fail”大概率是微信开发者工具里没有关闭域名校验。开发阶段需要在微信开发者工具的“详情-本地设置-勾选不校验合法域名”选项。这一步几乎每个第一次接触小程序开发的人都会卡住。3.4 前端代理配置解决跨域问题的标准做法当 Vue 管理端运行在 8081 端口后端运行在 8080 端口时浏览器直接发起 http://localhost:8080/api 请求会触发跨域限制。这个资源的常见做法是走 Vue CLI 的 devServer 代理把 /api 前缀的请求转发到后端地址。// vue.config.js module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }配置好之后前端代码里请求路径还是写着 /api/room/list但浏览器实际看到的请求地址是当前站点地址下的 /api/room/list开发服务器把它转发给真正的后端从而绕开跨域限制。我在部署这套系统时先后遇到了端口冲突和跨域失败两个问题都是靠这一段配置解决的。提示如果三个端同时启动建议分别开三个终端窗口方便看到各自的日志输出。后端启动出现报错时优先看最顶部的异常信息而不是刷屏的堆栈尾部。4. 核心业务链路与关键代码预订、入住、统计怎么连成一条线4.1 小程序端房型列表加载与创建订单小程序端的业务逻辑核心是“查询房间-选择日期-创建订单”。房型列表从后端接口拉取展示的字段包括房型名、面积、床型、价格、可订数量等。这里有一个典型的坑可订数量不是房间表里的固定字段而是根据订单状态动态算出来的所以列表展示时后端要做一次计算不能直接查 room 表返回。小程序端拉取房型列表的代码一般是这样的// pages/roomList/index.js Page({ data: { roomList: [], loading: true }, onLoad() { this.fetchRoomList() }, fetchRoomList() { const app getApp() wx.request({ url: app.globalData.baseURL /room/list, method: GET, success: (res) { if (res.data.code 200) { this.setData({ roomList: res.data.data }) } else { wx.showToast({ title: 加载失败, icon: none }) } }, complete: () { this.setData({ loading: false }) } }) } })这里的 baseURL 加了 /api 前缀而 Vue 端代理又按 /api 做转发所以前后端联调时要注意路径拼接是否重复。如果后端接口路径本身就是 /api/room/list那小程序端 baseURL 末尾就不要再加 /api否则会打出 /api/api/room/list 的错误路径。这个细节我排查过很久最后发现是路径拼接重复问题不大但特别隐蔽。创建订单时小程序端会携带 roomId、checkInDate、checkOutDate、customerName 这些参数提交到后端。这里有一个关键点入住天数和订单金额最好不交给前端算后端根据房间单价和日期差值计算避免用户篡改参数。前端只负责展示后端负责算钱这是所有管理系统应该守住的底线。4.2 前端管理端入住登记与订单状态流转前台管理系统的入住登记页面和订单列表页面是代码量最集中的部分。入住登记时员工选择订单后点击“办理入住”前端把订单号传给后端后端执行状态变更和房间状态变更。这里的状态流转不是一个 UPDATE 语句就能解决的它至少要改两张表订单表的状态改成“已入住”房间表的状态改成“打扫中”或“占用”。我用 Vue 写这类页面时的常见套路是先把状态字段做成可读的映射关系// constants/order.js export const ORDER_STATUS { 1: { label: 待支付, type: warning }, 2: { label: 待入住, type: primary }, 3: { label: 已入住, type: success }, 4: { label: 已完成, type: info }, 5: { label: 已取消, type: danger } }页面里渲染订单状态时只要读取这个映射表即可后续如果要新增“已锁房”“已退款”等状态也只需要在常量表里加一项不需要在多个页面里分别修改判断逻辑。这种写法在二次开发时非常省事强烈建议保留。前端调用入住接口的典型场景如下// views/order/checkin.vue async handleCheckin(row) { const res await axios.post(/api/order/checkin, { orderId: row.id, roomId: row.roomId, operatorId: this.employeeId }) if (res.data.code 200) { this.$message.success(入住登记成功) this.fetchOrderList() } }这里 operatorId 表示执行操作的前台员工编号后端会把它写入订单的操作日志里。很多课设项目不太注意操作人字段但答辩时老师很可能会问这笔入住是谁操作的系统的安全性体现在哪留下这个字段后你至少能回答“每个操作都有迹可循”。4.3 后端订单创建接口的事务边界与统计查询后端的关键代码集中在订单创建和统计查询。创建订单牵涉多张表必须加事务控制。一个典型的 Service 方法是这样的思路Transactional(rollbackFor Exception.class) public Order createOrder(OrderCreateDTO dto) { // 1. 检查房型剩余可订数量 RoomType roomType roomTypeMapper.selectById(dto.getRoomTypeId()); Integer available roomMapper.countAvailable(roomType.getId(), dto.getCheckInDate(), dto.getCheckOutDate()); if (available 0) { throw new BusinessException(该房型已满房); } // 2. 创建订单状态置为待支付 Order order new Order(); order.setOrderNo(generateOrderNo()); order.setRoomTypeId(roomType.getId()); order.setCustomerName(dto.getCustomerName()); order.setCheckInDate(dto.getCheckInDate()); order.setCheckOutDate(dto.getCheckOutDate()); order.setStatus(1); order.setAmount(caculateAmount(roomType, dto)); orderMapper.insert(order); // 3. 插入财务流水 FinanceRecord record new FinanceRecord(); record.setOrderId(order.getId()); record.setType(1); record.setAmount(order.getAmount()); financeRecordMapper.insert(record); return order; }这里 Transactional 注解保证了三步操作要么全部成功要么全部回滚。刚才的几个坑点都在这段代码里藏过如果只插入订单而不检查库存会出现超卖如果只插入订单而不生成财务流水后台财务管理模块就少了一条数据。课程设计里最常见的逻辑漏洞就是这些步骤不一致。统计查询则是后台管理系统的重头戏。按天统计订单收入是典型的 SQL 聚合查询Select(SELECT DATE(create_time) as date, COUNT(*) as orderCount, SUM(amount) as totalAmount FROM orders WHERE create_time BETWEEN #{startDate} AND #{endDate} GROUP BY DATE(create_time)) ListDailyStatVO dailyStats(Param(startDate) String startDate, Param(endDate) String endDate);这里的 GROUP BY DATE(create_time) 可以把每天的订单聚合到一行记录里后端拿到结果后按日期填充成图表数据。需要注意 DATE() 函数在 MySQL 里没问题但如果换用其他数据库就可能需要调整。5. 部署与改造避坑五个常见问题与排查路径5.1 前端启动报端口占用页面白屏现象双击 2-run.bat 后终端提示 listen EADDRINUSE浏览器访问一片空白。原因8080 端口被后端或其他服务占用Vue 开发服务启动失败。解决在 vue.config.js 里把 devServer.port 改成 8081 或其他空闲端口同时检查后端服务是否也占用了 8080。如果后端是 Spring Boot可以在 application.yml 中改 server.port但改了之后记得同步修改前端代理 target 的端口。5.2 小程序请求全部失败报 request:fail现象微信开发者工具里所有接口请求都不通报错信息只有 request:fail 一行。原因最常见的有三种域名校验未关闭、baseURL 写错、本机后端未启动。解决先在“详情-本地设置”勾选不校验合法域名再确认 baseURL 是否以 http 开头而不是 https最后确认后端控制台是否真的收到请求。经验是如果后端完全没打印日志问题基本出在前两步。5.3 数据库脚本导入报错或中文乱码现象导入 SQL 脚本时报语法错误或者查询出来的中文客户名全是问号。原因SQL 文件编码不是 UTF-8或 MySQL 数据库字符集不匹配。解决用命令行导入时先执行 SET NAMES utf8mb4;导入后在数据库管理工具中把表和字段的字符集统一改成 utf8mb4_general_ci。ALTER DATABASE hotel_db CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; ALTER TABLE orders CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;5.4 登录接口正常但页面始终跳回登录页现象输入正确的账号密码后登录接口返回成功但页面刷新后又回到登录页。原因token 没有写入浏览器存储或者路由守卫读取 token 的 key 和登录时写入的 key 不一致。解决打开浏览器的 Application 面板查看 Local Storage确认是否有 token 字段再检查前端路由守卫代码里读的是 localStorage.getItem(token) 还是 sessionStorage.getItem(admin_token)。这种问题十有八九是 key 名对不上。5.5 修改了 .bak 文件却不生效现象编辑了压缩包解压出来的 update-password.vue.bak 文件页面毫无变化。原因.bak 是备份文件不是程序实际运行的文件。真正的入口是 update-password.vue。解决先确认你改动的是否为带 .bak 后缀的文件如果是复制一份出来去掉 .bak 后缀再覆盖到对应源码路径。顺带提一句保留 .bak 文件没问题但提交二次开发成果前记得删掉否则会让代码评审的人困惑。6. 进阶用法把答辩版本改造成可上线状态的关键动作资源里的这套系统在课设答辩场景下足够完整但要真正把它往可上线方向推还需要补几个关键动作。第一个动作是统一接口返回格式。很多课设项目的前端代码里到处是 res.data.code 200 的判断但后端某些接口返回格式不一致有的直接返回 List有的包了一层 Result。规范的做法是统一成一个全局响应类接口无论成功失败都返回 code、message、data 三个字段前端再做一次封装。第二个动作是把硬编码配置全部外置。这套资源的小程序端 baseURL 写死在 app.js 里后端数据库连接写死在 application.yml 里。这些在本地没问题但如果将来要部署到服务器你会发现每台机器都要改源码再重新打包。正确做法是增加一个环境配置文件把根据环境切换的配置项集中管理。第三个动作是补一条完整的验证链路。每次部署完我都会按下面这个清单走一遍顺序验证动作期望结果1前端登录页面账号密码登录跳转首页路由守卫放行2小程序端查询房型列表返回可订房型和价格3小程序端提交预订订单订单状态为待支付4前台管理端办理入住订单状态变为已入住5后台管理端查看统计数据当日订单数和收入正确增加这套流程把三端串起来了任何一环报错都能说明问题定位在哪一块。做过一次后你会对这套系统的运行机制有更直观的理解答辩时老师问你“整个系统数据是怎么流动的”你可以依据这条链路完整讲一遍。还有一个容易忽视的地方是角色权限。这套资源里前台和后台虽然是两个页面工程但如果后端没有对管理接口做权限校验任何登录用户都能调 /api/stats/overview 看到运营数据。我可以很负责任地说大部分课设系统的权限都是前端显隐控制后端裸奔。你可以在后端加一个最轻量的拦截器校验请求头里的 token 对应角色的 code。只有把这一步补上系统才能算真正闭环。以后再拿到类似的带三端的新项目我会先看权限校验代码写在那里再决定是否值得改造成生产级系统从那以后我每次部署完都强制走一遍清单再交付这个习惯让我少踩了很多坑希望帮到你。本文还有配套的精品资源点击获取
