C++酒店点菜系统实战：状态机与数据持久化设计

简介一份基于C的酒店点菜系统完整源码包面向需要完成课程设计或实训项目的计算机相关专业学生以及希望了解餐饮管理系统核心模块的开发者。资源围绕权限管理、点餐管理、订单管理、结账管理和菜谱评分等功能展开代码结构清晰适合学习面向对象设计、链表数组存储、事件驱动编程等知识点。包内共19个文件包含4个cpp源文件、3个头文件和1个exe可执行程序以及txt说明文档和Code::Blocks工程文件等压缩包大小297KB便于直接查看工程结构或运行体验。该系统已吸引1808人下载学习具有一定参考价值。通过阅读源码和文档可快速掌握角色权限控制、菜品数据组织、订单状态转换等实现思路也能为后续扩展支付接口或图形界面提供基础。整体而言这是一份紧凑实用的C综合实训资料。1. C 酒店点菜系统难的不是点菜而是状态与不丢数据一个能把点菜、加菜、退菜、结算、库存都跑通并且程序重启后数据还在的酒店点菜系统是很多 C 初学者的目标也常是课程设计里最容易翻车的项目。表面上看它不过是一堆 cout 和 cin真正写起来你会发现难点全藏在“订单有状态”和“数据不丢”这两件事上。柜台后面坐着的收银员最怕的不是客人点菜慢而是单子状态乱了或者程序一崩菜品文件变成空文件。这篇文章按我实际做过的方案从类设计讲到能跑的完整流程代码可以直接抄但想清楚为什么这样设计比抄代码更重要。适合准备写课程设计、期末大作业或者想把手里的控制台项目升级得能见人的开发者。2. 先把系统拆出四个边界菜品、订单、存储、界面2.1 类职责怎么分决定了后面改需求时会不会推倒重来我一般不会一上来就写 main 里的 switch而是先把系统拆成四块菜品数据、订单数据、文件存储、交互界面。这样的拆分源于一个很朴素的理由酒店点菜系统的需求变化极快今天要加菜品分类明天要打折扣后天可能要把控制台版换成带界面的版本。如果所有逻辑都堆在 main 里任何一个改动都可能碰坏一大片代码。菜品数据对应 Dish 结构体包含编号、名称、单价、库存、分类。订单数据对应 Order 和 OrderItemOrderItem 记录点菜时的那一瞬间价格快照而不是去菜单表里现查价。存储单独拎出一个 Menu 类和 OrderManager 类分别负责菜品文件和订单文件的读写。界面层只做一件事接收输入、显示结果不直接改文件。这样划分以后测试某一段逻辑不用从头跑一遍交互流程。模块负责的事不应该做的事Dish 结构体存一道菜的静态信息与库存写文件、计算订单金额OrderItem 结构体存订单里一行菜的数量与价格快照修改库存Order 结构体存一桌的菜、状态、桌号读写文件Menu 类菜品增删改查、加载与保存处理订单OrderManager 类点菜、退菜、下单、结算直接操作菜品文件2.2 数据结构选型vector 与 enum 为什么够用很多教程一上来就让你写单链表存菜单理由是“链表能展示指针用法”。但真实项目里菜单是需要按编号查找、随机访问的vector 天然支持下标访问排序也方便。链表唯一的好处是中间插入快而点菜系统几乎没有中间插入菜品的需求新菜永远追加在末尾删除也只是逻辑上标记停售。所以我选择 vector 存菜品和订单把链表留给作业题。订单状态我用 enum 而不是字符串这是最容易忽略又最容易翻车的地方。字符串“已下单”和“已结算”在控制台打印时看不出区别一旦代码里写成 if (order.status 已下单)手一抖拼错字整个判断就静默失效。enum 有编译期检查编译器会直接报错。状态机是订单模块的灵魂流程是开台 OPENED → 下单 PLACED → 结算 SETTLED以及一个备用的 CANCELLED 作废状态。每个状态转换点都必须校验当前状态这个习惯能挡住后续绝大部分逻辑漏洞。#ifndef ORDER_H #define ORDER_H #include string #include vector // 订单状态机OPENED 可增删菜PLACED 锁定SETTLED 不可再动 enum class OrderStatus { OPENED, PLACED, SETTLED, CANCELLED }; // 订单里的一行菜价格在点菜时快照保存 struct OrderItem { int dishCode 0; std::string dishName; // 冗余字段打印小票时不用再查菜单 long priceInCents 0; // 单位分避免浮点误差 int quantity 0; }; struct Order { int tableNo 0; int seq 0; // 同一桌的订单序号防止覆盖 OrderStatus status OrderStatus::OPENED; std::vectorOrderItem items; }; #endif这段代码里最值得留意的两个点是 seq 和 priceInCents。seq 是同一张桌子的订单序号客人吃完一桌再翻台新订单不是覆盖旧订单而是 seq 加一历史记录还能查。价格快照则意味着即使之后菜单改价已经点的菜依然按点菜时的价格结算这是收银系统的基本要求。2.3 文件格式设计分隔符与编码的选择菜品和订单都要落盘我建议菜单用文本文件订单用追加日志不要混成一种格式。文本文件的好处是可以用文本编辑器直接打开查看、修复这对调试非常重要。文件里一行一道菜字段用竖线 | 分隔而不是逗号原因是菜品名里可能出现“招牌、红烧肉”这样带逗号的字符串竖线几乎不会出现在菜名里。编码方面我踩过比较大的坑是 Windows 控制台的 GBK 与源文件 UTF-8 混在一起显示乱码。建议统一约定源代码文件存 UTF-8程序运行时在 main 开头设置控制台输出代码页。Linux 和 macOS 的终端默认 UTF-8基本不用管。保存文件时也明确写 UTF-8不能让不同人的机器生成不同编码的菜品文件。3. 菜品管理与文件加载菜单从“写死数组”变成可维护数据3.1 菜谱文件格式与加载函数先看文件长什么样。我习惯在程序目录下建一个 data 文件夹里面放 dishes.txt第一行是版本号后面是菜品记录。版本号是给以后迁移用的程序先读第一行不认识的高版本号就提示“数据文件版本过高请升级程序”而不是直接解析出一堆乱数据。#VERSION 1 1001|口水鸡|2800|50|凉菜 1002|宫保鸡丁|3200|40|热菜 1003|米饭|200|200|主食 1004|鲜榨西瓜汁|1500|30|酒水字段从左到右依次是菜号、菜名、单价单位分、库存单位份、分类。价格用分而不是元是因为浮点数在计算金额时会出 0.10.2 不等于 0.3 这种问题收银系统一分钱都不能差。加载函数用 getline 逐行读遇到空行和以 # 开头的行直接跳过。核心逻辑写在下面这个函数里。bool Menu::load(const std::string path) { std::ifstream in(path); if (!in.is_open()) return false; dishes_.clear(); std::string line; while (std::getline(in, line)) { // 空行与注释行直接跳过文件里偶尔有空行是正常现象 if (line.empty() || line[0] #) continue; // 按 | 分隔菜品名即使包含逗号也不会分错列 std::vectorstd::string parts; std::string part; std::stringstream ss(line); while (std::getline(ss, part, |)) { parts.push_back(part); } if (parts.size() 5) continue; // 列数不足说明这行损坏,丢弃 Dish d; try { d.code std::stoi(parts[0]); d.name parts[1]; d.priceInCents std::stol(parts[2]); d.stock std::stoi(parts[3]); d.category parts[4]; } catch (...) { continue; // 某一行解析失败不影响其他行 } dishes_.push_back(d); } return true; }这段代码里的 try/catch 是特意加的。菜品文件一旦在人工编辑时被改坏一行整张菜单就不能加载这在后厨场景里是不可接受的。我一般会容忍坏行跳过它们然后统计失败行数提示给用户看。std::stoi 遇到非数字字符会抛异常不 catch 的话程序直接退出收银台当场死机。3.2 新增菜品时的校验与保存策略新增菜品不能直接 push_back 了事。菜号必须全局唯一价格和库存不能为负数。这些校验放在 Menu::add 里而不是放在 main 的输入逻辑里目的是让任何调用方都绕不开校验。bool Menu::add(const Dish dish) { if (find(dish.code) ! nullptr) return false; // 菜号冲突直接拒绝 if (dish.priceInCents 0 || dish.stock 0) return false; dishes_.push_back(dish); return save(); // 每次变更立即落盘不给“忘记保存”留机会 }保存函数有一个容易被忽视的细节先写临时文件再调用 rename 替换原文件。如果你图省事直接打开原文件写入写了一半断电文件就残了。临时文件加 rename 是常见做法rename 在同一个目录下是原子操作要么旧文件还在要么新文件完全到位不存在中间状态。bool Menu::save(const std::string path) { std::string tmpPath path .tmp; { std::ofstream out(tmpPath); if (!out.is_open()) return false; for (const Dish d : dishes_) { out d.code | d.name | d.priceInCents | d.stock | d.category \n; } out.flush(); // 强制把缓冲区写到底层文件 } if (std::rename(tmpPath.c_str(), path.c_str()) ! 0) return false; return true; }注意我给 flush 加了一行注释。C 的 ofstream 析构时会自动 flush但是程序如果在这个作用域里抛异常析构不一定执行显式 flush 是个好习惯。另外 rename 之后原文件的旧内容就没了所以这个方案不适合做订单文件订单必须走追加写这就在数据层把“菜单覆盖保存”和“订单只增不改”分开了。3.3 修改与停售不要直接删菜品有一个常见的误用后厨今天不做某道菜于是直接把菜品从文件里删掉。这会导致历史订单里引用的菜号查不到对应菜名小票打出来变成空名。我一般会加一个 onSale 字段停售只是把状态置为 false点菜时过滤掉但订单里依然能显示历史名称。可惜很多课程设计没这个字段那就至少保留菜号与快照菜名不要在订单里只存菜号不存名字。另一个细节是库存单位。单位是“份”还是“克”必须在代码里统一。有人用 double 存克重然后发现浮点误差导致库存越扣越偏。我只用整数单位精确到“份”如果以后要做“按克称重”就把数量单位改造为 int 型毫克的快照而不是用 double 硬算。4. 点餐与结算流程状态机如何拦住重复结算和退菜乱序4.1 订单流转从开台到入账的完整链路点菜系统的核心流程可以概括为四步客人入座开台服务员点菜加菜后厨下单锁定客人结账入账。每一步都对应一个操作每个操作都必须检查当前订单状态。例如“已下单”的订单不能再加菜“已结算”的订单不能再退菜这在控制台程序里看似简单一旦写成多个函数互相调用就很容易漏掉判断。我在 OrderManager 里只维护一个 vector 每个元素是一张桌子的订单。不需要用栈或队列因为点菜系统不存在严格的先进先出需求客人可以给任意桌点菜也不存在“只能处理最早那桌”的业务规则。class OrderManager { public: Order openTable(int tableNo); // 开台新建订单 bool addItem(int tableNo, int dishCode, int qty); bool removeItem(int tableNo, int dishCode, int qty); bool placeOrder(int tableNo); // 下单锁单 bool settle(int tableNo, long paid, long* change); // 结算入账 Order* findTable(int tableNo); private: std::vectorOrder orders_; Menu* menu_; // 需要访问菜品库存注意生命周期 };openTable 时要做一件事检查这个桌号是否已有未结算订单。如果有提示先结算旧单不能直接覆盖。seq 字段在这里派上用场新订单的 seq 是旧订单最大 seq 加一保证历史记录不丢。4.2 加菜与库存扣减快照与库存必须同时更新加菜函数是订单模块里最容易写错的地方因为涉及两个数据源的联动订单行要加一条记录菜单里的库存要同步扣减。这两个动作必须放在同一个函数内完成绝不能一个在 main 里调一个在另一个函数里调那样迟早出现“订单里有菜但库存没扣”的玄学问题。bool OrderManager::addItem(int tableNo, int dishCode, int qty) { Order* order findTable(tableNo); if (order nullptr || qty 0) return false; if (order-status ! OrderStatus::OPENED) return false; // 已下单不能再加菜 Dish* dish menu_-find(dishCode); if (dish nullptr) return false; if (dish-stock qty) return false; // 库存不足直接拒绝 // 如果订单里已存在同一道菜累加数量而不是新增重复行 for (OrderItem item : order-items) { if (item.dishCode dishCode) { item.quantity qty; dish-stock - qty; return true; } } OrderItem item{dishCode, dish-name, dish-priceInCents, qty}; order-items.push_back(item); dish-stock - qty; return true; }这段代码的关键点有三个。第一状态判断放在最前面不满足条件直接返回后面所有逻辑都默认订单是 OPENED 状态。第二库存检查用的是“小于 qty”而不是“小于等于”因为等于的话刚好够卖应该放行。第三累加重复菜与新增菜分开处理避免同一道菜在订单里出现多行结算金额计算会变得极其难排查。退菜函数逻辑类似但要从相反方向思考先查订单里有没有这道菜再判断当前数量够不够退。全部退掉之后如果订单里一行菜都不剩我一般选择保留空订单而不是自动作废因为服务员可能只是打算重新点。真正作废的入口单独提供让收银员确认。4.3 结算入账老订单为什么不怕改价结算函数是状态机最后的把关闸口。它接收两个参数应收前的找零指针和实收金额。先用当前订单里每行的 priceInCents 乘以 quantity 求总额再与实收金额比较。这里再次体现价格快照的意义如果结算时去菜单表里查最新价格菜价在客人用餐期间涨了一块钱结算金额就跟着变了客人投诉跑不掉。bool OrderManager::settle(int tableNo, long paid, long* change) { Order* order findTable(tableNo); if (order nullptr) return false; // 必须已下单才能结已结算或已作废的单子不能重复入账 if (order-status ! OrderStatus::PLACED) return false; long total 0; for (const OrderItem item : order-items) { total item.priceInCents * item.quantity; } // 有折扣券可以在这里按总价计算先展示全价结算 if (paid total) return false; // 实收小于应付拒绝 *change paid - total; order-status OrderStatus::SETTLED; return true; }status 判断是重复结算问题的防火墙。我在给某开发者做代码评审时见过一次真实的翻车结算函数里没有状态判断收银员连着敲了两次回车订单金额入账了两次账目对不上。加这一行判断之后第二次调用直接返回 falseUI 层再提示“该单已结算请勿重复操作”。如果还要做更严格的防呆可以给 Order 加一个 settledAt 时间戳在界面上展示。结算完成后我习惯把整张订单输出成一个文本小票追加写入 receipts 目录下的日志文件。这个操作不参与任何金额计算纯粹为了对账。小票内容的生成函数单独写返回 std::string界面层打印文件层写入核心逻辑不碰 IO。这样以后想把小票改成二维码或发送到打印机只需替换生成函数。5. 酒店点菜系统常见踩坑与排查从乱码到订单重复入账5.1 中文乱码跑起来菜单全是“锟斤拷”现象程序在 Windows 上刚启动控制台里输出的菜单全是乱码菜品名显示成“锟斤拷”或问号。原因源代码存成 UTF-8而 Windows 控制台默认用 GBK 代码页输出两边对不上。解决在 main 最开头调用 Windows API 设置控制台输出代码页为 UTF-8或者编译时加 /utf-8 参数统一源文件编码。我在代码里一般这样写#ifdef _WIN32 #include windows.h #endif int main() { #ifdef _WIN32 SetConsoleOutputCP(CP_UTF8); SetConsoleCP(CP_UTF8); #endif // ... }Linux 和 macOS 默认 UTF-8不需要这两行。如果你用的是老式编译器不支持 /utf-8那就把源文件另存为 GBK但这样代码在 Linux 上又会乱所以我建议直接用新的编译器并统一 UTF-8。5.2 文件数据丢一半程序崩溃后菜品文件变成空文件现象程序运行中异常退出再启动时菜单全没了dishes.txt 是 0 字节或者只有半个字符。原因保存函数直接打开原文件写入写入过程中程序崩溃文件被截断。解决改成先写临时文件再 rename也就是第 3 章里 save 函数的做法。另外在每次写入后调用 flush确保数据从缓冲区进到操作系统。注意 rename 之前要确保临时文件确实写成功否则 rename 会把一个坏文件替换成另一个坏文件。5.3 同一张订单被结算两次账目翻倍现象收银员反映某桌的菜金入账多了对账时发现重复的订单记录。原因settle 函数没有检查当前状态或者 UI 层在点击结算后没有禁用按钮用户敲了两次回车。解决状态机校验是最后一层防线。我在 settle 开头加 if (order-status ! OrderStatus::PLACED) return false并把结算成功的订单状态改为 SETTLED。这样无论 UI 层怎么调用第二笔结算一定失败。UI 层收到 false 后提示“已结算”而不是继续走找零逻辑。5.4 库存扣成负数菜卖出去了但库存在涨现象菜单里某道菜的库存显示 -3但客人实际只点了两道。原因加菜时检查了库存但扣减库存和写入订单不在同一个事务里比如先扣库存后写订单失败库存就少了。另一种情况是多个入口都能扣库存逻辑重复。解决把库存扣减和订单行更新放在同一个函数里并且只允许通过 OrderManager::addItem 这一个入口。如果以后要做多线程给这个入口加一把互斥锁避免两个服务员同时为两桌客人点同一道菜各自读到库存 5各自扣减最终库存只剩 3。课程设计一般不会上多线程但这个习惯会在扩展时救你。5.5 退菜退多了订单总额变成负数现象服务员连续退同一道菜订单里数量已经退到 0还能继续退金额被减成负数。原因removeItem 里只检查“订单里有没有这道菜”没有检查“当前数量是否足够退”。解决退菜数量必须在 0 到现有数量之间数量超出时直接返回 false。更稳妥的做法是退完数量为 0 时把这一行从 items 里移除并在界面打印“该菜已退清”。我一般还会在退菜函数里记录日志谁退的、什么时候退的、退了几个这些信息对核对菜品损耗非常有用。6. 进阶技巧把核心逻辑和界面分离让点菜内核能换皮不换脑控制台点菜系统做完以后很多人想升级成带按钮的界面或者做成网页版给平板点餐用。如果前面章节已经把菜品、订单、存储各自拆开这个升级会非常顺。最核心的技巧是OrderManager 和 Menu 里不能出现任何 cout 和 cin所有输入输出全部由外层调用方传入由外部决定是打印到控制台、写到文件还是显示在图形界面上。我习惯给核心模块定义一套纯内存的数据接口UI 层只负责翻译用户操作。比如“点菜”这个动作UI 层拿到桌号和菜号调用 orderManager.addItem(tableNo, code, qty)拿到 true 就显示成功拿到 false 就显示失败原因。核心不需要知道服务员是按键盘还是点触摸屏。这样做的另一个好处是你可以写一个自动化测试脚本直接调用这些函数不用真的跑交互流程回归测试快得多。另外一个值得加的小技巧是给数据文件加版本头。我在第 3 章的 dishes.txt 里放了 #VERSION 1加载时先读版本号。以后如果增加新字段比如加一个“辣度”列就升级版本号到 2加载函数按版本走不同解析分支。旧文件依然能打开新文件在旧程序里会被拒之门外而不是解析成错乱的数据。订单日志同理每一行开头可以写时间戳和操作类型方便以后做数据迁移和分析。我个人的一个习惯是把订单状态判断统一封装成一个小函数集群比如 canAddItem(order)、canSettle(order)而不是在每个函数里重复比较 status。所有状态转换都必须经过这些守卫函数这样以后扩展“已结账订单支持部分退款”时只需要改守卫逻辑不用满文件找 if。控制台版看着简单这样写以后换界面时才不用把逻辑重写一遍。希望帮到你。本文还有配套的精品资源点击获取