做毕业设计选了沙县小吃收银系统这个题目用SpringBoot来落地听起来不太起眼但真做起来其实挺有讲究。收银系统属于典型的管理信息系统麻雀虽小五脏俱全从前端点餐界面到后端订单流转再到支付对接和营业报表一条链路走下来SpringBoot那一套核心技能点基本都能覆盖到。这篇文章就把我当时从选题、设计到编码再到最后调试上线的完整思路和经验做个梳理给准备做同类系统或者正在为毕业设计发愁的朋友一个具体可参考的路径。1. 项目整体设计与技术选型思路1.1 毕业设计选题的几个现实考量很多人觉得“沙县小吃收银系统”这个题目偏简单技术含量低我一开始也有这个顾虑。但真把需求拆开看这个题目的覆盖面和延展空间都相当可观。收银系统首先要解决的就是“点餐-结算-出餐-报表”这条核心业务链这里面牵扯到并发下单、库存扣减、订单状态流转、支付回调、数据统计这些环节。一个快餐店在不同时段的并发量虽然比不上电商大促但高峰期几十单同时进来对后端接口的响应速度和数据一致性同样有要求。另一方面选这个题目在实际答辩的时候特别好讲。沙县小吃是大家都熟悉的场景评委不需要你费劲解释业务背景你直接把桌台点餐、扫码点单、后厨出餐这个流程讲清楚所有人都能听懂。技术实现上哪怕用了很多复杂设计也能够落地到具体场景里去论证合理性这比做一个抽象的管理系统要容易得多。1.2 为什么是SpringBoot而不是其他框架SpringBoot在Java生态里早就成了事实标准选它有几个实际考量。第一是启动快、配置少相较于传统Spring MVC那套繁琐的XML配置SpringBoot的自动配置机制把大量样板工作直接省掉了。尤其对毕业设计来说时间紧、任务重如果整天折腾配置文件核心业务逻辑反而没时间打磨。第二是生态成熟SpringBoot整合MyBatis、Redis、MQ、WebSocket都有非常成熟的方案。我在设计这个项目的技术栈时核心架构如下SpringBoot 2.7.x基础框架提供依赖管理和自动配置MyBatis Plus数据持久层内置CRUD方法省掉大量Mapper XMLMySQL 8.x主数据库存储菜品、订单、用户等业务数据Redis缓存热点菜品数据、分布式锁控制并发下单、存储购物车状态WebSocket实现订单状态变更实时推送到后厨大屏和前台JWT无状态登录认证区分管理员、收银员、后厨等多类角色第三是部署方便。SpringBoot内嵌Tomcat打包成Jar包扔到服务器上就能跑。我用宝塔面板加Docker部署整个过程非常顺畅一条命令就能完成构建和启动。1.3 系统整体功能架构从功能模块角度这个系统最终分成了六个核心模块各自职责清晰、边界明确模块核心功能业务价值桌台管理桌台开台、换桌、并桌、清台模拟线下快餐店的桌台运营状态支持扫码点餐场景菜品管理菜品分类、口味规格、上下架、库存预警支撑菜单灵活调整适应日常菜品更新需求点餐下单购物车、下单、订单拆分、备注管理核心业务链路起点支持堂食、打包两种场景支付结算现金结算、微信/支付宝扫码支付、聚合支付对接完成订单闭环满足多种支付场景订单管理订单状态流转、退单、催菜、订单查询管理从下单到完成的全生命周期后厨实时同步营业报表日营收统计、菜品销量排行、时段分析辅助门店运营决策提供经营数据可视化2. 核心功能模块的详细设计2.1 点餐下单流程的设计思路点餐是收银系统的核心业务节点这里我设计了两种点餐模式。一种是传统的收银员代客点餐用户在收银台直接看菜单收银员操作下单另一种是桌台扫码点餐顾客入座后扫桌台二维码在手机上直接浏览菜单和下单。两种模式最终都会汇聚到同一套订单生成逻辑里。这里最关键的是购物车数据存储方案。最初我考虑用MySQL临时表来存购物车但后来发现频繁的增删改查会带来不小的数据库开销而且用户点餐时会出现滑动选择、修改数量这类高频操作。改用Redis来维护购物车数据后每个桌位或每个用户会话对应一个唯一key里面用Hash结构存菜品ID和数量体验好了很多也减轻了数据库压力。Redis自身的过期机制还能自动清理长时间未结算的无效购物车省去自己写定时任务。下单接口要考虑重复提交的问题。如果用户快速连点两次“提交订单”按常规操作会生成两条一模一样的订单顾客要多付一次钱。这个问题是在联调阶段发现的当时测试同学模拟了高强度点击两条订单同时落库。后来通过给下单请求加了一个前端生成的唯一请求编号后端用Redis的SETNX命令做幂等校验同一编号的请求在规定时间内只能创建一笔订单从根上解决了重复下单问题。2.2 订单状态机的合理流转设计订单状态是整个系统的业务主线状态流转设计的合理性直接影响系统后续扩展能力。我最终设计了一条从“待支付”到“已完成”的完整生命周期待支付 - 已支付 - 制作中 - 待取餐 - 已完成除了这条主流程还有两个分支状态已支付后顾客退单会进入“退款中”进而到“已退款”制作中后厨发现食材不足可以进行“拒单”操作订单直接进入“已取消”。当时设计这个状态机有一个反复推敲的地方催菜功能怎么设计。传统做法是顾客喊服务员催菜服务员口头传话到后厨。我想要在系统里实现顾客或者收银员一键“催菜”后厨大屏上对应订单高亮显示并伴随声音提醒。这需要一个中间状态“催菜中”它本质上不改变订单主流程状态只是标记了该订单存在催菜诉求。我单独加了一个order_notify表来记录催菜事件避免把业务状态搞复杂。这是实际运营中非常高频的一个需求有在这个系统里就会自然想到妥善处理的话答辩时也很加分。2.3 支付模块的实现方式与选择支付环节是收银系统里最敏感的部分。当时第一次对接的是微信官方支付接口流程相对标准但申请商户号环节比较折腾个人开发申请需要营业执照等资质。考虑到毕业设计主要做功能演示我在系统里做了一套“模拟支付网关”完整模拟了二维码生成、支付回调、订单状态变更、退款四个环节这样既能安全工作又能把整个支付流程跑通。但为了让系统具备真实落地能力我在代码层面做了接口抽象public interface PaymentService { PaymentResult createPayment(Order order); PaymentResult handleCallback(PaymentNotify notify); PaymentResult refund(Order order); }定义了统一接口后模拟支付和真实对接只需要更换实现类即可。这样设计的好处很明显答辩时跟评委解释“这是一个可替换的支付网关设计”比单纯说“我没对接真实支付”要硬气得多。模拟支付的核心逻辑是生成一个支付二维码内容顾客在收银台确认订单后系统生成随机支付流水号然后提供一个“模拟支付成功”的管理员接口触发回调方法完成订单支付状态变更。我特意在回调方法里加了签名校验的逻辑虽然现阶段校验的是本地MD5签名但对接真实支付网关时只需要换成微信的签名校验规则就行。这笔账算得过来既满足了毕设展示又保住了架构的扩展性。2.4 库存扣减与并发控制快餐店的核心矛盾是高峰期并发高。尤其是沙县小吃这类门店午餐时段可能十几个订单同时涌入如果系统库存扣减做得不好很容易出现超卖或者负库存。这个问题我在设计时就放在很重要的位置。MySQL的乐观锁方案是第一选择。菜品表加一个version字段每次扣减库存时执行这样的SQLUPDATE dish SET stock stock - #{quantity}, version version 1 WHERE id #{dishId} AND version #{oldVersion}如果数据库返回的影响行数为0说明有其他请求已经修改了这条记录当前请求需要重新读取最新库存再尝试扣减。这个方案实现简单对快餐店这种并发量级的场景完全够用。但在极端情况下乐观锁的失败重试会带来请求堆积所以我在这个基础上又加了一层Redis分布式锁。下单流程里同一个菜品的一次批量扣减操作会用Redisson的锁机制包起来锁的粒度是“菜品ID 当前订单的批次号”保证同一个菜品在高并发下不会被同时修改库存。锁超时时间设置为3秒避免某个请求持有锁时间过长影响正常业务。这两层保护配合下来压测时用JMeter模拟100个并发用户同时下单同一道招牌拌面最终库存数据依然准确没有出现负数和错乱的情况。技术方案不怕旧关键是能解决实际问题。3. 数据库设计与关键表结构解析3.1 核心数据表及字段设计数据库设计是整个系统的地基表设计得好不好直接决定后续功能开发是顺畅还是痛苦。我按照业务模块将表拆分为用户权限、菜品库存、交易订单、日志统计四组核心表如下菜品表 dishid, category_id, name, image, price, stock, unit, status, version, create_time, update_time这里有个小设计心得price字段我用了Decimal(10,2)而不是直接用Double初始开发时图省事一度用了double后来账单统计时有操作发现对不上账排查半天才发现是小数的二进制精度误差。全部改成Decimal后金额计算彻底干净。订单表 ordersid, order_no, table_id, user_id, total_amount, pay_amount, status, pay_type, remark, create_time, pay_time, finish_time表名没有用order因为order在MySQL里是关键字直接使用会带来很多SQL书写上的麻烦这是早期踩过的一个坑。订单明细表 order_itemid, order_id, dish_id, dish_name, price, quantity, amount订单明细为什么要冗余保存一份dish_name和price因为菜品价格和名称未来随时可能调整如果订单只关联dish_id事后查历史订单看到的是当前价格而不是当时的成交价格这就是一种“业务数据漂移”。冗余存储可以说是收银系统必须坚持的设计原则。桌台表 dining_tableid, table_no, seat_count, status, open_time, update_time这里status用了枚举值空闲、占用、待清理。桌台从“占用”到“空闲”不是直接切换的必须经过“待清理”状态这是当时跟门店实际运营逻辑对齐后确定的状态机。收银员结账后桌台置为“待清理”服务员打扫并确认后才恢复“空闲”。如果不加这个中间态很容易出现“顾客还没走就安排了新客入座”的运营事故。3.2 数据库索引设计与查询优化订单表的数据量在门店运营后会持续增长尤其订单明细表一天几百单很正常月积累下来就是上万条数据。查询的时候如果索引设计不合理翻历史账单会非常慢。我在orders表建了三个核心索引ALTER TABLE orders ADD INDEX idx_order_no (order_no); ALTER TABLE orders ADD INDEX idx_status_create_time (status, create_time); ALTER TABLE orders ADD INDEX idx_table_time (table_id, create_time);第一个索引是满足订单号精确查询第二个索引覆盖了运营最频繁的场景——“按订单状态查某个时间段内的订单”第三个索引用来查某桌台的历史消费记录。在营业报表模块里我需要按天统计销售额最早写的SQL是直接对orders表做全表查询再在内存里分组聚合。结果测下来几万条数据时还好但数据量到十万级别时查询耗时飙到几百毫秒虽然不至于拖垮应用但明显有优化空间。后来改成了在SQL层面做日期分组和SUM聚合配合上面建的时间索引查询响应稳定在几十毫秒内。3.3 数据一致性与事务控制订单生成过程涉及多张表的写操作写入orders、写入order_item、扣减dish库存、更新桌面状态。这四步操作必须放在同一个数据库事务里任何一步失败都要整体回滚否则就会出现订单已生成但库存没扣、桌面状态错乱这种严重问题。Spring的Transactional注解解决了这个需求。这里特别要强调的是事务的传播行为和隔离级别。我用了默认的REQUIRED传播行为即如果当前存在事务就加入当前事务不存在就新建一个。隔离级别用的是MySQL默认的REPEATABLE_READ在这个场景下足够安全也没有必要为了追求性能改成READ_COMMITTED。事务里还涉及一个“分布式”的伪命题Redis库存缓存和MySQL库存数据的一致性。实际操作中我采用的策略是先更新数据库再删除Redis缓存。如果Redis删除失败缓存里的旧库存数据也不会造成“负库存”因为扣减操作最终以数据库为准Redis里的数据只是用于前台菜单显示的预扣余量。这样设计虽然做不到强一致但对门店收银场景来说体验和安全性都是够用的。4. 实操过程与核心环节实现4.1 完整开发环境搭建环境搭建这部分值得详细的说说。我拿一台全新的云服务器2核4G配置作为演示环境操作系统选择Ubuntu 22.04使用宝塔面板作为运维辅助工具。以下是一套完整的操作流程第一步安装基础环境。在宝塔面板软件商店里直接安装MySQL 8.0、Redis 7.0、Nginx 1.22这几项都是可视化操作几分钟就能完成。Java环境我坚持手动安装因为宝塔自带的Java版本管理有时候不太直观mkdir -p /usr/local/java tar -zxvf jdk-8u391-linux-x64.tar.gz -C /usr/local/java vim /etc/profile # 添加如下内容 export JAVA_HOME/usr/local/java/jdk1.8.0_391 export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar # 使配置生效 source /etc/profile java -version第二步创建数据库和账号。我特意创建了一个独立的数据库账号没有直接用root权限操作业务库这是一种好习惯也方便后续权限控制和数据隔离。CREATE DATABASE shaxian_pos DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; CREATE USER pos_userlocalhost IDENTIFIED BY YourPassword; GRANT ALL PRIVILEGES ON shaxian_pos.* TO pos_userlocalhost; FLUSH PRIVILEGES;数据库字符集一定要用utf8mb4这个是硬性要求。沙县小吃菜单里有很多特殊字符和生僻字如果用了utf8部分字形会存不进去或者显示成乱码。第三步打包上传部署。我在本地开发机上执行打包命令然后上传到服务器通过Docker运行。这里简单展示docker-compose配置version: 3 services: app: image: openjdk:8-jdk-alpine container_name: shaxian-pos ports: - 8080:8080 volumes: - /data/pos/app.jar:/app.jar - /data/pos/logs:/logs command: [java, -jar, /app.jar, --spring.profiles.activeprod] restart: always这种部署方式的好处是以后代码更新只需要替换app.jar文件然后重启容器不需要操心Java运行时环境变化。4.2 后端核心代码实践在订单生成这个核心方法上我采用的面相是“事务内完成所有关键写入”设计。简单梳理一下关键流程第一步生成订单号。订单号我用了“日期随机序列”的格式如20250415001。这里不直接用数据库自增ID作为对外订单号是因为会让竞争对手轻易推断出单量而且多表联查时自增ID暴露容易泄露业务规模。自定义订单号加唯一索引更安全也更专业。第二步锁定菜品库存。在事务内对要购买的菜品记录执行SELECT ... FOR UPDATE锁定这些行直到事务结束。Transactional(rollbackFor Exception.class) public OrderResult createOrder(CreateOrderRequest request) { // 1. 参数校验及幂等性校验 // 2. 锁定菜品库存记录 ListOrderItemRequest items request.getItems(); for (OrderItemRequest item : items) { Dish dish dishMapper.selectByIdForUpdate(item.getDishId()); if (dish.getStock() item.getQuantity()) { throw new BusinessException(菜品【 dish.getName() 】库存不足); } } // 3. 计算订单总金额 // 4. 插入订单主记录 // 5. 插入订单明细记录 // 6. 扣减库存 // 7. 更新桌台状态 // 8. 发送WebSocket通知 return buildOrderResult(); }这里用SELECT ... FOR UPDATE加悲观锁和之前提到的乐观锁方案定位并不冲突。悲观锁负责事务内部的强一致保护乐观锁负责跨请求的并发冲突兜底。两层都做了系统才能稳。第三步是发送WebSocket通知。创建订单后后厨大屏上要立刻显示新订单。通过WebSocket广播的方式实现ServerEndpoint(/ws/kitchen) public class KitchenWebSocket { private static final CopyOnWriteArraySetSession SESSIONS new CopyOnWriteArraySet(); public static void sendToKitchen(OrderNotifyMessage message) { String payload JSON.toJSONString(message); for (Session session : SESSIONS) { try { session.getBasicRemote().sendText(payload); } catch (IOException e) { SESSIONS.remove(session); } } } }用CopyOnWriteArraySet存储WebSocket会话是因为它是一个线程安全的集合在高频次广播时不会出现并发修改异常。考虑到并发尖峰是收银系统的常态这里值得用一点点并发知识换取稳定性。4.3 前端演示环节的关键页面毕设演示环节基本都是靠前端页面撑场面。我在前端用Vue 3 Element Plus搭建的后台管理界面移动端点餐端则写了一个轻量级的H5页面。收银台页面是整个演示的重头戏布局是左侧为菜品类目拌面、蒸饺、炖汤、套餐等中间是菜品列表每个菜品显示图片、价格、今日库存右侧为当前订单购物车区域。选中菜品后点击“加入购物车”右侧实时更新数量和金额收银员一眼就能看到客人点了什么、花了多少钱。桌面扫码点餐的H5页面相对简洁顾客用微信扫桌台二维码进入上方轮播展示招牌菜品中间是菜品分类Tab下方是购物车聚合栏。整个页面强迫症式的做了移动端适配在iPhone和Android各机型上验证过显示效果。数据可视化这块用了ECharts做营业报表。首页Dashboard展示当日营收、订单量、新增会员数三个核心卡片下方是从早十点到晚十点的分时段营业额折线图右侧是今天的菜品销量TOP5排行榜。这套可视化不能说多复杂但答辩时评委看设备一眼就能明白系统具备数据分析能力。5. 常见问题与排查技巧实录5.1 SpringBoot版本坑与依赖冲突SpringBoot版本选择上踩过比较大的坑。开发初期图新直接用了SpringBoot 3.0结果发现它强制要求JDK 17而且MyBatis Plus官方当时对SpringBoot 3的适配还不完善启动时经常报各种依赖兼容错误。后来我回退到SpringBoot 2.7.x配合JDK 8一切顺畅了。这里有一个心得毕业设计选型不要追求版本最新要选生态最稳定、资料最丰富的组合。SpringBoot 2.7.x MyBatis Plus 3.5.x MySQL 8.0是一个非常成熟的组合网上遇到问题能找到大量解决方案这一点在赶进度时格外重要。另一个依赖冲突的典型场景是Redis客户端。SpringBoot 2.x默认用Lettuce作为Redis客户端但如果项目里同时引入了Jedis依赖启动时容易出现路由冲突。我一律去掉Jedis统一用Lettuce。省心。5.2 数据库死锁的分析与处理在压测时遇到过一例死锁报错信息是Deadlock found when trying to get lock; try restarting transaction。一开始对死锁不太敏感以为是随机问题复现几次后排查日志发现是两条并发下单请求以不同顺序锁定了同一个菜品。请求A先锁菜品1再锁菜品2请求B先锁菜品2再锁菜品1在特定交叉时刻就会互相等待形成死锁。MySQL检测到死锁后会主动回滚一个事务对用户表现为“下单失败请重试”。解决方案有两个层面。第一个是调整锁定顺序所有请求都用同一个顺序去获取菜品锁比如按菜品ID从小到大排序后再执行锁定。第二个是设置事务等待锁超时时间SET GLOBAL innodb_lock_wait_timeout 3; SET SESSION innodb_lock_wait_timeout 3;两个方案我都做了死锁问题彻底消失。5.3 WebSocket连接不稳定的排查开发阶段WebSocket功能频繁掉线尤其在SpringBoot内嵌Tomcat环境下运行时连接过一会儿就断开。排查发现是Nginx反向代理配置的问题。Nginx对HTTP长连接的默认超时时间是60秒一旦超过没有数据交互连接就被切断了。解决方式是调大Nginx的proxy_read_timeout并开启WebSocket协议升级支持location /ws/ { proxy_pass http://backend_server; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 3600s; }配置生效后WebSocket连接稳定了后厨大屏不再频繁断线重连。还有一个小细节WebSocket消息格式不能直接发中文需要统一用JSON封装好再发送。前端拿到消息后解析JSON再渲染避免因为编码问题导致乱码。5.4 常见问题速查表问题现象产生原因解决方案启动报Port 8080 already in use端口被占用lsof -i:8080 查找进程并kill或修改server.port数据库连接失败密码不对或权限不足检查application.yml配置到MySQL中验证授权页面中文显示乱码前后端字符集不一致统一使用UTF-8数据库连接串加characterEncodingutf8订单重复支付回调接口未做幂等用订单状态加乐观锁支付回调时校验订单状态菜品图片加载失败静态资源路径错误配置资源映射或使用Nginx静态目录Redis连接超时未配置密码或IP白名单设置requirepass调整spring.redis配置6. 从毕设到实际落地的延伸思考与个人心得这个系统的核心逻辑虽然不复杂但将每个模块串联起来并保证稳定运行后你给我重新审视“一个完整的软件系统”时视角发生很大变化——从最初只在意“功能跑不跑得通”到后期更关心“系统扛不扛得住并发、数据部对不对得上账、代码好不好扩展”。代码层面我把每个核心模块都做了接口抽象支付服务、库存服务、通知服务都是独立接口换实现类就能换一套逻辑。当时答辩被问“如果接入微信支付怎么改”直接现场操作给评委看把模拟支付类换成真实支付类的依赖注入配置几分钟之内讲清楚。运维层面用Docker打包部署后整套系统在云服务器上稳定运行了两个月没掉过链子。为了做压测还模拟了连续一周的营业数据每天约500笔订单一共积累了三千多条有效订单数据。从这些数据里跑出的营业报表拿来给答辩展示非常有说服力。如果这个系统后续要继续演进我有几个明确的方向。一是接入真实支付网关把微信支付和支付宝的商户号办下来代码框架已经准备好了只是资质申请是另外一件事。二是增加会员模块做一个轻量级的储值和积分体系让回头客消费可以累计积分兑换菜品这也是门店运营实实在在需要的功能。三是增加后厨KDS厨房显示系统的完整实现目前已经有了简单的WebSocket大屏进阶版可以增加菜品制作计时、超时预警等功能。回到毕业设计本身我最大的体会是选题接地气并不等于没深度关键是你要愿意往深处去做。沙县小吃收银系统这个题目从表面看只是个CRUD项目但只要你把可靠性、扩展性、并发安全这几个点真正落到位做出的项目就不缺技术含量。哪怕最终不需要真正商用整个过程中的需求分析、数据库设计、并发控制、接口联调、部署上线这套完整流程本身就是毕业后步入职场最有价值的预演。把这个项目吃透了以后遇到类似的企业级管理系统开发任务你心里就有底了。最后再分享一个小技巧写毕业设计论文或文档时项目架构图和用例图用ProcessOn画一份清晰的图把设计思路用图表达出来比长篇大论的文字叙述要加分得多。答辩时间一般只有十到十五分钟图是最有效率的语言一定要舍得在这上面花时间。 
长河君 · 2026/10/8 9:36:28 · 阅读 1.2k SpringBoot收银系统毕业设计实战：从需求分析到上线部署
做毕业设计选了沙县小吃收银系统这个题目用SpringBoot来落地听起来不太起眼但真做起来其实挺有讲究。收银系统属于典型的管理信息系统麻雀虽小五脏俱全从前端点餐界面到后端订单流转再到支付对接和营业报表一条链路走下来SpringBoot那一套核心技能点基本都能覆盖到。这篇文章就把我当时从选题、设计到编码再到最后调试上线的完整思路和经验做个梳理给准备做同类系统或者正在为毕业设计发愁的朋友一个具体可参考的路径。1. 项目整体设计与技术选型思路1.1 毕业设计选题的几个现实考量很多人觉得“沙县小吃收银系统”这个题目偏简单技术含量低我一开始也有这个顾虑。但真把需求拆开看这个题目的覆盖面和延展空间都相当可观。收银系统首先要解决的就是“点餐-结算-出餐-报表”这条核心业务链这里面牵扯到并发下单、库存扣减、订单状态流转、支付回调、数据统计这些环节。一个快餐店在不同时段的并发量虽然比不上电商大促但高峰期几十单同时进来对后端接口的响应速度和数据一致性同样有要求。另一方面选这个题目在实际答辩的时候特别好讲。沙县小吃是大家都熟悉的场景评委不需要你费劲解释业务背景你直接把桌台点餐、扫码点单、后厨出餐这个流程讲清楚所有人都能听懂。技术实现上哪怕用了很多复杂设计也能够落地到具体场景里去论证合理性这比做一个抽象的管理系统要容易得多。1.2 为什么是SpringBoot而不是其他框架SpringBoot在Java生态里早就成了事实标准选它有几个实际考量。第一是启动快、配置少相较于传统Spring MVC那套繁琐的XML配置SpringBoot的自动配置机制把大量样板工作直接省掉了。尤其对毕业设计来说时间紧、任务重如果整天折腾配置文件核心业务逻辑反而没时间打磨。第二是生态成熟SpringBoot整合MyBatis、Redis、MQ、WebSocket都有非常成熟的方案。我在设计这个项目的技术栈时核心架构如下SpringBoot 2.7.x基础框架提供依赖管理和自动配置MyBatis Plus数据持久层内置CRUD方法省掉大量Mapper XMLMySQL 8.x主数据库存储菜品、订单、用户等业务数据Redis缓存热点菜品数据、分布式锁控制并发下单、存储购物车状态WebSocket实现订单状态变更实时推送到后厨大屏和前台JWT无状态登录认证区分管理员、收银员、后厨等多类角色第三是部署方便。SpringBoot内嵌Tomcat打包成Jar包扔到服务器上就能跑。我用宝塔面板加Docker部署整个过程非常顺畅一条命令就能完成构建和启动。1.3 系统整体功能架构从功能模块角度这个系统最终分成了六个核心模块各自职责清晰、边界明确模块核心功能业务价值桌台管理桌台开台、换桌、并桌、清台模拟线下快餐店的桌台运营状态支持扫码点餐场景菜品管理菜品分类、口味规格、上下架、库存预警支撑菜单灵活调整适应日常菜品更新需求点餐下单购物车、下单、订单拆分、备注管理核心业务链路起点支持堂食、打包两种场景支付结算现金结算、微信/支付宝扫码支付、聚合支付对接完成订单闭环满足多种支付场景订单管理订单状态流转、退单、催菜、订单查询管理从下单到完成的全生命周期后厨实时同步营业报表日营收统计、菜品销量排行、时段分析辅助门店运营决策提供经营数据可视化2. 核心功能模块的详细设计2.1 点餐下单流程的设计思路点餐是收银系统的核心业务节点这里我设计了两种点餐模式。一种是传统的收银员代客点餐用户在收银台直接看菜单收银员操作下单另一种是桌台扫码点餐顾客入座后扫桌台二维码在手机上直接浏览菜单和下单。两种模式最终都会汇聚到同一套订单生成逻辑里。这里最关键的是购物车数据存储方案。最初我考虑用MySQL临时表来存购物车但后来发现频繁的增删改查会带来不小的数据库开销而且用户点餐时会出现滑动选择、修改数量这类高频操作。改用Redis来维护购物车数据后每个桌位或每个用户会话对应一个唯一key里面用Hash结构存菜品ID和数量体验好了很多也减轻了数据库压力。Redis自身的过期机制还能自动清理长时间未结算的无效购物车省去自己写定时任务。下单接口要考虑重复提交的问题。如果用户快速连点两次“提交订单”按常规操作会生成两条一模一样的订单顾客要多付一次钱。这个问题是在联调阶段发现的当时测试同学模拟了高强度点击两条订单同时落库。后来通过给下单请求加了一个前端生成的唯一请求编号后端用Redis的SETNX命令做幂等校验同一编号的请求在规定时间内只能创建一笔订单从根上解决了重复下单问题。2.2 订单状态机的合理流转设计订单状态是整个系统的业务主线状态流转设计的合理性直接影响系统后续扩展能力。我最终设计了一条从“待支付”到“已完成”的完整生命周期待支付 - 已支付 - 制作中 - 待取餐 - 已完成除了这条主流程还有两个分支状态已支付后顾客退单会进入“退款中”进而到“已退款”制作中后厨发现食材不足可以进行“拒单”操作订单直接进入“已取消”。当时设计这个状态机有一个反复推敲的地方催菜功能怎么设计。传统做法是顾客喊服务员催菜服务员口头传话到后厨。我想要在系统里实现顾客或者收银员一键“催菜”后厨大屏上对应订单高亮显示并伴随声音提醒。这需要一个中间状态“催菜中”它本质上不改变订单主流程状态只是标记了该订单存在催菜诉求。我单独加了一个order_notify表来记录催菜事件避免把业务状态搞复杂。这是实际运营中非常高频的一个需求有在这个系统里就会自然想到妥善处理的话答辩时也很加分。2.3 支付模块的实现方式与选择支付环节是收银系统里最敏感的部分。当时第一次对接的是微信官方支付接口流程相对标准但申请商户号环节比较折腾个人开发申请需要营业执照等资质。考虑到毕业设计主要做功能演示我在系统里做了一套“模拟支付网关”完整模拟了二维码生成、支付回调、订单状态变更、退款四个环节这样既能安全工作又能把整个支付流程跑通。但为了让系统具备真实落地能力我在代码层面做了接口抽象public interface PaymentService { PaymentResult createPayment(Order order); PaymentResult handleCallback(PaymentNotify notify); PaymentResult refund(Order order); }定义了统一接口后模拟支付和真实对接只需要更换实现类即可。这样设计的好处很明显答辩时跟评委解释“这是一个可替换的支付网关设计”比单纯说“我没对接真实支付”要硬气得多。模拟支付的核心逻辑是生成一个支付二维码内容顾客在收银台确认订单后系统生成随机支付流水号然后提供一个“模拟支付成功”的管理员接口触发回调方法完成订单支付状态变更。我特意在回调方法里加了签名校验的逻辑虽然现阶段校验的是本地MD5签名但对接真实支付网关时只需要换成微信的签名校验规则就行。这笔账算得过来既满足了毕设展示又保住了架构的扩展性。2.4 库存扣减与并发控制快餐店的核心矛盾是高峰期并发高。尤其是沙县小吃这类门店午餐时段可能十几个订单同时涌入如果系统库存扣减做得不好很容易出现超卖或者负库存。这个问题我在设计时就放在很重要的位置。MySQL的乐观锁方案是第一选择。菜品表加一个version字段每次扣减库存时执行这样的SQLUPDATE dish SET stock stock - #{quantity}, version version 1 WHERE id #{dishId} AND version #{oldVersion}如果数据库返回的影响行数为0说明有其他请求已经修改了这条记录当前请求需要重新读取最新库存再尝试扣减。这个方案实现简单对快餐店这种并发量级的场景完全够用。但在极端情况下乐观锁的失败重试会带来请求堆积所以我在这个基础上又加了一层Redis分布式锁。下单流程里同一个菜品的一次批量扣减操作会用Redisson的锁机制包起来锁的粒度是“菜品ID 当前订单的批次号”保证同一个菜品在高并发下不会被同时修改库存。锁超时时间设置为3秒避免某个请求持有锁时间过长影响正常业务。这两层保护配合下来压测时用JMeter模拟100个并发用户同时下单同一道招牌拌面最终库存数据依然准确没有出现负数和错乱的情况。技术方案不怕旧关键是能解决实际问题。3. 数据库设计与关键表结构解析3.1 核心数据表及字段设计数据库设计是整个系统的地基表设计得好不好直接决定后续功能开发是顺畅还是痛苦。我按照业务模块将表拆分为用户权限、菜品库存、交易订单、日志统计四组核心表如下菜品表 dishid, category_id, name, image, price, stock, unit, status, version, create_time, update_time这里有个小设计心得price字段我用了Decimal(10,2)而不是直接用Double初始开发时图省事一度用了double后来账单统计时有操作发现对不上账排查半天才发现是小数的二进制精度误差。全部改成Decimal后金额计算彻底干净。订单表 ordersid, order_no, table_id, user_id, total_amount, pay_amount, status, pay_type, remark, create_time, pay_time, finish_time表名没有用order因为order在MySQL里是关键字直接使用会带来很多SQL书写上的麻烦这是早期踩过的一个坑。订单明细表 order_itemid, order_id, dish_id, dish_name, price, quantity, amount订单明细为什么要冗余保存一份dish_name和price因为菜品价格和名称未来随时可能调整如果订单只关联dish_id事后查历史订单看到的是当前价格而不是当时的成交价格这就是一种“业务数据漂移”。冗余存储可以说是收银系统必须坚持的设计原则。桌台表 dining_tableid, table_no, seat_count, status, open_time, update_time这里status用了枚举值空闲、占用、待清理。桌台从“占用”到“空闲”不是直接切换的必须经过“待清理”状态这是当时跟门店实际运营逻辑对齐后确定的状态机。收银员结账后桌台置为“待清理”服务员打扫并确认后才恢复“空闲”。如果不加这个中间态很容易出现“顾客还没走就安排了新客入座”的运营事故。3.2 数据库索引设计与查询优化订单表的数据量在门店运营后会持续增长尤其订单明细表一天几百单很正常月积累下来就是上万条数据。查询的时候如果索引设计不合理翻历史账单会非常慢。我在orders表建了三个核心索引ALTER TABLE orders ADD INDEX idx_order_no (order_no); ALTER TABLE orders ADD INDEX idx_status_create_time (status, create_time); ALTER TABLE orders ADD INDEX idx_table_time (table_id, create_time);第一个索引是满足订单号精确查询第二个索引覆盖了运营最频繁的场景——“按订单状态查某个时间段内的订单”第三个索引用来查某桌台的历史消费记录。在营业报表模块里我需要按天统计销售额最早写的SQL是直接对orders表做全表查询再在内存里分组聚合。结果测下来几万条数据时还好但数据量到十万级别时查询耗时飙到几百毫秒虽然不至于拖垮应用但明显有优化空间。后来改成了在SQL层面做日期分组和SUM聚合配合上面建的时间索引查询响应稳定在几十毫秒内。3.3 数据一致性与事务控制订单生成过程涉及多张表的写操作写入orders、写入order_item、扣减dish库存、更新桌面状态。这四步操作必须放在同一个数据库事务里任何一步失败都要整体回滚否则就会出现订单已生成但库存没扣、桌面状态错乱这种严重问题。Spring的Transactional注解解决了这个需求。这里特别要强调的是事务的传播行为和隔离级别。我用了默认的REQUIRED传播行为即如果当前存在事务就加入当前事务不存在就新建一个。隔离级别用的是MySQL默认的REPEATABLE_READ在这个场景下足够安全也没有必要为了追求性能改成READ_COMMITTED。事务里还涉及一个“分布式”的伪命题Redis库存缓存和MySQL库存数据的一致性。实际操作中我采用的策略是先更新数据库再删除Redis缓存。如果Redis删除失败缓存里的旧库存数据也不会造成“负库存”因为扣减操作最终以数据库为准Redis里的数据只是用于前台菜单显示的预扣余量。这样设计虽然做不到强一致但对门店收银场景来说体验和安全性都是够用的。4. 实操过程与核心环节实现4.1 完整开发环境搭建环境搭建这部分值得详细的说说。我拿一台全新的云服务器2核4G配置作为演示环境操作系统选择Ubuntu 22.04使用宝塔面板作为运维辅助工具。以下是一套完整的操作流程第一步安装基础环境。在宝塔面板软件商店里直接安装MySQL 8.0、Redis 7.0、Nginx 1.22这几项都是可视化操作几分钟就能完成。Java环境我坚持手动安装因为宝塔自带的Java版本管理有时候不太直观mkdir -p /usr/local/java tar -zxvf jdk-8u391-linux-x64.tar.gz -C /usr/local/java vim /etc/profile # 添加如下内容 export JAVA_HOME/usr/local/java/jdk1.8.0_391 export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar # 使配置生效 source /etc/profile java -version第二步创建数据库和账号。我特意创建了一个独立的数据库账号没有直接用root权限操作业务库这是一种好习惯也方便后续权限控制和数据隔离。CREATE DATABASE shaxian_pos DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; CREATE USER pos_userlocalhost IDENTIFIED BY YourPassword; GRANT ALL PRIVILEGES ON shaxian_pos.* TO pos_userlocalhost; FLUSH PRIVILEGES;数据库字符集一定要用utf8mb4这个是硬性要求。沙县小吃菜单里有很多特殊字符和生僻字如果用了utf8部分字形会存不进去或者显示成乱码。第三步打包上传部署。我在本地开发机上执行打包命令然后上传到服务器通过Docker运行。这里简单展示docker-compose配置version: 3 services: app: image: openjdk:8-jdk-alpine container_name: shaxian-pos ports: - 8080:8080 volumes: - /data/pos/app.jar:/app.jar - /data/pos/logs:/logs command: [java, -jar, /app.jar, --spring.profiles.activeprod] restart: always这种部署方式的好处是以后代码更新只需要替换app.jar文件然后重启容器不需要操心Java运行时环境变化。4.2 后端核心代码实践在订单生成这个核心方法上我采用的面相是“事务内完成所有关键写入”设计。简单梳理一下关键流程第一步生成订单号。订单号我用了“日期随机序列”的格式如20250415001。这里不直接用数据库自增ID作为对外订单号是因为会让竞争对手轻易推断出单量而且多表联查时自增ID暴露容易泄露业务规模。自定义订单号加唯一索引更安全也更专业。第二步锁定菜品库存。在事务内对要购买的菜品记录执行SELECT ... FOR UPDATE锁定这些行直到事务结束。Transactional(rollbackFor Exception.class) public OrderResult createOrder(CreateOrderRequest request) { // 1. 参数校验及幂等性校验 // 2. 锁定菜品库存记录 ListOrderItemRequest items request.getItems(); for (OrderItemRequest item : items) { Dish dish dishMapper.selectByIdForUpdate(item.getDishId()); if (dish.getStock() item.getQuantity()) { throw new BusinessException(菜品【 dish.getName() 】库存不足); } } // 3. 计算订单总金额 // 4. 插入订单主记录 // 5. 插入订单明细记录 // 6. 扣减库存 // 7. 更新桌台状态 // 8. 发送WebSocket通知 return buildOrderResult(); }这里用SELECT ... FOR UPDATE加悲观锁和之前提到的乐观锁方案定位并不冲突。悲观锁负责事务内部的强一致保护乐观锁负责跨请求的并发冲突兜底。两层都做了系统才能稳。第三步是发送WebSocket通知。创建订单后后厨大屏上要立刻显示新订单。通过WebSocket广播的方式实现ServerEndpoint(/ws/kitchen) public class KitchenWebSocket { private static final CopyOnWriteArraySetSession SESSIONS new CopyOnWriteArraySet(); public static void sendToKitchen(OrderNotifyMessage message) { String payload JSON.toJSONString(message); for (Session session : SESSIONS) { try { session.getBasicRemote().sendText(payload); } catch (IOException e) { SESSIONS.remove(session); } } } }用CopyOnWriteArraySet存储WebSocket会话是因为它是一个线程安全的集合在高频次广播时不会出现并发修改异常。考虑到并发尖峰是收银系统的常态这里值得用一点点并发知识换取稳定性。4.3 前端演示环节的关键页面毕设演示环节基本都是靠前端页面撑场面。我在前端用Vue 3 Element Plus搭建的后台管理界面移动端点餐端则写了一个轻量级的H5页面。收银台页面是整个演示的重头戏布局是左侧为菜品类目拌面、蒸饺、炖汤、套餐等中间是菜品列表每个菜品显示图片、价格、今日库存右侧为当前订单购物车区域。选中菜品后点击“加入购物车”右侧实时更新数量和金额收银员一眼就能看到客人点了什么、花了多少钱。桌面扫码点餐的H5页面相对简洁顾客用微信扫桌台二维码进入上方轮播展示招牌菜品中间是菜品分类Tab下方是购物车聚合栏。整个页面强迫症式的做了移动端适配在iPhone和Android各机型上验证过显示效果。数据可视化这块用了ECharts做营业报表。首页Dashboard展示当日营收、订单量、新增会员数三个核心卡片下方是从早十点到晚十点的分时段营业额折线图右侧是今天的菜品销量TOP5排行榜。这套可视化不能说多复杂但答辩时评委看设备一眼就能明白系统具备数据分析能力。5. 常见问题与排查技巧实录5.1 SpringBoot版本坑与依赖冲突SpringBoot版本选择上踩过比较大的坑。开发初期图新直接用了SpringBoot 3.0结果发现它强制要求JDK 17而且MyBatis Plus官方当时对SpringBoot 3的适配还不完善启动时经常报各种依赖兼容错误。后来我回退到SpringBoot 2.7.x配合JDK 8一切顺畅了。这里有一个心得毕业设计选型不要追求版本最新要选生态最稳定、资料最丰富的组合。SpringBoot 2.7.x MyBatis Plus 3.5.x MySQL 8.0是一个非常成熟的组合网上遇到问题能找到大量解决方案这一点在赶进度时格外重要。另一个依赖冲突的典型场景是Redis客户端。SpringBoot 2.x默认用Lettuce作为Redis客户端但如果项目里同时引入了Jedis依赖启动时容易出现路由冲突。我一律去掉Jedis统一用Lettuce。省心。5.2 数据库死锁的分析与处理在压测时遇到过一例死锁报错信息是Deadlock found when trying to get lock; try restarting transaction。一开始对死锁不太敏感以为是随机问题复现几次后排查日志发现是两条并发下单请求以不同顺序锁定了同一个菜品。请求A先锁菜品1再锁菜品2请求B先锁菜品2再锁菜品1在特定交叉时刻就会互相等待形成死锁。MySQL检测到死锁后会主动回滚一个事务对用户表现为“下单失败请重试”。解决方案有两个层面。第一个是调整锁定顺序所有请求都用同一个顺序去获取菜品锁比如按菜品ID从小到大排序后再执行锁定。第二个是设置事务等待锁超时时间SET GLOBAL innodb_lock_wait_timeout 3; SET SESSION innodb_lock_wait_timeout 3;两个方案我都做了死锁问题彻底消失。5.3 WebSocket连接不稳定的排查开发阶段WebSocket功能频繁掉线尤其在SpringBoot内嵌Tomcat环境下运行时连接过一会儿就断开。排查发现是Nginx反向代理配置的问题。Nginx对HTTP长连接的默认超时时间是60秒一旦超过没有数据交互连接就被切断了。解决方式是调大Nginx的proxy_read_timeout并开启WebSocket协议升级支持location /ws/ { proxy_pass http://backend_server; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 3600s; }配置生效后WebSocket连接稳定了后厨大屏不再频繁断线重连。还有一个小细节WebSocket消息格式不能直接发中文需要统一用JSON封装好再发送。前端拿到消息后解析JSON再渲染避免因为编码问题导致乱码。5.4 常见问题速查表问题现象产生原因解决方案启动报Port 8080 already in use端口被占用lsof -i:8080 查找进程并kill或修改server.port数据库连接失败密码不对或权限不足检查application.yml配置到MySQL中验证授权页面中文显示乱码前后端字符集不一致统一使用UTF-8数据库连接串加characterEncodingutf8订单重复支付回调接口未做幂等用订单状态加乐观锁支付回调时校验订单状态菜品图片加载失败静态资源路径错误配置资源映射或使用Nginx静态目录Redis连接超时未配置密码或IP白名单设置requirepass调整spring.redis配置6. 从毕设到实际落地的延伸思考与个人心得这个系统的核心逻辑虽然不复杂但将每个模块串联起来并保证稳定运行后你给我重新审视“一个完整的软件系统”时视角发生很大变化——从最初只在意“功能跑不跑得通”到后期更关心“系统扛不扛得住并发、数据部对不对得上账、代码好不好扩展”。代码层面我把每个核心模块都做了接口抽象支付服务、库存服务、通知服务都是独立接口换实现类就能换一套逻辑。当时答辩被问“如果接入微信支付怎么改”直接现场操作给评委看把模拟支付类换成真实支付类的依赖注入配置几分钟之内讲清楚。运维层面用Docker打包部署后整套系统在云服务器上稳定运行了两个月没掉过链子。为了做压测还模拟了连续一周的营业数据每天约500笔订单一共积累了三千多条有效订单数据。从这些数据里跑出的营业报表拿来给答辩展示非常有说服力。如果这个系统后续要继续演进我有几个明确的方向。一是接入真实支付网关把微信支付和支付宝的商户号办下来代码框架已经准备好了只是资质申请是另外一件事。二是增加会员模块做一个轻量级的储值和积分体系让回头客消费可以累计积分兑换菜品这也是门店运营实实在在需要的功能。三是增加后厨KDS厨房显示系统的完整实现目前已经有了简单的WebSocket大屏进阶版可以增加菜品制作计时、超时预警等功能。回到毕业设计本身我最大的体会是选题接地气并不等于没深度关键是你要愿意往深处去做。沙县小吃收银系统这个题目从表面看只是个CRUD项目但只要你把可靠性、扩展性、并发安全这几个点真正落到位做出的项目就不缺技术含量。哪怕最终不需要真正商用整个过程中的需求分析、数据库设计、并发控制、接口联调、部署上线这套完整流程本身就是毕业后步入职场最有价值的预演。把这个项目吃透了以后遇到类似的企业级管理系统开发任务你心里就有底了。最后再分享一个小技巧写毕业设计论文或文档时项目架构图和用例图用ProcessOn画一份清晰的图把设计思路用图表达出来比长篇大论的文字叙述要加分得多。答辩时间一般只有十到十五分钟图是最有效率的语言一定要舍得在这上面花时间。