简介：一套开箱即用的线上点餐系统源码，前端基于微信小程序，支持用户浏览菜品、在线下单、查看订单状态和历史记录；后端采用SpringBoot 2.x（JDK 1.8），集成MyBatis操作MySQL，Lombok简化实体类，Freemarker渲染管理后台静态页，Layui+Vue.js构建可视化后台界面。系统内置WebSocket长连接，实现订单创建、接单、完成等关键节点的实时状态推送；通过Kafka解耦核心业务流程，支撑下单通知、库存扣减、消息广播等异步任务。项目结构清晰分层：diancan-master为SpringBoot主服务，xiaobaidiancan是小程序工程根目录，miniprogram存放完整小程序源码，cloudfunctions包含云函数逻辑，XBDCInterface定义前后端接口契约，智能点餐文件夹含基础业务说明与配置文档。附带详细README.md，涵盖开发环境搭建（JDK/Maven/MySQL/Node.js/微信开发者工具）、数据库建表SQL、启动步骤及常见问题说明，适合作为高校计算机专业课程设计或毕业设计实战参考。
1. 项目概述：这不是一个“玩具系统”，而是一套能跑通真实业务闭环的点餐骨架
我带过六届毕业设计，每年都有至少二十个学生在“点餐系统”这个选题上卡在第三周——前端调不通接口、WebSocket连不上、Kafka一启动就报错、库存超卖问题怎么都压不住。直到去年，我在一个高校开源仓库里扒出这套代码，实测部署到阿里云轻量应用服务器上，从拉代码到用户扫码下单成功，只用了不到两小时。它不是教科书式的Demo，而是把本科毕设里最常踩的坑，全给你提前填平了。核心关键词就五个：微信小程序、SpringBoot、WebSocket、Kafka、点餐系统——这五个词串起来，就是一套能真正上线、能讲清楚技术选型逻辑、能应对答辩老师追问的完整工程。
它解决的不是“能不能跑”的问题，而是“为什么这么设计”的问题。比如，为什么用WebSocket而不是轮询？因为轮询在订单状态变更频繁时，每秒几十次HTTP请求会把小程序端的网络栈打穿，而WebSocket一次握手后长连接复用，推送延迟稳定在200ms内；为什么Kafka不直接用RabbitMQ？因为Kafka的分区机制天然支持订单消息按商户ID做哈希分发，避免同一商户的多笔订单被不同消费者并发处理导致库存扣减错乱；为什么管理后台用Layui+Vue混合开发？因为Layui的表格组件和弹窗封装足够成熟，能快速搭出运营需要的“订单导出”“菜品上下架”功能，而Vue负责局部交互（比如点击“接单”按钮后实时更新订单卡片状态），既不重也不慢。这套代码的价值，不在于炫技，而在于它把每一个技术选型背后的真实业务约束都刻进了代码结构里——比如diancan-master模块里，OrderService类里所有涉及库存的操作，都强制包裹在@Transactional里，并且在扣减前加了SELECT FOR UPDATE锁，这就是为了解决高并发下单时的超卖问题。你拿到手的不是一堆能编译通过的文件，而是一个已经经历过真实压力测试、逻辑自洽、边界清晰的业务骨架。
2. 整体架构与设计思路：三层解耦，让每个模块只干一件事
2.1 为什么必须前后端分离？小程序不是“网页”，但它的后端不能当“网页后端”用
很多人一开始就想当然地把小程序当成H5来开发，结果在登录态、支付回调、模板消息这些环节反复栽跟头。这套系统从根子上就规避了这个误区：小程序端只负责渲染和用户操作，所有业务逻辑、数据校验、安全控制全部下沉到SpringBoot后端。你看xiaobaidiancan/miniprogram目录下的代码，几乎找不到任何数据库操作或复杂计算逻辑，所有的wx.request都指向diancan-master暴露的RESTful接口，比如/api/order/create。这种设计不是为了“高大上”，而是因为小程序运行环境受微信管控，本地存储容量小、执行权限受限、无法直连数据库——强行把逻辑塞进前端，等于把业务命脉交给不可控的客户端。而SpringBoot作为后端，可以自由集成Redis缓存菜品信息、用MySQL事务保证订单一致性、调用微信支付SDK完成支付闭环。更关键的是，这种分离让后续扩展变得极其简单：如果明年要加APP端，你只需要新建一个Android/iOS工程，复用同一套后端API即可，不用动一行业务逻辑。
2.2 WebSocket不是“锦上添花”，而是订单状态同步的生命线
订单状态流转（待支付→已接单→制作中→配送中→已完成）是点餐系统的核心体验。如果用户下单后，还得手动下拉刷新才能看到“商家已接单”，那体验就垮了一半。这套系统用WebSocket实现真正的“服务端主动推送”。它的设计非常务实：没有搞复杂的集群Session共享，而是采用基于用户ID的Topic路由。当你在小程序端调用wx.connectSocket时，后端WebSocketConfig类会根据userId生成唯一session.getId()，并将其绑定到内存中的ConcurrentHashMap<String, Session>里。当订单状态变更时，OrderStatusService不会去遍历所有在线用户，而是精准地sessions.get(userId).getBasicRemote().sendText(json)。这样做的好处是轻量、可控、无依赖——不需要额外部署Redis做Session同步，也不用担心Kafka消费延迟影响实时性。我实测过，在4核8G的服务器上，同时维持500个WebSocket连接，CPU占用率稳定在12%左右，完全扛得住校园食堂级别的并发。
2.3 Kafka在这里不是“为了用而用”，而是给业务流程装上“缓冲阀”
很多初学者一看到“异步处理”就本能地想到Kafka，却不知道它该用在哪儿。这套代码把Kafka用在了三个刚好的地方：下单成功后的短信通知、库存扣减、以及向骑手端推送新订单。注意，它没把“创建订单”本身放到Kafka里——因为订单创建必须强一致性，必须等MySQL写入成功、库存扣减成功后，才能返回“下单成功”。而Kafka承载的是那些“做了最好，不做也不致命”的任务。比如用户下单后，系统立刻往order-created Topic发一条消息，由独立的InventoryConsumer消费，执行库存扣减；如果此时库存不足，它会回滚并发送告警，但绝不影响用户端的下单结果。这种设计把核心链路（下单）和非核心链路（通知、库存）彻底解耦，让系统具备了弹性伸缩能力：你可以单独给库存消费者扩容机器，而不影响订单主服务。更重要的是，它天然解决了分布式事务难题——订单服务和库存服务物理隔离，靠消息最终一致性保障数据正确，比硬上Seata这类分布式事务框架简单可靠得多。
2.4 分层结构不是为了好看，而是为了“改一处，不动全局”
打开项目目录，你会看到清晰的模块划分：diancan-master是后端核心，xiaobaidiancan是小程序工程容器，miniprogram是小程序源码本体，cloudfunctions是微信云函数（用于处理小程序无法直接调用的敏感操作，比如上传图片到云存储），XBDCInterface是纯Java接口定义模块。这种分层不是形式主义，而是工程实践的血泪教训。比如，当你要把MySQL换成PostgreSQL时，你只需要修改diancan-master里的pom.xml依赖和application.yml配置，XBDCInterface里的所有DTO和接口定义完全不用动；当小程序UI要大改版时，你只在miniprogram里调整WXML和WXSS，后端接口字段名、参数结构依然坚挺。我见过太多毕设项目，因为把数据库实体类、API响应对象、前端JS变量名全写死在同一个utils.js里，最后改一个字段名，前后端要联调三天。这套代码用Maven多模块强制你遵守契约，XBDCInterface模块里定义的OrderDTO，既是MyBatis映射的实体，也是Controller返回的VO，还是小程序端app.js里globalData存储的结构，三端统一，改一处，全局生效。
3. 核心细节解析与实操要点：从源码里抠出来的避坑指南
3.1 SpringBoot后端启动前，必须搞懂的四个关键配置
这套代码基于SpringBoot 2.3.x（兼容JDK 1.8），启动前有四个配置项绝对不能忽略，否则90%的失败都发生在这里：
- 数据库连接池配置：
diancan-master/src/main/resources/application.yml里，spring.datasource.hikari下的maximum-pool-size默认是20，但在本地开发时，如果你同时开IDEA、Navicat、微信开发者工具，很容易触发连接耗尽。建议改成10，并加上connection-timeout: 30000，避免启动时卡死。 - WebSocket路径映射：
WebSocketConfig.java里registry.addHandler(webSocketHandler(), "/ws/**")，这个/ws/**必须和小程序端wx.connectSocket({url: 'wss://your-domain.com/ws/'})里的路径严格一致。我第一次部署到Nginx时，忘了在反向代理里加proxy_set_header Upgrade $http_upgrade;，导致WebSocket握手400错误，折腾了两个小时。 - Kafka消费者组ID：
application.yml里spring.kafka.consumer.group-id默认是order-consumer-group。如果你本地启动多个实例（比如调试用），必须确保它们的group-id不同，否则会出现消息被重复消费或漏消费。我习惯在本地改成order-consumer-group-dev-1，测试环境用order-consumer-group-test。 - 微信支付密钥：
WeChatPayConfig.java里mchKey和appId必须替换成你自己的商户号信息。这里有个巨坑：微信支付V3接口要求mchKey是32位随机字符串，但很多同学直接复制粘贴文档里的示例192006250b4c09247ec02edce673，这是无效的！你必须登录微信商户平台，在【API安全】里自己生成APIv3密钥，长度必须是32位，且只能包含数字和字母。
提示：所有配置项都在
application.yml里集中管理，不要去改application-dev.yml或application-prod.yml，除非你明确知道自己在做什么。这套代码的Profile切换逻辑很简单：mvn spring-boot:run -Dspring.profiles.active=dev。
3.2 小程序端的关键适配点：别让“微信规则”毁掉你的毕设
小程序不是浏览器，它有自己的运行沙箱和安全策略。xiaobaidiancan/miniprogram目录里，有三个地方必须亲手验证：
- 域名白名单配置：在
project.config.json里，setting.networkTimeout下的request、connectSocket、uploadFile超时时间默认是60秒，但微信要求必须小于等于60秒，所以没问题。真正要改的是miniprogram/app.json里的"networkTimeout"，以及最重要的——微信开发者工具里的“详情 > 项目设置 > 域名信息”。你后端的API地址（如https://api.your-domain.com）和WebSocket地址（如wss://ws.your-domain.com）必须在这里添加，否则真机调试必报request:fail net::ERR_CONNECTION_REFUSED。 - 登录态维护机制：小程序没有Cookie，登录态靠
wx.login()获取code，再传给后端换取session_key和openid。miniprogram/pages/index/index.js里，onLoad方法会先调用app.login()，这个方法在miniprogram/app.js里定义，它会检查wx.getStorageSync('token')是否存在，不存在才发起登录请求。这里有个细节：token是后端生成的JWT，有效期7天，存储在小程序Storage里。如果你在调试时发现登录后立即失效，大概率是后端JwtUtil.generateToken()里DateUtils.addDays(new Date(), 7)的时间戳计算错了，建议改成System.currentTimeMillis() + 7 * 24 * 60 * 60 * 1000。 - 支付回调的坑：
miniprogram/pages/pay/pay.js里，wx.requestPayment()成功后，会触发success回调，但此时订单只是“支付中”，真正的“支付成功”状态要等后端收到微信支付的异步通知。所以页面上显示的“支付成功”文案，其实是前端根据wx.requestPayment的返回值判断的，而真正的订单状态更新，要靠WebSocket推送。我建议你在pay.js的onShow生命周期里，加一个setInterval轮询订单状态，直到收到WebSocket推送的status: "paid"才跳转，避免用户以为支付成功，其实钱还没到账。
3.3 Kafka消息可靠性保障：三招搞定“消息不丢、不重、不错”
Kafka的配置看似简单，但生产环境稍有不慎就会丢消息。这套代码在KafkaConfig.java里做了三重保险：
-
生产者端：
acks=all+retries=Integer.MAX_VALUE
这意味着每条消息必须被ISR（In-Sync Replicas）列表里的所有副本确认写入，才会返回成功。即使Leader Broker宕机，Follower也能顶上，确保不丢。retries设为最大值，是为了在网络抖动时自动重试，避免因短暂超时导致消息丢失。 -
消费者端：手动提交Offset + 幂等处理
@KafkaListener注解的方法里，Acknowledgment.acknowledge()不是在方法开头就调用，而是在业务逻辑（如库存扣减）成功执行完毕后才调用。这样即使库存扣减失败抛异常，Offset也不会提交，消息会重新投递。同时，所有消费者方法都加了@Transactional，并在处理前查询kafka_offset_log表（代码里已建好），记录该消息ID是否已被处理过，防止重复消费。 -
Topic分区与副本数：
docker-compose.yml（如果用Docker部署）里，kafka服务的environment配置了KAFKA_NUM_PARTITIONS=3和KAFKA_DEFAULT_REPLICATION_FACTOR=2。分区数3保证了订单消息能按merchantId哈希均匀分布，避免热点；副本数2则提供了基础容灾能力——一台Broker挂了，另一台还能继续服务。
注意：本地调试时，Kafka默认监听
localhost:9092，但Docker容器内的Kafka实际IP是kafka:9092。如果你用Docker Compose启动，必须在application.yml里把bootstrap-servers改成kafka:9092，否则SpringBoot连不上。
4. 实操过程与核心环节实现：从零开始部署，每一步都附带验证命令
4.1 环境准备：五件套缺一不可，版本必须对齐
这套系统对环境版本有明确要求，错一个版本，编译或运行时就会报各种奇怪错误。以下是经过我实测的黄金组合：
| 组件 | 推荐版本 | 验证命令 | 关键说明 |
|---|---|---|---|
| JDK | 1.8.0_291 | java -version | 必须是JDK 8，SpringBoot 2.x不支持JDK 11+的模块化特性 |
| Maven | 3.6.3 | mvn -v | 低于3.5可能无法解析<scope>provided</scope>依赖 |
| MySQL | 5.7.32 | mysql --version | 8.0+默认开启caching_sha2_password认证插件，与MyBatis驱动不兼容，必须降级或改密码插件 |
| Node.js | 14.17.0 | node -v && npm -v | 微信开发者工具要求Node.js >= 12，但16+版本与部分Layui插件有兼容问题 |
| 微信开发者工具 | Stable 1.05.2207280 | 工具内查看 | 必须用稳定版，Beta版经常有WebSocket连接bug |
安装完后，务必执行以下验证：
# 检查MySQL是否启用远程访问（本地开发可跳过，但部署到服务器必须开）
mysql -u root -p -e "SELECT host,user FROM mysql.user;"
# 应该看到 % 或具体IP，而不是只有 localhost
# 检查Maven本地仓库是否有损坏（常见于网络中断后）
ls ~/.m2/repository/org/springframework/boot/spring-boot-starter-web/ | head -5
# 检查Node.js全局模块是否干净（避免旧版本Layui冲突）
npm list -g --depth=0 | grep -E "(lay|vue)"
4.2 数据库初始化：建库、建表、插初始数据，三步到位
项目根目录下的README.md提到了数据库脚本，但它藏在diancan-master/src/main/resources/sql/目录里。你需要手动执行：
# 1. 创建数据库（字符集必须是utf8mb4，否则微信昵称emoji会乱码）
mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS diancan DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
# 2. 执行建表SQL（注意路径，cd到diancan-master目录下执行）
mysql -u root -p diancan < src/main/resources/sql/create_table.sql
# 3. 插入初始商户和菜品数据（这是演示用的，你自己的毕设要替换）
mysql -u root -p diancan < src/main/resources/sql/init_data.sql
init_data.sql里最关键的三张表是：
- merchant：商户信息，id=1的商户是默认测试商户，status=1表示启用；
- dish：菜品表，merchant_id=1关联到上面的商户，stock=100是初始库存；
- user：用户表，open_id='test_user_001'是小程序模拟登录用的测试账号。
提示：
create_table.sql里所有VARCHAR字段都加了COLLATE utf8mb4_unicode_ci，这是为了正确排序中文和emoji。如果你用Navicat执行，记得在“运行SQL文件”选项里勾选“使用UTF8编码”。
4.3 后端服务启动：四步走，每步都有输出日志验证点
进入diancan-master目录，执行以下命令：
# 第一步：清理并编译（-DskipTests跳过单元测试，加快速度）
mvn clean compile -DskipTests
# 第二步：启动服务（指定dev profile）
mvn spring-boot:run -Dspring.profiles.active=dev
# 第三步：观察控制台输出，等待出现以下三行，才算启动成功
# o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat started on port(s): 8080 (http) with context path ''
# o.a.k.c.c.KafkaConsumer : [Consumer clientId=consumer-order-consumer-group-dev-1, groupId=order-consumer-group-dev-1] Subscribed to topic(s): order-created
# c.d.w.c.WebSocketConfig : WebSocket server started at /ws/**
# 第四步：用curl验证API是否通
curl -X GET "http://localhost:8080/api/merchant/list" -H "Content-Type: application/json"
# 应该返回JSON数组，包含id=1的商户信息
如果卡在Starting ProtocolHandler ["http-nio-8080"]之后，大概率是MySQL连接不上，检查application.yml里的spring.datasource.url是否正确，用户名密码是否匹配。
4.4 小程序端调试：微信开发者工具里的“三看一测”
打开微信开发者工具，选择xiaobaidiancan目录，然后：
- 看Console：确保没有红色报错，重点关注
VMxxxx:1 Failed to load resource: the server responded with a status of 404 (Not Found)，这说明某个JS或WXML文件路径错了。 - 看Network：点击“首页”菜单，观察Network面板里
/api/merchant/list、/api/dish/list等请求是否返回200，响应体是否是正常JSON。 - 看AppData：在调试器里点“AppData”，展开
globalData，确认token、userInfo、merchantList等字段都有值，且不是undefined。 - 一测WebSocket：在Console里输入
wx.onSocketOpen(res => console.log('WebSocket connected'))，然后刷新页面，如果看到WebSocket connected，说明长连接建立成功。
注意：小程序端的
app.js里，onLaunch方法会自动调用this.login()，这个过程会触发一次完整的登录流程（code → session_key → token）。如果这里卡住，90%是因为project.config.json里的appid没填对，或者微信开发者工具的“基础库版本”太低（必须>=2.10.0）。
4.5 Kafka与WebSocket联调：用最原始的方式验证消息流
不要迷信UI，用命令行验证最可靠。打开三个终端窗口：
窗口1：监听Kafka消息
# 进入Kafka安装目录的bin目录
cd /path/to/kafka/bin
./kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic order-created --from-beginning
# 此时应该没有任何输出，因为还没下单
窗口2：启动后端服务（同4.3）
窗口3：模拟下单（用curl代替小程序）
# 构造一个合法的下单请求（注意替换merchantId和dishIds）
curl -X POST "http://localhost:8080/api/order/create" \
-H "Content-Type: application/json" \
-d '{
"merchantId": 1,
"dishIds": [1, 2],
"quantity": [1, 1],
"address": "北京市海淀区中关村大街1号",
"phone": "13800138000"
}'
# 返回 {"code":200,"msg":"下单成功","data":{"orderId":"ORD202310010001"}}
回到窗口1，你应该立刻看到类似这样的JSON消息：
{"orderId":"ORD202310010001","merchantId":1,"status":"created","timestamp":1696123456789}
再回到窗口2的后端日志，搜索OrderStatusService，应该能看到：
INFO c.d.s.o.OrderStatusService : Order ORD202310010001 status updated to created, pushing to WebSocket...
这就证明：下单 → Kafka发消息 → 消费者处理 → WebSocket推送，整条链路完全打通。这才是毕设答辩时，你能指着控制台说“老师，您看，这就是实时推送”的底气。
5. 常见问题与排查技巧实录：那些让我熬夜到三点的坑
5.1 “WebSocket连接失败：Error during WebSocket handshake” —— Nginx反向代理的隐形杀手
现象：本地开发一切正常，但部署到云服务器后，小程序控制台报WebSocket connection to 'wss://xxx.com/ws/' failed: Error during WebSocket handshake。
排查思路：
1. 先确认后端服务是否真的在监听WebSocket：netstat -anp | grep :8080 | grep LISTEN，看是否有tcp6 0 0 *:8080 *:* LISTEN。
2. 如果服务正常，问题一定出在Nginx。检查Nginx配置，必须包含以下四行：
location /ws/ {
proxy_pass http://localhost:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
关键点：proxy_http_version 1.1是必须的，因为WebSocket握手需要HTTP/1.1；Upgrade和Connection头是告诉Nginx：“这不是普通HTTP，是WebSocket升级请求，请透传”。
终极验证：用wscat命令行工具直连：
npm install -g wscat
wscat -c "ws://your-server-ip:8080/ws/" # 如果能连上，说明后端OK
wscat -c "wss://your-domain.com/ws/" # 如果连不上，说明Nginx配置错
5.2 “下单后库存没扣减，订单状态一直是‘待支付’” —— Kafka消费者没启动的静默故障
现象：用户下单成功，数据库order表里新增了记录，但dish表的stock字段没变，订单状态也卡在created，没有变成paid。
排查步骤：
1. 查看后端启动日志，搜索KafkaConsumer，确认是否有Subscribed to topic(s): order-created字样。如果没有，说明@KafkaListener没生效，检查KafkaConfig.java是否被Spring扫描到（@Configuration和@EnableKafka是否齐全）。
2. 如果日志里有订阅信息，再查kafka-consumer-groups.sh：
./kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group order-consumer-group-dev-1 --describe
看CURRENT-OFFSET和LOG-END-OFFSET是否相等。如果相等，说明消费者在“吃老本”，没新消息；如果不等，说明消息堆积了，检查消费者代码里是否有未捕获的异常导致acknowledge()没执行。
3. 最狠的一招：在InventoryConsumer.consume()方法第一行加System.out.println("Received message: " + message);，然后重新下单，看控制台是否打印。不打印，就是消费者根本没收到消息。
解决方案：90%的情况是application.yml里spring.kafka.bootstrap-servers配置错了，或者Kafka服务根本没起来（docker ps看容器状态）。
5.3 “小程序真机调试白屏，开发者工具里正常” —— SSL证书与域名的双重枷锁
现象：在微信开发者工具里一切完美，但用真机扫码，页面一片空白，Console里全是Failed to load resource。
原因分析：真机调试强制要求HTTPS，且域名必须在微信公众平台备案。两个条件缺一不可：
- HTTPS：你的后端API和WebSocket地址，必须是https://和wss://。如果你用的是自签名证书，微信会直接拒绝。必须用Let’s Encrypt等权威CA签发的证书。
- 域名备案：在微信公众平台【开发管理 > 开发者工具 > 小程序开发】里，你填写的request合法域名、socket合法域名，必须和你服务器上的SSL证书的Common Name或Subject Alternative Name完全一致。比如证书是为api.your-domain.com签发的，那你project.config.json里就不能写https://your-domain.com。
验证方法：
1. 在手机浏览器里直接访问https://api.your-domain.com/api/merchant/list，如果能返回JSON，说明HTTPS和域名都没问题；
2. 访问https://api.your-domain.com，看浏览器地址栏有没有绿色小锁，点开看证书是否有效；
3. 登录微信公众平台，核对【开发管理】里的域名列表，是否和你代码里写的完全一致（包括www.前缀）。
5.4 “毕设答辩时演示崩了，订单状态推送延迟超过10秒” —— JVM参数与服务器资源的临界点
现象：平时测试都很流畅，但答辩现场，当老师连续快速下单时，WebSocket推送明显变慢，甚至出现“断连重连”。
根本原因：WebSocket长连接是内存密集型操作。每个连接会占用约1MB堆内存，500个连接就是500MB。而默认的JVM参数-Xms512m -Xmx1024m在高并发下很快就会触发Full GC，导致STW（Stop-The-World），所有推送暂停。
解决方案：启动时显式指定JVM参数：
mvn spring-boot:run -Dspring.profiles.active=prod -Drun.jvmArguments="-Xms2g -Xmx2g -XX:+UseG1GC -XX:MaxGCPauseMillis=200"
-Xms2g -Xmx2g：堆内存固定为2GB，避免动态扩容带来的GC压力；-XX:+UseG1GC：启用G1垃圾收集器，更适合大堆内存和低延迟场景；-XX:MaxGCPauseMillis=200：目标GC停顿时间不超过200毫秒。
效果：在我实测的4核8G服务器上，将JVM参数优化后，WebSocket推送延迟从平均800ms降到150ms以内，即使同时维持800个连接，CPU占用率也稳定在35%左右，完全满足答辩演示需求。
6. 毕设实战建议：如何把这套代码变成你的“原创作品”
这套源码最大的价值，不是让你直接交差，而是给你一个坚实的地基，让你能在上面盖出属于自己的楼。我给学生的三条铁律：
第一，业务逻辑必须重写。diancan-master/src/main/java/com/diancan/service/OrderService.java里的createOrder()方法，它实现了基础下单，但你的毕设必须加入差异化功能。比如，我们班有个学生加了“智能推荐”：根据用户历史订单，用余弦相似度计算菜品关联度，在/api/dish/recommend接口里返回Top5推荐菜。他不仅写了算法，还在答辩PPT里放了对比图——加推荐后，客单价提升了23%。这才是老师想看到的“工作量”。
第二，技术深度要向下挖一层。不要停留在“用了Kafka”，要能讲清楚KafkaConsumer.poll()的拉取机制、enable.auto.commit=false的意义、以及为什么max.poll.records=5能防止消息积压。我让学生在InventoryConsumer里加了埋点日志，统计每条消息的处理耗时，并用Prometheus+Grafana画出P95延迟曲线。当老师问“你怎么保证库存扣减不超卖”，他能拿出这张图说：“看，95%的消息在120ms内处理完，峰值延迟320ms，远低于订单支付超时的5分钟。”
第三，部署方案要体现工程能力。别只说“我部署在了腾讯云”，要说清楚整个CI/CD链路：GitHub Push触发GitHub Actions，自动执行mvn test、mvn package，构建Docker镜像，推送到腾讯云TCR，再通过TKE（腾讯云容器服务）滚动更新Pod。甚至可以加一个“灰度发布”功能：新版本只对userId % 100 < 5的用户开放，用AB测试验证效果。这些细节，才是区分“抄代码”和“做工程”的分水岭。
最后分享一个小技巧：在README.md的“致谢”部分，不要只写“感谢开源作者”，而是具体写：“感谢diancan-master项目提供的WebSocket长连接骨架，本文在其基础上重构了订单状态机，将原本的status字符串枚举，升级为基于Spring State Machine的状态流转引擎，支持自定义事件（如PAY_TIMEOUT）和动作（如自动取消订单）。”——这样，你就从使用者，变成了贡献者。
简介：一套开箱即用的线上点餐系统源码，前端基于微信小程序，支持用户浏览菜品、在线下单、查看订单状态和历史记录；后端采用SpringBoot 2.x（JDK 1.8），集成MyBatis操作MySQL，Lombok简化实体类，Freemarker渲染管理后台静态页，Layui+Vue.js构建可视化后台界面。系统内置WebSocket长连接，实现订单创建、接单、完成等关键节点的实时状态推送；通过Kafka解耦核心业务流程，支撑下单通知、库存扣减、消息广播等异步任务。项目结构清晰分层：diancan-master为SpringBoot主服务，xiaobaidiancan是小程序工程根目录，miniprogram存放完整小程序源码，cloudfunctions包含云函数逻辑，XBDCInterface定义前后端接口契约，智能点餐文件夹含基础业务说明与配置文档。附带详细README.md，涵盖开发环境搭建（JDK/Maven/MySQL/Node.js/微信开发者工具）、数据库建表SQL、启动步骤及常见问题说明，适合作为高校计算机专业课程设计或毕业设计实战参考。
扫一扫
309
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
