简介毕业设计论文《基于微信小程序的酒店管理系统》围绕酒店管理系统的设计与实现展开面向计算机相关专业毕业生及需要完成毕业设计论文的学生。内容涵盖系统需求分析、技术选型、功能模块设计、数据库设计、系统测试等完整流程重点论述用户管理、公告信息、新闻资讯、食物与房间订单、房型管理等模块并结合Springboot框架、Java技术、MySQL数据库及微信小程序开发者工具进行了详细剖析有助于理解前后端分离开发模式和小程序项目落地思路。资源包共1个文件为docx格式论文正文压缩包大小约3.77MB结构清晰、章节完整可直接参考其目录组织、论述逻辑和排版格式。目前已有166人学习浏览适合作为毕业论文撰写、开题准备及系统开发实践的参考资料。1. 小程序酒店管理系统不是套壳应用是一整条业务流水线“基于微信小程序的酒店管理系统”听起来像是一个标准 CRUD 课题但真正动手后会发现它横跨三条线小程序端的页面与渲染、SpringBoot 后端接口、MySQL 数据表设计中间还要处理房间预订、食物订单、用户状态这些交叉业务。我当初用 IoT 设备项目练手惯了以为这类系统两三天能拼出来结果光是一个房间订单的日期冲突就改了三版。这篇想把这套系统从需求到落地的全过程拆开讲包括前端小程序项目的目录组织、后端接口规划、订单状态机设计、MySQL 表拆分以及真机调试时最容易卡住的几个点。适合正在做类似毕业设计或者打算拿小程序项目练手但不想只做静态页面的开发者。2. 工程结构拆解SpringBoot 与微信小程序端各自该管什么2.1 B/S 架构下的小程序不是浏览器页面很多论文会把这类系统归到 B/S 架构但从运行角度讲微信小程序更像“客户端容器 远程服务”。微信开发者工具负责编译和预览真正的逻辑运行在用户微信中页面内容则通过wx.request与 SpringBoot 后端通信。选择 B/S 的核心理由是小程序端不需要安装、不需要关注后端部署方式所有业务状态都收敛到服务端这样房间、订单、新闻这些数据才能被管理员和用户共享。请求链路上典型流程是小程序Page触发事件 →setData控制视图状态 → 调用utils/request.js里的封装方法 → 发送 HTTP 请求到 SpringBoot Controller → Controller 转给 Service → Service 调用 Mapper → 返回统一结构给小程序渲染。这个链路里后端只关心接口契约前端只关心渲染和交互调试时哪一段出问题可以立刻通过控制台定位。2.2 小程序目录与逻辑层、视图层微信开发者工具创建的项目目录结构固定app.js是全局逻辑app.json注册页面和窗口样式pages/下每个页面由.wxml、.wxss、.js、.json四个文件组成。以本项目为例我习惯把pages/index/放首页、pages/room放房间列表、pages/order放订单页再单独建一个utils/request.js做请求封装。// utils/request.js 对 wx.request 做一层封装避免每个页面重复写 url const BASE_URL http://localhost:8080 function request(path, method, data) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL path, method: method || GET, data: data || {}, header: { Content-Type: application/json }, success: (res) { if (res.statusCode 200 res.data.code 200) { resolve(res.data.data) } else { wx.showToast({ title: res.data.msg || 请求失败, icon: none }) reject(res) } }, fail: (err) reject(err) }) }) } module.exports { request, BASE_URL }这段封装的核心作用是把异常和业务状态码统一处理掉。页面里调用时不需要关心statusCode和code的区别只管返回数据。注意BASE_URL在开发阶段用本地局域网 IP 时需要在微信开发者工具里勾选“不校验合法域名”否则请求会被拦截。小程序的逻辑层和视图层是分离的逻辑层改数据不会直接操作 DOM必须通过setData把数据传给视图层。这一点比 Vue 的响应式更“笨”一些但好处是数据流清晰调试时只要看setData前后数据变化就能定位问题。2.3 SpringBoot 后端分层与统一响应体后端我用的分层是 Controller、Service、Mapper、Entity 四层。Controller 只做参数接收和路由Service 写业务逻辑Mapper 直接对应 MySQL 查询。为了让小程序端判断结果更简单定义一个统一响应体// common/Result.java public class ResultT { private Integer code; private String msg; private T data; public static T ResultT success(T data) { ResultT r new Result(); r.code 200; r.msg success; r.data data; return r; } public static T ResultT error(String msg) { ResultT r new Result(); r.code 500; r.msg msg; return r; } }对应的 Controller 方法签名可以统一成Result返回例如房间列表接口RestController RequestMapping(/api/room) public class RoomController { Resource private RoomService roomService; GetMapping(/list) public ResultListRoomInfo list(RequestParam(defaultValue 1) Integer page, RequestParam(defaultValue 10) Integer pageSize) { return Result.success(roomService.pageRooms(page, pageSize)); } }统一响应体的好处是前端request.js只需要解析一层data不需要每个接口单独做状态判断。实际写的时候我习惯把page和pageSize都带上默认值避免小程序端传参不完整导致空指针。2.4 数据库设计6 张核心表与关联关系这个系统的业务模块比较多但拆开看核心还是围绕用户、房间、食物、订单四类数据。从论文里的功能需求看至少要这些表表名核心字段职责sys_userid, username, password, nickname, avatar, role管理员和普通用户共用一张表用 role 区分room_typeid, type_name, bed_num, area, price房型管理与房间是一对多room_infoid, room_no, room_type_id, image, status房间基础信息status 标记可预订/入住/维护room_orderid, order_no, user_id, room_id, checkin_date, checkout_date, total_price房间订单一个订单对应一个房间food_infoid, food_name, price, image, category_id食物信息供点餐使用cart_itemid, user_id, food_id, count购物车表提交后创建食物订单sys_user同时接待管理员和用户靠role字段区分能少一张表但对接口鉴权要求更高。room_order是整张数据库设计里最关键的表user_id和room_id是两个外键checkin_date与checkout_date用于日期冲突判断。实际建表时我给room_order加了order_no唯一索引既能做订单号查询也能天然防止重复插入。3. 从注册到预订核心模块的接口设计与参数说明3.1 注册登录账号密码与 wx.login 的选择论文里说的是账号密码注册登录但小程序真正的生态会更倾向于wx.login获取code然后后端拿code加appid、secret换openid。我的做法是两条逻辑并存新用户先用账号密码注册绑定手机号登录时如果检测到微信已授权就调用wx.login静默登录后端根据openid关联用户。// pages/login/login.js wx.login({ success: (res) { wx.request({ url: http://localhost:8080/api/user/loginByWx, method: POST, data: { code: res.code }, success: (resp) { const token resp.data.data.token wx.setStorageSync(token, token) } }) } })后端拿到code后调用微信接口换openid再查sys_user表查不到就自动注册一个账号。这样做的好处是用户无感知登录但注意secret必须放在后端不能出现在小程序代码里。如果只是毕业设计演示账号密码登录其实更直观评审时也容易说清楚。3.2 房间信息查询动态列表与详情房间列表需要支持按房型筛选、按价格排序、分页查询。用 MyBatis Plus 的LambdaQueryWrapper做动态条件非常简单public PageRoomInfo pageRooms(Integer page, Integer pageSize, Integer roomTypeId, String keyword) { LambdaQueryWrapperRoomInfo wrapper new LambdaQueryWrapper(); wrapper.eq(roomTypeId ! null, RoomInfo::getRoomTypeId, roomTypeId) .like(StringUtils.hasText(keyword), RoomInfo::getRoomNo, keyword) .orderByAsc(RoomInfo::getPrice); return roomInfoMapper.selectPage(new Page(page, pageSize), wrapper); }这里eq的第一个参数是布尔条件只有roomTypeId不为空时才拼接该条件like同理关键字为空就不做模糊查询。这样一套代码可以覆盖列表页所有筛选场景不需要单独写多个 SQL。小程序端首页如果要做“精选房型”可以加一个recommend字段列表接口多一个排序规则。3.3 购物车与食物订单状态流转从“加入”到“已支付”购物车单独建表核心字段是user_id、food_id、count。加入购物车时先查是否已有记录有则数量加一没有则插入。提交购物车后把cart_item中的数据批量生成food_order数据同时清空购物车。食物订单的status我定义为0 待支付1 已支付待配送2 已完成3 已取消。小程序端“我的”页面直接按状态分组显示。管理员端处理食物订单时只需要改status字段不需要动其他表。这里要注意的是购物车提交和订单生成必须放在同一个事务里否则可能出现购物车清了订单没生成的脏数据。用 SpringTransactional标注 Service 方法即可下面第四章有具体代码。3.4 房间订单预订要考虑的日期冲突与价格计算房间订单与食物订单最大的不同是必须校验时间段不能出现同一房间同一时间段被重复预订。校验 SQL 是查重叠区间SELECT COUNT(*) FROM room_order WHERE room_id #{roomId} AND status IN (0, 1) AND checkin_date #{endDate} AND checkout_date #{startDate}大于 0 就说明有重叠直接返回错误。价格计算则要区分订金和总价论文里提到的字段包括订金、预订天数、总价格。通常做法是总价格 房间单价 * 入住天数订金单独存一个字段支付时先付订金到店再补尾款。小程序详情页展示的是总价下单页要拆开列清楚避免用户投诉。3.5 管理员后台新闻、房型、订单的统一 CRUD 套路后台管理模块虽然功能多但本质是一套分页 增删改查。可以把“列表、新增、编辑、删除”做成一个通用的 BaseController子类继承后自动获得这几个方法。参数上列表接口统一使用page、pageSize、keyword三个参数返回结果包含total和records。参数类型必填说明pageInteger否页码默认 1pageSizeInteger否每页条数默认 10keywordString否模糊搜索关键字具体字段由子类定义roomTypeIdInteger否房型筛选仅房间列表使用管理员修改新闻、食物、房型时增加/更新操作都走同一个saveOrUpdate方法减少重复代码。删除操作要注意外键约束比如删房型前先查room_info有没有关联房间有关联就提示“该房型下存在房间无法删除”。4. 代码落地预订模块的 Service 层与房间订单的排坑细节4.1 订单创建的代码骨架事务与日期校验创建房间订单是所有功能里最需要小心的涉及用户、房间、订单三张表还要求数据一致性。我把核心逻辑写在 Service 实现类里Transactional(rollbackFor Exception.class) public RoomOrder createOrder(CreateOrderParam param) { // 1. 校验房间存在且可预订 RoomInfo room roomInfoMapper.selectById(param.getRoomId()); if (room null || room.getStatus() ! 1) { throw new BusinessException(房间不可预订); } // 2. 校验日期区间不能重叠 Integer overlapCount roomOrderMapper.countOverlap( param.getRoomId(), param.getStartDate(), param.getEndDate()); if (overlapCount 0) { throw new BusinessException(该时间段已被预订); } // 3. 计算价格单价 * 天数 long days ChronoUnit.DAYS.between(param.getStartDate(), param.getEndDate()); if (days 0) { throw new BusinessException(入住日期不合法); } BigDecimal totalPrice room.getPrice() .multiply(BigDecimal.valueOf(days)); // 4. 生成订单号并插入 RoomOrder order new RoomOrder(); order.setOrderNo(generateOrderNo(param.getUserId())); order.setUserId(param.getUserId()); order.setRoomId(param.getRoomId()); order.setCheckinDate(param.getStartDate()); order.setCheckoutDate(param.getEndDate()); order.setTotalPrice(totalPrice); order.setStatus(0); roomOrderMapper.insert(order); return order; }这段代码逻辑按步骤拆成四段Transactional保证校验、插入、更新在同一个事务里中间任何一步抛异常都会整体回滚。ChronoUnit.DAYS.between是计算日期差的标准写法注意LocalDate类型不要用getTime()除毫秒数容易踩时区坑。BusinessException是自定义异常统一被全局异常处理器捕获后转成Result.error()返回。4.2 防止重复下单订单号唯一索引的作用前端用户手快连点两次“提交”后端可能创建两条重复订单。纯用status判断拦不住这种并发请求我用的方案是在room_order表上给order_no建唯一索引下单时generateOrderNo按“时间戳 用户ID”生成这样同一用户在极短时间内的请求会生成不同订单号但真正要防的是同一订单内容重复入库。更严格的做法是增加一个biz_key字段用userId roomId startDate endDate做唯一索引。第一次插入成功第二次插入时 MySQL 会报DuplicateKeyException在 Service 里捕获该异常并返回“订单已存在请勿重复提交”这个方法比加分布式锁简单得多适合毕业设计和小并发场景。4.3 多表联查与分页MyBatis Plus 的条件构造器房间订单列表页通常需要显示用户名、房号、房型名称这就要求room_order联查sys_user和room_info。我的做法是先分页查主表再补查关联数据避免写复杂的嵌套子查询public PageRoomOrderVO pageOrderVO(Integer page, Integer pageSize, Integer status) { LambdaQueryWrapperRoomOrder wrapper new LambdaQueryWrapper(); wrapper.eq(status ! null, RoomOrder::getStatus, status) .orderByDesc(RoomOrder::getCreateTime); PageRoomOrder orderPage roomOrderMapper.selectPage(new Page(page, pageSize), wrapper); // 收集 userId 和 roomId用 in 查询一次性取回 ListInteger userIds orderPage.getRecords().stream() .map(RoomOrder::getUserId).distinct().collect(Collectors.toList()); ListInteger roomIds orderPage.getRecords().stream() .map(RoomOrder::getRoomId).distinct().collect(Collectors.toList()); MapInteger, String userMap userService.selectNamesByIds(userIds); MapInteger, String roomMap roomService.selectRoomNosByIds(roomIds); // 组装VO返回给前端 ListRoomOrderVO voList orderPage.getRecords().stream().map(order - { RoomOrderVO vo new RoomOrderVO(); BeanUtils.copyProperties(order, vo); vo.setUserName(userMap.get(order.getUserId())); vo.setRoomNo(roomMap.get(order.getRoomId())); return vo; }).collect(Collectors.toList()); PageRoomOrderVO result new Page(orderPage.getCurrent(), orderPage.getSize(), orderPage.getTotal()); result.setRecords(voList); return result; }这里没有用 Mapper 里的自定义 join而是在内存里做关联因为订单表分页后每页最多 10 条in查询的开销远小于复杂 join。参数说明page是当前页pageSize是每页大小status空值表示查询全部状态。这样写的好处是后续加缓存也方便直接对selectNamesByIds做 Redis 缓存即可。4.4 真机调试请求不到后端三个常见原因微信开发者工具里模拟器请求本地接口正常但真机预览时请求失败基本是三个原因。第一BASE_URL写了localhost真机上 localhost 是手机自己要改成电脑的局域网 IP。第二没有在开发者工具里勾选“不校验合法域名”开发阶段可以在“详情-本地设置”里打开。第三后端服务没有监听0.0.0.0SpringBoot 默认监听所有网卡但可能被防火墙挡住记得开放 8080 端口。提示真机调试时请求失败先看手机和电脑是否在同一 Wi-Fi再在电脑命令行执行ipconfigWindows或ifconfigmacOS确认 IP 没写错。项目上线后就不能再用 IP 地址需要配备案域名并在小程序后台添加合法域名。4.5 前端调用参数与后端接收的对应关系小程序端提交订单时表单字段较多建议前端统一使用POST后端用RequestBody接收。前端传参要特别注意checkinDate和checkoutDate的格式Java 侧如果使用LocalDate默认序列化格式是yyyy-MM-dd前端必须保证同格式否则会报反序列化错误。我通常在小程序端用dayjs统一格式化避免手动拼字符串。// pages/room/detail.js const params { userId: wx.getStorageSync(userId), roomId: roomId, startDate: 2024-06-01, endDate: 2024-06-03 } request(/api/roomOrder/create, POST, params).then(res { wx.navigateTo({ url: /pages/order/detail?id${res.id} }) })对应后端CreateOrderParam里用NotBlank校验日期字符串再在 Service 里转换成LocalDate。前端传参后可以先console.log看看格式后端日志也打印一遍两边对上再往下走。5. 上线前的检查清单切换基础库版本与边界场景处理5.1 控制包体大小2M 限制与分包策略微信小程序主包不能超过 2M图片尽量全部放到服务器只在小程序里保存压缩后的 URL。如果功能模块太多可以在app.json里配置分包比如pages/admin/*全部挪到subpackages/admin下这样主包体积能显著下降。5.2 设置基础库版本与顶部导航栏高度开发时遇到“组件找不到”或 API 不生效多半是基础库版本太低。在app.json中显式声明libVersion: 3.0.0或更高统一团队开发环境。顶部导航栏的胶囊位置在不同机型上不同不要写死statusBarHeight用wx.getMenuButtonBoundingClientRect()动态计算导航栏高度并在onResize里重新获取。5.3 后端接口的边界与异常提示管理员删除用户前检查该用户有没有未完成订单删除房型前检查是否有房间引用。订单状态更新用条件更新比如从“待支付”改为“已支付”时SQL 强制加上WHERE status 0防止把已完成的订单改回去。前端对每个按钮加 loading 状态避免重复点击。5.4 用邻近日期作为测试用例房间预订测试不要只用一个测试日期用“今天入住、明天退房”“跨月入住”“退房日期早于入住日期”三种用例分别跑一遍能发现ChronoUnit.DAYS.between和 SQL 时间边界处理不一致的问题。下单后再打开该房间详情页确认可用状态已经变化这就是一个完整闭环的验证方式。最后的建议是这个项目虽然叫“酒店管理系统”真正评审的重点往往不在酒店业务本身而在你是否把“状态管理”和“数据一致性”讲清楚。把 4.2 节的唯一索引、4.4 节的日期重叠校验以及订单状态流转弄明白面试官问任何一个分支你都有实际代码兜底。验证时也可以故意开两个窗口同时点同一个房间的预订如果第二次返回“该时间段已被预订”说明你的并发处理逻辑已经生效。本文还有配套的精品资源点击获取 微信小程序酒店管理系统开发：SpringBoot后端与MySQL订单状态设计全解析
简介毕业设计论文《基于微信小程序的酒店管理系统》围绕酒店管理系统的设计与实现展开面向计算机相关专业毕业生及需要完成毕业设计论文的学生。内容涵盖系统需求分析、技术选型、功能模块设计、数据库设计、系统测试等完整流程重点论述用户管理、公告信息、新闻资讯、食物与房间订单、房型管理等模块并结合Springboot框架、Java技术、MySQL数据库及微信小程序开发者工具进行了详细剖析有助于理解前后端分离开发模式和小程序项目落地思路。资源包共1个文件为docx格式论文正文压缩包大小约3.77MB结构清晰、章节完整可直接参考其目录组织、论述逻辑和排版格式。目前已有166人学习浏览适合作为毕业论文撰写、开题准备及系统开发实践的参考资料。1. 小程序酒店管理系统不是套壳应用是一整条业务流水线“基于微信小程序的酒店管理系统”听起来像是一个标准 CRUD 课题但真正动手后会发现它横跨三条线小程序端的页面与渲染、SpringBoot 后端接口、MySQL 数据表设计中间还要处理房间预订、食物订单、用户状态这些交叉业务。我当初用 IoT 设备项目练手惯了以为这类系统两三天能拼出来结果光是一个房间订单的日期冲突就改了三版。这篇想把这套系统从需求到落地的全过程拆开讲包括前端小程序项目的目录组织、后端接口规划、订单状态机设计、MySQL 表拆分以及真机调试时最容易卡住的几个点。适合正在做类似毕业设计或者打算拿小程序项目练手但不想只做静态页面的开发者。2. 工程结构拆解SpringBoot 与微信小程序端各自该管什么2.1 B/S 架构下的小程序不是浏览器页面很多论文会把这类系统归到 B/S 架构但从运行角度讲微信小程序更像“客户端容器 远程服务”。微信开发者工具负责编译和预览真正的逻辑运行在用户微信中页面内容则通过wx.request与 SpringBoot 后端通信。选择 B/S 的核心理由是小程序端不需要安装、不需要关注后端部署方式所有业务状态都收敛到服务端这样房间、订单、新闻这些数据才能被管理员和用户共享。请求链路上典型流程是小程序Page触发事件 →setData控制视图状态 → 调用utils/request.js里的封装方法 → 发送 HTTP 请求到 SpringBoot Controller → Controller 转给 Service → Service 调用 Mapper → 返回统一结构给小程序渲染。这个链路里后端只关心接口契约前端只关心渲染和交互调试时哪一段出问题可以立刻通过控制台定位。2.2 小程序目录与逻辑层、视图层微信开发者工具创建的项目目录结构固定app.js是全局逻辑app.json注册页面和窗口样式pages/下每个页面由.wxml、.wxss、.js、.json四个文件组成。以本项目为例我习惯把pages/index/放首页、pages/room放房间列表、pages/order放订单页再单独建一个utils/request.js做请求封装。// utils/request.js 对 wx.request 做一层封装避免每个页面重复写 url const BASE_URL http://localhost:8080 function request(path, method, data) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL path, method: method || GET, data: data || {}, header: { Content-Type: application/json }, success: (res) { if (res.statusCode 200 res.data.code 200) { resolve(res.data.data) } else { wx.showToast({ title: res.data.msg || 请求失败, icon: none }) reject(res) } }, fail: (err) reject(err) }) }) } module.exports { request, BASE_URL }这段封装的核心作用是把异常和业务状态码统一处理掉。页面里调用时不需要关心statusCode和code的区别只管返回数据。注意BASE_URL在开发阶段用本地局域网 IP 时需要在微信开发者工具里勾选“不校验合法域名”否则请求会被拦截。小程序的逻辑层和视图层是分离的逻辑层改数据不会直接操作 DOM必须通过setData把数据传给视图层。这一点比 Vue 的响应式更“笨”一些但好处是数据流清晰调试时只要看setData前后数据变化就能定位问题。2.3 SpringBoot 后端分层与统一响应体后端我用的分层是 Controller、Service、Mapper、Entity 四层。Controller 只做参数接收和路由Service 写业务逻辑Mapper 直接对应 MySQL 查询。为了让小程序端判断结果更简单定义一个统一响应体// common/Result.java public class ResultT { private Integer code; private String msg; private T data; public static T ResultT success(T data) { ResultT r new Result(); r.code 200; r.msg success; r.data data; return r; } public static T ResultT error(String msg) { ResultT r new Result(); r.code 500; r.msg msg; return r; } }对应的 Controller 方法签名可以统一成Result返回例如房间列表接口RestController RequestMapping(/api/room) public class RoomController { Resource private RoomService roomService; GetMapping(/list) public ResultListRoomInfo list(RequestParam(defaultValue 1) Integer page, RequestParam(defaultValue 10) Integer pageSize) { return Result.success(roomService.pageRooms(page, pageSize)); } }统一响应体的好处是前端request.js只需要解析一层data不需要每个接口单独做状态判断。实际写的时候我习惯把page和pageSize都带上默认值避免小程序端传参不完整导致空指针。2.4 数据库设计6 张核心表与关联关系这个系统的业务模块比较多但拆开看核心还是围绕用户、房间、食物、订单四类数据。从论文里的功能需求看至少要这些表表名核心字段职责sys_userid, username, password, nickname, avatar, role管理员和普通用户共用一张表用 role 区分room_typeid, type_name, bed_num, area, price房型管理与房间是一对多room_infoid, room_no, room_type_id, image, status房间基础信息status 标记可预订/入住/维护room_orderid, order_no, user_id, room_id, checkin_date, checkout_date, total_price房间订单一个订单对应一个房间food_infoid, food_name, price, image, category_id食物信息供点餐使用cart_itemid, user_id, food_id, count购物车表提交后创建食物订单sys_user同时接待管理员和用户靠role字段区分能少一张表但对接口鉴权要求更高。room_order是整张数据库设计里最关键的表user_id和room_id是两个外键checkin_date与checkout_date用于日期冲突判断。实际建表时我给room_order加了order_no唯一索引既能做订单号查询也能天然防止重复插入。3. 从注册到预订核心模块的接口设计与参数说明3.1 注册登录账号密码与 wx.login 的选择论文里说的是账号密码注册登录但小程序真正的生态会更倾向于wx.login获取code然后后端拿code加appid、secret换openid。我的做法是两条逻辑并存新用户先用账号密码注册绑定手机号登录时如果检测到微信已授权就调用wx.login静默登录后端根据openid关联用户。// pages/login/login.js wx.login({ success: (res) { wx.request({ url: http://localhost:8080/api/user/loginByWx, method: POST, data: { code: res.code }, success: (resp) { const token resp.data.data.token wx.setStorageSync(token, token) } }) } })后端拿到code后调用微信接口换openid再查sys_user表查不到就自动注册一个账号。这样做的好处是用户无感知登录但注意secret必须放在后端不能出现在小程序代码里。如果只是毕业设计演示账号密码登录其实更直观评审时也容易说清楚。3.2 房间信息查询动态列表与详情房间列表需要支持按房型筛选、按价格排序、分页查询。用 MyBatis Plus 的LambdaQueryWrapper做动态条件非常简单public PageRoomInfo pageRooms(Integer page, Integer pageSize, Integer roomTypeId, String keyword) { LambdaQueryWrapperRoomInfo wrapper new LambdaQueryWrapper(); wrapper.eq(roomTypeId ! null, RoomInfo::getRoomTypeId, roomTypeId) .like(StringUtils.hasText(keyword), RoomInfo::getRoomNo, keyword) .orderByAsc(RoomInfo::getPrice); return roomInfoMapper.selectPage(new Page(page, pageSize), wrapper); }这里eq的第一个参数是布尔条件只有roomTypeId不为空时才拼接该条件like同理关键字为空就不做模糊查询。这样一套代码可以覆盖列表页所有筛选场景不需要单独写多个 SQL。小程序端首页如果要做“精选房型”可以加一个recommend字段列表接口多一个排序规则。3.3 购物车与食物订单状态流转从“加入”到“已支付”购物车单独建表核心字段是user_id、food_id、count。加入购物车时先查是否已有记录有则数量加一没有则插入。提交购物车后把cart_item中的数据批量生成food_order数据同时清空购物车。食物订单的status我定义为0 待支付1 已支付待配送2 已完成3 已取消。小程序端“我的”页面直接按状态分组显示。管理员端处理食物订单时只需要改status字段不需要动其他表。这里要注意的是购物车提交和订单生成必须放在同一个事务里否则可能出现购物车清了订单没生成的脏数据。用 SpringTransactional标注 Service 方法即可下面第四章有具体代码。3.4 房间订单预订要考虑的日期冲突与价格计算房间订单与食物订单最大的不同是必须校验时间段不能出现同一房间同一时间段被重复预订。校验 SQL 是查重叠区间SELECT COUNT(*) FROM room_order WHERE room_id #{roomId} AND status IN (0, 1) AND checkin_date #{endDate} AND checkout_date #{startDate}大于 0 就说明有重叠直接返回错误。价格计算则要区分订金和总价论文里提到的字段包括订金、预订天数、总价格。通常做法是总价格 房间单价 * 入住天数订金单独存一个字段支付时先付订金到店再补尾款。小程序详情页展示的是总价下单页要拆开列清楚避免用户投诉。3.5 管理员后台新闻、房型、订单的统一 CRUD 套路后台管理模块虽然功能多但本质是一套分页 增删改查。可以把“列表、新增、编辑、删除”做成一个通用的 BaseController子类继承后自动获得这几个方法。参数上列表接口统一使用page、pageSize、keyword三个参数返回结果包含total和records。参数类型必填说明pageInteger否页码默认 1pageSizeInteger否每页条数默认 10keywordString否模糊搜索关键字具体字段由子类定义roomTypeIdInteger否房型筛选仅房间列表使用管理员修改新闻、食物、房型时增加/更新操作都走同一个saveOrUpdate方法减少重复代码。删除操作要注意外键约束比如删房型前先查room_info有没有关联房间有关联就提示“该房型下存在房间无法删除”。4. 代码落地预订模块的 Service 层与房间订单的排坑细节4.1 订单创建的代码骨架事务与日期校验创建房间订单是所有功能里最需要小心的涉及用户、房间、订单三张表还要求数据一致性。我把核心逻辑写在 Service 实现类里Transactional(rollbackFor Exception.class) public RoomOrder createOrder(CreateOrderParam param) { // 1. 校验房间存在且可预订 RoomInfo room roomInfoMapper.selectById(param.getRoomId()); if (room null || room.getStatus() ! 1) { throw new BusinessException(房间不可预订); } // 2. 校验日期区间不能重叠 Integer overlapCount roomOrderMapper.countOverlap( param.getRoomId(), param.getStartDate(), param.getEndDate()); if (overlapCount 0) { throw new BusinessException(该时间段已被预订); } // 3. 计算价格单价 * 天数 long days ChronoUnit.DAYS.between(param.getStartDate(), param.getEndDate()); if (days 0) { throw new BusinessException(入住日期不合法); } BigDecimal totalPrice room.getPrice() .multiply(BigDecimal.valueOf(days)); // 4. 生成订单号并插入 RoomOrder order new RoomOrder(); order.setOrderNo(generateOrderNo(param.getUserId())); order.setUserId(param.getUserId()); order.setRoomId(param.getRoomId()); order.setCheckinDate(param.getStartDate()); order.setCheckoutDate(param.getEndDate()); order.setTotalPrice(totalPrice); order.setStatus(0); roomOrderMapper.insert(order); return order; }这段代码逻辑按步骤拆成四段Transactional保证校验、插入、更新在同一个事务里中间任何一步抛异常都会整体回滚。ChronoUnit.DAYS.between是计算日期差的标准写法注意LocalDate类型不要用getTime()除毫秒数容易踩时区坑。BusinessException是自定义异常统一被全局异常处理器捕获后转成Result.error()返回。4.2 防止重复下单订单号唯一索引的作用前端用户手快连点两次“提交”后端可能创建两条重复订单。纯用status判断拦不住这种并发请求我用的方案是在room_order表上给order_no建唯一索引下单时generateOrderNo按“时间戳 用户ID”生成这样同一用户在极短时间内的请求会生成不同订单号但真正要防的是同一订单内容重复入库。更严格的做法是增加一个biz_key字段用userId roomId startDate endDate做唯一索引。第一次插入成功第二次插入时 MySQL 会报DuplicateKeyException在 Service 里捕获该异常并返回“订单已存在请勿重复提交”这个方法比加分布式锁简单得多适合毕业设计和小并发场景。4.3 多表联查与分页MyBatis Plus 的条件构造器房间订单列表页通常需要显示用户名、房号、房型名称这就要求room_order联查sys_user和room_info。我的做法是先分页查主表再补查关联数据避免写复杂的嵌套子查询public PageRoomOrderVO pageOrderVO(Integer page, Integer pageSize, Integer status) { LambdaQueryWrapperRoomOrder wrapper new LambdaQueryWrapper(); wrapper.eq(status ! null, RoomOrder::getStatus, status) .orderByDesc(RoomOrder::getCreateTime); PageRoomOrder orderPage roomOrderMapper.selectPage(new Page(page, pageSize), wrapper); // 收集 userId 和 roomId用 in 查询一次性取回 ListInteger userIds orderPage.getRecords().stream() .map(RoomOrder::getUserId).distinct().collect(Collectors.toList()); ListInteger roomIds orderPage.getRecords().stream() .map(RoomOrder::getRoomId).distinct().collect(Collectors.toList()); MapInteger, String userMap userService.selectNamesByIds(userIds); MapInteger, String roomMap roomService.selectRoomNosByIds(roomIds); // 组装VO返回给前端 ListRoomOrderVO voList orderPage.getRecords().stream().map(order - { RoomOrderVO vo new RoomOrderVO(); BeanUtils.copyProperties(order, vo); vo.setUserName(userMap.get(order.getUserId())); vo.setRoomNo(roomMap.get(order.getRoomId())); return vo; }).collect(Collectors.toList()); PageRoomOrderVO result new Page(orderPage.getCurrent(), orderPage.getSize(), orderPage.getTotal()); result.setRecords(voList); return result; }这里没有用 Mapper 里的自定义 join而是在内存里做关联因为订单表分页后每页最多 10 条in查询的开销远小于复杂 join。参数说明page是当前页pageSize是每页大小status空值表示查询全部状态。这样写的好处是后续加缓存也方便直接对selectNamesByIds做 Redis 缓存即可。4.4 真机调试请求不到后端三个常见原因微信开发者工具里模拟器请求本地接口正常但真机预览时请求失败基本是三个原因。第一BASE_URL写了localhost真机上 localhost 是手机自己要改成电脑的局域网 IP。第二没有在开发者工具里勾选“不校验合法域名”开发阶段可以在“详情-本地设置”里打开。第三后端服务没有监听0.0.0.0SpringBoot 默认监听所有网卡但可能被防火墙挡住记得开放 8080 端口。提示真机调试时请求失败先看手机和电脑是否在同一 Wi-Fi再在电脑命令行执行ipconfigWindows或ifconfigmacOS确认 IP 没写错。项目上线后就不能再用 IP 地址需要配备案域名并在小程序后台添加合法域名。4.5 前端调用参数与后端接收的对应关系小程序端提交订单时表单字段较多建议前端统一使用POST后端用RequestBody接收。前端传参要特别注意checkinDate和checkoutDate的格式Java 侧如果使用LocalDate默认序列化格式是yyyy-MM-dd前端必须保证同格式否则会报反序列化错误。我通常在小程序端用dayjs统一格式化避免手动拼字符串。// pages/room/detail.js const params { userId: wx.getStorageSync(userId), roomId: roomId, startDate: 2024-06-01, endDate: 2024-06-03 } request(/api/roomOrder/create, POST, params).then(res { wx.navigateTo({ url: /pages/order/detail?id${res.id} }) })对应后端CreateOrderParam里用NotBlank校验日期字符串再在 Service 里转换成LocalDate。前端传参后可以先console.log看看格式后端日志也打印一遍两边对上再往下走。5. 上线前的检查清单切换基础库版本与边界场景处理5.1 控制包体大小2M 限制与分包策略微信小程序主包不能超过 2M图片尽量全部放到服务器只在小程序里保存压缩后的 URL。如果功能模块太多可以在app.json里配置分包比如pages/admin/*全部挪到subpackages/admin下这样主包体积能显著下降。5.2 设置基础库版本与顶部导航栏高度开发时遇到“组件找不到”或 API 不生效多半是基础库版本太低。在app.json中显式声明libVersion: 3.0.0或更高统一团队开发环境。顶部导航栏的胶囊位置在不同机型上不同不要写死statusBarHeight用wx.getMenuButtonBoundingClientRect()动态计算导航栏高度并在onResize里重新获取。5.3 后端接口的边界与异常提示管理员删除用户前检查该用户有没有未完成订单删除房型前检查是否有房间引用。订单状态更新用条件更新比如从“待支付”改为“已支付”时SQL 强制加上WHERE status 0防止把已完成的订单改回去。前端对每个按钮加 loading 状态避免重复点击。5.4 用邻近日期作为测试用例房间预订测试不要只用一个测试日期用“今天入住、明天退房”“跨月入住”“退房日期早于入住日期”三种用例分别跑一遍能发现ChronoUnit.DAYS.between和 SQL 时间边界处理不一致的问题。下单后再打开该房间详情页确认可用状态已经变化这就是一个完整闭环的验证方式。最后的建议是这个项目虽然叫“酒店管理系统”真正评审的重点往往不在酒店业务本身而在你是否把“状态管理”和“数据一致性”讲清楚。把 4.2 节的唯一索引、4.4 节的日期重叠校验以及订单状态流转弄明白面试官问任何一个分支你都有实际代码兜底。验证时也可以故意开两个窗口同时点同一个房间的预订如果第二次返回“该时间段已被预订”说明你的并发处理逻辑已经生效。本文还有配套的精品资源点击获取