简介这是一份基于C的酒店管理系统完整工程文件面向初学C或希望了解业务系统设计的开发者涵盖客房预订、入住登记、退房结算、房间状态管理等核心模块可直接用Visual Studio打开.sln文件进行编辑、编译与运行。压缩包内共27个文件约28MB主要包含main.cpp入口文件、HotelManager相关实现、Visual Studio工程配置.vcxproj/.filters/.sln以及编译调试产物.obj/.pdb/.tlog/.log等便于查看代码结构、理解构建流程并定位问题。目前已有542人学习下载适合用来练习面向对象编程、文件与工程组织以及学习如何将业务需求落地为完整C项目。通过阅读和运行源码还能了解基本的软件调试与接口设计思路是结合理论与实践的不错参考。1. 酒店管理系统完整工程文件差的是“能交付”的那部分市面上能搜到的酒店管理系统源码不少但绝大多数是单表 CRUD 的 demo房间能增删改查订单能列表分页真到部署就把人卡住——数据库没有初始化脚本上传的身份证照片存了绝对路径改个端口要翻五个配置文件。所谓“完整工程文件”指的不是代码齐全而是把系统当成能交付的产品来组织目录结构清晰、配置分环境、有建库建表与基础数据脚本、有部署说明。下面按平时交付工程的习惯把酒店管理系统从架构选型、表设计、预订入住核心闭环到迁移部署拆开讲适合做毕设、做二次开发或接手老系统的人。2. 先立架构酒店管理系统的模块边界与工程目录设计订方案之前先划边界。酒店管理系统看起来功能零碎其实业务域非常固定先把模块切清楚后面的表设计和接口才不会越写越乱。2.1 单体系统也先切模块五个业务域加一个基础域常见做法是按“客房、宾客、预订、入住、账务、系统”六个域来切即使最终打成单个 jar 包代码里也必须按这些域分包。客房域管房型和房间状态宾客域管散客、会员和协议单位预订域管订房、取消和 no-show入住域管登记、换房和续住账务域管账单与流水系统域管用户、角色和字典。酒店管理系统的复杂度不在功能数量而在状态交错——房间被预订了能不能再卖、退房了能不能立刻挂出去这些问题都得靠域之间的接口约定来约束。技术栈我一般选 Spring Boot 2.7 MyBatis-Plus MySQL 8 做后端Vue 3 Element Plus 做前端。原因是这套组合在工程文件交付场景里最通用接手的人多、问题资料全、一套 Maven 和 npm 就能把依赖锁死。个人学习换成 FastAPI 或 React 都没问题但“完整工程文件”强调交接选主流栈能省掉大量解释成本。业务域核心实体对外提供的主要能力客房域房型、房间房态查询、房态变更、维修登记宾客域宾客、会员建档、证件校验、等级折扣预订域订单预订、取消、改期入住域入住单登记、退房、换房、续住账务域账单、流水押金、结算、发票系统域用户、角色、字典登录、权限、数据字典2.2 工程目录长这样前后端分置、脚本单独放拿到一套酒店管理系统工程文件先看目录目录乱的项目代码基本也乱。我习惯按下面这个结构组织前后端分开数据库脚本单独拎出来部署文件放 deploy 目录。hotel-ms/ ├── backend/ │ ├── src/main/java/com/hotel/ │ │ ├── controller/ # 接口层只做参数校验和响应包装 │ │ ├── service/ # 业务层事务和状态流转 │ │ ├── mapper/ # 数据访问只写 SQL 和条件构造 │ │ ├── entity/ # 表映射 │ │ ├── config/ # 跨域、拦截器、上传配置 │ │ └── common/ # 统一返回、异常、工具类 │ ├── src/main/resources/ │ │ ├── application.yml │ │ ├── application-dev.yml │ │ └── application-prod.yml │ └── pom.xml ├── frontend/ │ ├── src/ │ │ ├── api/ # 接口封装 │ │ ├── views/ # 页面room、order、bill、login │ │ ├── router/ │ │ └── store/ │ └── package.json ├── db/ │ ├── init.sql # 建库建表 │ └── data.sql # 基础数据房型、房间、管理员 ├── deploy/ │ └── docker-compose.yml └── README.md这个结构里最容易被人忽略的是db目录。前端开发通常会忽略数据库脚本但接手的人第一件事就是建库。db 目录独立出来等于告诉对方“先跑这两个 SQL再看代码”。这跟 Unity 工程换电脑必须带着 ProjectSettings 目录是一个道理缺了工程配置代码再全也起不来。upload目录上传的证件照、房间图片不应该出现在 Git 里要在.gitignore中排除只保留目录本身。2.3 配置文件里的三个必调参数接手工程文件后配置文件的排查顺序基本是固定的。下面三个参数出问题的概率最高也是迁移时首先要检查的位置。参数所在文件作用常见误配spring.datasource.urlapplication-dev.yml数据库连接地址写死localhost部署到服务器后连不上server.portapplication.yml后端端口与前端代理目标不一致接口全部 404file.upload-dirconfig 包或 yml上传文件存放目录写死D:/uploadLinux 部署直接 500注意这三个参数尽量不要直接改 yml 文件推荐用${DB_HOST:127.0.0.1}这种带默认值的占位符写法让环境变量去覆盖。具体命令在第 5 章给出。3. 酒店管理系统的核心表设计预订、入住、账单的状态流转数据库是整个工程文件的地基。酒店管理系统的表不算多但两张状态表的设计直接决定并发下会不会超卖房间值得单独拿出来讲。3.1 房间状态机的五个状态位房间状态建议用两位字符编码而不是自由的英文单词。原因是前端下拉、后端枚举、报表统计都要引用同一套状态编码短且稳定字典表里维护一次就行。状态值含义进入条件可流转到01空闲初始化、打扫完成04、0502脏房退房完成0103维修报修登记0104已预订订单创建成功05、0105已入住办理入住登记02很多 demo 把“退房”直接置为“空闲”省掉了脏房状态。真实场景里退房后房间要等保洁清扫才能重新售卖这段时间是明确不可售的。省掉它前台就会把没打扫的房间卖出去这是房态控制Housekeeping里最基础的规则。同样维修中的房间要在系统里显式标记不能靠线下沟通。3.2 核心建表 SQL四张表够跑通完整闭环一个能交付的酒店管理系统最少需要房型、房间、宾客、订单四张表。下面是去掉冗余字段后的最小可用版本。CREATE TABLE t_room_type ( id bigint PRIMARY KEY AUTO_INCREMENT, name varchar(50) NOT NULL COMMENT 房型名, base_price decimal(10,2) NOT NULL COMMENT 门市价, bed_num tinyint DEFAULT 1 COMMENT 床位数, area int DEFAULT NULL COMMENT 面积(㎡), remark varchar(255), KEY idx_name (name) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT房型表; CREATE TABLE t_room ( id bigint PRIMARY KEY AUTO_INCREMENT, room_no varchar(10) NOT NULL UNIQUE COMMENT 房号, floor int DEFAULT 1, type_id bigint NOT NULL, status char(2) DEFAULT 01 COMMENT 01空闲 02脏房 03维修 04已预订 05已入住, version int DEFAULT 0 COMMENT 乐观锁防并发超卖, KEY idx_type_status (type_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT房间表; CREATE TABLE t_guest ( id bigint PRIMARY KEY AUTO_INCREMENT, name varchar(50) NOT NULL, id_card varchar(18) NOT NULL COMMENT 证件号, phone varchar(20), member_level tinyint DEFAULT 0 COMMENT 0散客 1银卡 2金卡, UNIQUE KEY uk_id_card (id_card) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT宾客表; CREATE TABLE t_order ( id bigint PRIMARY KEY AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 业务订单号, guest_id bigint NOT NULL, room_id bigint NOT NULL, check_in_date date NOT NULL, check_out_date date NOT NULL, status char(2) DEFAULT 01 COMMENT 01已预订 02已入住 03已退房 04已取消, total_amount decimal(10,2) DEFAULT 0, create_time datetime DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_order_no (order_no), KEY idx_room_date (room_id, check_in_date, check_out_date), KEY idx_guest (guest_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单表;这段 SQL 里三个设计点比较关键。t_room的version是乐观锁字段更新房态时带上WHERE version ?防止两个前台同时把同一间房卖给不同客人。uk_order_no唯一索引是订单幂等的兜底业务上即使重复提交数据库也会拒绝第二条。idx_room_date复合索引则是日期冲突查询的命脉后面查“某房间在某区间是否可订”就是扫这个索引。3.3 从预订到退房的字段流转每个环节改哪张表状态流转让初学者最晕的地方在于一个操作往往要同时改两张表而且有先后顺序。环节操作变更内容涉及表预订客户下单插入订单记录 status01房间 status 01→04t_order、t_room入住前台登记订单 status 01→02房间 04→05记录入住人证件t_order、t_room退房结算离店订单 status 02→03房间 05→02生成账单记录t_order、t_room、t_bill这里最容易做错的是退房结算时先改房态还是先改订单。常见做法是把两个更新放到同一个数据库事务里固定顺序先订单后房间再配合乐观锁。如果事务没包住就会出现订单已取消但房间还显示已预订的脏数据。账单表 t_bill 可以等核心闭环跑通后再补它按订单号挂流水字段一般是项目名称、金额、支付方式、操作人。4. 酒店管理系统最小闭环复现预订→入住→退房结算表结构定了核心闭环就是三段式可订房查询、下单、状态变更。下面按前后端分别给出可运行的代码骨架参数怎么传、校验在哪一层做一次说清。4.1 后端接口预订的幂等与时间冲突校验下单是酒店管理系统里并发风险最高的接口核心逻辑必须放在后端事务里。Transactional(rollbackFor Exception.class) public OrderVO createOrder(OrderCreateReq req) { // 1. 日期合法性入住日必须在退房日之前且不能是过去时间 if (!req.getCheckInDate().isBefore(req.getCheckOutDate())) { throw new BizException(入住日期必须早于退房日期); } // 2. 查房态该房间在目标区间内不可有未取消的订单 long conflict orderMapper.countConflict( req.getRoomId(), req.getCheckInDate(), req.getCheckOutDate(), OrderStatus.BOOKED.getCode(), OrderStatus.CHECKED_IN.getCode()); if (conflict 0) { throw new BizException(该房间在所选日期已被预订); } // 3. 生成业务单号并落库uk_order_no 唯一索引兜底并发确保幂等 Order order new Order(); order.setOrderNo(generateOrderNo(req.getRoomId())); order.setGuestId(req.getGuestId()); order.setRoomId(req.getRoomId()); order.setCheckInDate(req.getCheckInDate()); order.setCheckOutDate(req.getCheckOutDate()); order.setStatus(OrderStatus.BOOKED.getCode()); orderMapper.insert(order); // 4. 同步房态为已预订这里用条件更新做乐观锁保护 int rows roomMapper.updateStatusWithLock( req.getRoomId(), RoomStatus.AVAILABLE.getCode(), RoomStatus.RESERVED.getCode()); if (rows 0) { throw new BizException(房间状态已变化请刷新后重试); } return convert(order); }这段代码的关键参数只有四个roomId、guestId、checkInDate、checkOutDate。第 2 步的countConflict就是扫idx_room_date复合索引统计目标区间内状态为已预订或已入住的订单数量。第 4 步是整段代码的精华——updateStatusWithLock生成的 SQL 是UPDATE t_room SET status04, versionversion1 WHERE id? AND status01以“更新命中行数”作为并发冲突的判断依据比先查再更新的方案防护更严。业务单号orderNo的规则一般是“日期 房间号 四位随机数”即便生成重复唯一索引也会拦下第二条。4.2 前端页面可订房列表与参数传递前端在工程文件里的作用是把接口串成可操作的页面核心是参数不要在前端做业务判断。// 酒店管理系统 - 可订房查询与预订提交 const queryForm reactive({ checkInDate: , checkOutDate: , typeId: }) async function loadAvailableRooms() { const { data } await http.get(/api/room/available, { params: queryForm }) roomList.value data.rows } async function submitOrder(row) { const payload { roomId: row.id, // 传主键 id不传 roomNo guestId: guestStore.current.id, // 当前登录宾客 checkInDate: queryForm.checkInDate, checkOutDate: queryForm.checkOutDate } await http.post(/api/order, payload) // 后端再做一次日期校验 ElMessage.success(预订成功) loadAvailableRooms() // 刷新列表房态已变化 }一个容易忽略的细节是roomId必须传表主键而不是房号。房号在工程上允许重排和修改主键才是关联订单的稳定标识。前端这里只做展示和传参日期是否合法、房间是否可售统一由后端校验前端校验只是减少无效请求的体验优化。列表接口返回的每一行要带version字段吗不需要它对前端透明后端更新时自行读取。4.3 三个高频报错对照表报错现象根因处理方式明明有空房却订不进去可订房查询没排除脏房02和维修03查询条件收紧为status01且目标区间无未取消订单订单创建成功但房态没变更新语句没带WHERE status01把已入住的房也改了用条件更新命中行数为 0 时直接抛异常回滚退房后房间一直不释放订单和房间的更新没放在同一个事务里把订单更新和房态更新包进Transactional顺序固定先订单后房间这三类问题在接手老系统时几乎必现。定位思路是先看错误发生在哪个环节再查对应表的状态值是否符合状态机流转规则。日志里重点看事务是否回滚MyBatis 的update返回值是否被消费。5. 工程文件的“可迁移性”才是检验标准配置、初始化与上传目录判断一套酒店管理系统工程文件是否完整不看代码量看能否在另一台干净的机器上按 README 一次跑起来。这跟 C4D 工程文件换了电脑要重新链接贴图路径、剪映工程在 Windows 和 Mac 之间互导会丢素材是同一个问题工程文件的价值在于可迁移而不是在本机自娱自乐。5.1 一键初始化与配置覆盖的标准命令# 步骤1初始化数据库init.sql 建表data.sql 灌基础数据 mysql -uroot -p db/init.sql mysql -uroot -p db/data.sql # 步骤2用环境变量覆盖配置不修改任何 yml 文件 export DB_HOST10.0.0.5 DB_PORT3306 DB_NAMEhotel_prod export UPLOAD_DIR/data/hotel-ms/upload # 步骤3打包并启动后端 cd backend mvn clean package -DskipTests java -jar target/hotel-admin.jar --spring.profiles.activeprodinit.sql和data.sql分开是有意的前者只管结构后者管房型、权限、管理员账号等基础数据。升级时只替换 data.sql不影响表结构。application.yml 里用${DB_HOST:127.0.0.1}这种带默认值的占位符环境变量没配就走本地默认这条语法是配置迁移的关键。前端构建产物dist目录用 Nginx 托管反向代理/api到后端端口前端页面本身不感知环境差异。5.2 上传目录与跨系统迁移的坑上传目录是迁移时踩坑率最高的点。工程文件里绝不能出现D:\upload或/root/upload这种写死的绝对路径正确写法是file.upload-dir${UPLOAD_DIR:./upload}用相对路径兜底。Nginx 再配一个/upload/的 location 把静态图片映射出去。证件照片这类文件一旦存进 MySQL 的 BLOB 字段或打进 war 包备份体积和迁移成本都会失控文件系统存储加数据库存路径是主流方案。验收标准很简单把 backend、frontend/dist、db、deploy 四个目录拷到一台没装过 JDK 和 MySQL 的机器按 README 走一遍能起来才算完整的工程文件——迁移时十有八九卡在数据库连接或上传目录写死先把这两个变量从代码里抽出来其余配置项都只是锦上添花。本文还有配套的精品资源点击获取