简介一套基于JavaSSMMySQL微信小程序开发的火锅店点餐系统毕业设计项目面向需要完成毕设、课程设计或期末大作业的高校学生以及希望快速搭建餐饮管理系统的开发者。系统集成了Spring、SpringMVC、MyBatis框架采用微信小程序作为前端交互平台覆盖顾客浏览菜品、选择锅底配菜、在线点餐以及后台订单管理、菜品管理、用户管理等完整业务流程。资源包共1367个文件大小约30.98MB核心类型包括java后端源码、vue管理端页面、小程序wxml/wxss/js、MySQL数据库脚本、XML配置及说明文档等目录结构规范便于按模块学习与二次开发。项目经过严格调试界面美观、操作简单功能齐全可直接作为高分毕设参考也可用于课程设计与期末大作业。目前已有38人学习浏览适合需要完整可运行项目以快速上手Java Web与小程序开发的学习者。1. 火锅店点餐系统的技术栈为什么偏偏是 SSM 加微信小程序火锅店最忙的晚市服务员一手菜单一手点菜宝在桌台间来回跑顾客催加菜、后厨喊单、前台算错账任何一环卡住整店体验就崩了。用 JavaSSMMySQL微信小程序做的火锅店点餐系统本质就是把这三件事搬进手机顾客在小程序里选锅底、挑荤素、定辣度、提交订单SSM 后端接收请求并完成下单事务MySQL 落库菜品和订单数据。对做毕设的同学来说这个组合技术栈不花哨但覆盖面广——Spring 的依赖注入和事务、SpringMVC 的接口映射、MyBatis 的动态 SQL、小程序的生命周期与本地缓存全是面试常考点。下面按从零搭这类订单系统的顺序推进数据模型与接口先行SSM 后端跟上小程序对接最后落到部署验证和 MySQL 优化。2. 先定 ER 图和接口再写代码SSM 分层结构与火锅店点餐的 MySQL 建表毕设项目最常见的烂尾原因不是代码写不完而是表结构先烂了订单状态不知道该放哪、菜品价格和订单价格混在一个字段、表之间没有外键也没有索引后端越写越拧巴。所以我习惯先把 ER 图和接口定下来再谈实现这一步省下的返工时间远超画图那点功夫。2.1 SSM 三个框架各管什么小程序和服务端怎么对接SSM 是 Spring、SpringMVC、MyBatis 的缩写拆开看职责很清晰Spring 管理对象和事务SpringMVC 处理 HTTP 请求的映射和参数绑定MyBatis 负责 SQL 与 Java 对象的转换。小程序和服务端的对接方式是 HTTP JSON 接口小程序端wx.request发请求后端RestController返回统一结构的 JSON。返回格式建议固定成{ code: 0, msg: ok, data: {} }code为 0 表示成功非 0 是业务错误码。前端只判断code不必为每个接口写一套 if/else。这个约定要在写第一个接口之前定下来前后端各存一份联调时才不会互相等。先把接口清单立住后端和小程序照着实现功能方法路径入参返回 data微信登录POST/api/user/login{ code }userId菜品分类GET/api/category/list无分类数组菜品列表GET/api/dish/listcategoryId菜品数组创建订单POST/api/order/createuserId, tableId, items[]orderId模拟支付POST/api/order/payorderIdpayTime订单列表GET/api/order/listuserId, status订单数组表里的接口基本就是小程序所有页面的数据来源。登录接口比较特殊传的不是用户名密码而是wx.login返回的临时 code菜品列表是只读接口查询时记得过滤status 0的下架菜品创建订单和支付两个接口一个写主表和明细一个改状态是后面事务和状态机的核心。2.2 点餐系统的 ER 图与建表 SQL用户、菜品、订单明细怎么落库先画 ER 图再建表。用户和订单是一对多一个订单对应多条订单明细菜品分类对菜品是一对多菜品和订单明细不建外键明细里存的是下单时的快照。桌台不单独建主表作为订单的属性table_id存放扫码进来的桌号直接落这里。下面这套建表 SQL 是 MySQL 5.7 和 8.0 都能直接跑通的最小版本-- 用户表小程序端通过 openid 识别身份不存密码 create table t_user ( id int primary key auto_increment, openid varchar(64) not null unique, nickname varchar(50), avatar varchar(255), create_time datetime default current_timestamp ) engine innodb default charset utf8mb4 comment 小程序用户; -- 菜品分类锅底、荤菜、素菜、小吃 create table t_category ( id int primary key auto_increment, name varchar(30) not null, sort int default 0 ) engine innodb default charset utf8mb4 comment 菜品分类; -- 菜品表price 用 decimal不用 float create table t_dish ( id int primary key auto_increment, category_id int not null, name varchar(50) not null, price decimal(10, 2) not null, stock int not null default 0, image varchar(255), status tinyint default 1 comment 1上架 0下架, create_time datetime default current_timestamp, key idx_category (category_id) ) engine innodb default charset utf8mb4 comment 火锅菜品; -- 订单主表status 用整数状态机 create table t_order ( id bigint primary key auto_increment, order_no varchar(32) not null, user_id int not null, table_id varchar(20), total_amount decimal(10, 2) not null, status tinyint default 0 comment 0待支付 1已支付 2制作中 3已完成 4已取消, remark varchar(200) comment 辣度/忌口备注, create_time datetime default current_timestamp, pay_time datetime, unique key uk_order_no (order_no), key idx_user_time (user_id, create_time) ) engine innodb default charset utf8mb4 comment 订单主表; -- 订单明细冗余菜名和价格保留下单快照 create table t_order_item ( id bigint primary key auto_increment, order_id bigint not null, dish_id int not null, dish_name varchar(50), price decimal(10, 2) not null, count int not null, key idx_order (order_id) ) engine innodb default charset utf8mb4 comment 订单明细;几个值得记住的设计用户表不存密码用openid唯一标识这是小程序登录的通行做法order_no有唯一键顾客和客服查单都靠它不用自增 id 对外暴露订单明细冗余dish_name和price菜品改名或调价后历史订单仍然能看到当时的菜名和价格这叫快照冗余点餐、外卖系统里是标配。2.3 建表时的三个硬规矩金额类型、索引顺序、快照冗余金额一律decimal(10,2)。float/double是二进制近似存储0.1 0.2会得到0.30000000000000004对账时能查出鬼来。Java 侧对应BigDecimal不要用Double接收价格。库存用整型扣减靠条件更新。update t_dish set stock stock - #{count} where id #{id} and stock #{count}影响行数为 0 就是库存不足比先 select 再 update 少一次查询还能避免并发超卖。索引跟着高频查询走。顾客端最高频的查询是按用户查订单按时间倒序所以建(user_id, create_time)联合索引order_no加唯一索引按单号查订单可以走到const。这个差别在数据量上万之后会非常明显第五章专门验证。提示建表阶段把这三条定死后面 Controller、Service、Mapper 怎么写都不会出大格。最怕的是中途发现金额类型错了改表结构连带改所有 SQL 和实体类。3. SSM 后端实现Controller-Service-Mapper 三层把登录、下单、扣库存串起来表结构定好之后后端就是顺着分层把接口一个个填上。SSM 项目最忌把业务逻辑堆在 Controller 里我的习惯是 Controller 只做参数接收和结果包装Service 处理业务Mapper 只碰 SQL谁越界谁难看。3.1 Maven 工程结构与三个配置文件先让 Spring 容器转起来用 Maven 建工程目录结构按包名com.hotpot组织hotpot-server ├── pom.xml └── src/main ├── java/com/hotpot │ ├── controller # 接口层RestController │ ├── service # 业务层事务在这里 │ ├── dao # MyBatis Mapper 接口 │ ├── entity # 实体类 │ └── common # Result 包装、异常类 └── resources ├── spring-mybatis.xml ├── spring-mvc.xml ├── jdbc.properties └── mapper # OrderMapper.xml 等 SQL 文件Spring 容器启动顺序值得注意web.xml里的ContextLoaderListener先加载spring-mybatis.xml创建根容器DispatcherServlet再加载spring-mvc.xml创建子容器子容器能看到父容器的 Bean反之不行。所以 Service、Mapper 放进根容器Controller 放进子容器。各文件职责如下配置文件职责关键配置web.xml启动入口ContextLoaderListener、DispatcherServletspring-mybatis.xml数据源、事务、会话工厂jdbc.properties、MapperScannerConfigurerspring-mvc.xml接口层注解驱动、Controller 包扫描jdbc.properties数据库连接url、username、password面试八股里常问的 SpringMVC 执行流程——请求先进DispatcherServlet经HandlerMapping找到 Controller 方法返回后由视图解析器处理——在这个项目里就是一次wx.request从进入到 JSON 返回的完整路径。你也可以借此把Spring 容器和 SpringMVC 容器什么关系讲清楚这是比背流程更有区分度的答法。3.2 微信登录接口wx.login 的 code 换取 openidRestController RequestMapping(/api/user) public class UserController { Autowired private UserService userService; PostMapping(/login) public Result login(RequestBody MapString, String params) { // 小程序端 wx.login 返回的临时 code5 分钟有效 String code params.get(code); String openid userService.code2Openid(code); Integer userId userService.findOrCreate(openid); return Result.ok(userId); } }Service 里code2Openid做的事是拿 code 请求微信的jscode2session接口把返回的 openid 在t_user里查一遍没有就插入新用户并返回自增 id。同一微信号在同一个小程序里的 openid 是固定的天然适合当用户主键。注意appid和secret只能放后端配置文件小程序端发出去的任何请求别人都能看到把 secret 写进小程序代码等于把钥匙挂在门口。3.3 创建订单的 Transactional 与乐观锁扣库存下单接口是整套系统里最容易写错的地方。一次下单实际包含四步生成订单主记录、遍历购物车明细、逐条扣库存、算总金额。四步要么全部成功要么全部回滚所以 Service 方法上必须加事务Service public class OrderServiceImpl implements OrderService { Override Transactional(rollbackFor Exception.class) public Long createOrder(CreateOrderDTO dto) { String orderNo generateOrderNo(); // 日期 随机数保证唯一 Order order new Order(); order.setOrderNo(orderNo); order.setUserId(dto.getUserId()); order.setTableId(dto.getTableId()); order.setStatus(0); // 待支付 order.setRemark(dto.getRemark()); // 辣度、忌口写这里 orderMapper.insert(order); BigDecimal total BigDecimal.ZERO; for (ItemDTO item : dto.getItems()) { // 条件更新影响行数为 0 说明库存不足 int rows orderMapper.deductStock(item.getDishId(), item.getCount()); if (rows 0) { throw new BizException(菜品库存不足 item.getDishName()); } Dish dish dishMapper.selectById(item.getDishId()); OrderItem oi new OrderItem(); oi.setOrderId(order.getId()); oi.setDishId(dish.getId()); oi.setDishName(dish.getName()); // 快照 oi.setPrice(dish.getPrice()); // 快照 oi.setCount(item.getCount()); orderItemMapper.insert(oi); total total.add(dish.getPrice().multiply(BigDecimal.valueOf(item.getCount()))); } order.setTotalAmount(total); orderMapper.updateAmount(order.getId(), total); return order.getId(); } }对应 Mapper 里的扣库存 SQL 就是 2.3 说的条件更新update iddeductStock update t_dish set stock stock - #{count} where id #{dishId} and stock #{count} /update提示Transactional默认只对RuntimeException回滚自定义业务异常要么继承RuntimeException要么在注解上写死rollbackFor Exception.class。见过太多 SSM 项目事务没生效一查是异常被 try/catch 吞掉或者异常类型不对事务根本没机会回滚。3.3.1 订单状态机待支付、已支付、制作中、已完成订单从创建到完成至少要经历四个状态0 待支付、1 已支付、2 制作中、3 已完成外加 4 取消。状态只允许向前流转不允许跳转或回退。实现上不写自由 if而是提供changeStatus(orderId, from, to)方法update 语句带and status #{from}影响行数为 0 就说明状态被并发改了直接报错。这样小程序、后厨、前台三端对同一订单改状态也不会乱。3.4 订单列表的 MyBatis 动态 SQL一个 select 顶三份订单查询的筛选条件在不同页面不一样顾客端只看自己的管理端可以按状态筛。用 MyBatis 的where加if标签把条件拼起来参数没传的分支自动忽略select idlistByUser resultTypeOrderVO select * from t_order where if testuserId ! nulland user_id #{userId}/if if teststatus ! nulland status #{status}/if /where order by create_time desc limit #{offset}, #{pageSize} /selectoffset的计算是(pageNum - 1) * pageSize这一步放 Service 里算别让前端传。MyBatis 的 Mapper 接口没有实现类Spring 启动时用 JDK 动态代理为每个接口生成代理对象方法调用最终落到 XML 里的 SQL这也是面试常考的MyBatis 怎么和 Spring 整合的答案核心。4. 微信小程序端实现菜品列表、购物车缓存到携带桌号提交订单后端接口就绪后小程序端要做的事很清晰启动时登录拿 userId点餐页拉分类和菜品购物车用本地缓存管理提交订单时带上桌号。用原生小程序实现完全够不必引框架。4.1 小程序目录与 app.json把启动页配成点餐主页miniprogram/ ├── app.js # 启动时 wx.login 拿 userId ├── app.json # 全局配置pages 第一项是启动页 ├── app.wxss ├── utils/ │ ├── request.js # wx.request 封装 │ └── cart.js # 购物车本地缓存 └── pages/ ├── index/ # 点餐主页分类 菜品列表 ├── cart/ # 购物车页 ├── order-confirm/ # 确认订单页桌号 备注 ├── order-list/ # 我的订单列表 └── order-detail/ # 订单详情页面数据来源对应关系是index 页调分类和菜品接口cart 页只读本地缓存order-confirm 页组合购物车缓存和桌号order-list 和 order-detail 分别调订单列表和详情接口。app.json 里pages数组的第一项就是小程序启动后进入的页面想改刚进入的加载页面把目标页挪到数组第一个位置即可。点餐类小程序通常不需要 tabBar一个主入口页面加几个跳转就能完成闭环。4.2 封装 wx.request统一 baseURL、loading 与错误提示// utils/request.js const BASE_URL http://localhost:8080/hotpot/api; function request(path, method GET, data {}) { return new Promise((resolve, reject) { wx.showLoading({ title: 加载中 }); wx.request({ url: ${BASE_URL}${path}, method, data, header: { Content-Type: application/json }, success(res) { if (res.statusCode 200 res.data.code 0) { resolve(res.data.data); } else { wx.showToast({ title: res.data.msg || 请求失败, icon: none }); reject(res.data); } }, fail(err) { wx.showToast({ title: 网络异常, icon: none }); reject(err); }, complete() { wx.hideLoading(); } }); }); } module.exports { request, BASE_URL };这个封装的要点是 Promise 化和统一收口页面里调用request(/dish/list, GET, { categoryId })拿到的直接是 data不用每处重复处理 loading 和错误弹窗。开发阶段用localhost没问题但手机真机预览时 localhost 指向手机自身要改成电脑的局域网 IP正式上线必须用已备案的 HTTPS 域名并在小程序后台配置 request 合法域名否则线上请求会被拦。这是小程序开发第一个容易卡住的地方。用 uniapp 开发的等价写法是uni.request封装思路完全一样。4.3 购物车本地缓存与辣度单选框从加菜到算总价购物车不需要服务端参与本地缓存足够。用同步 API 最简单因为购物车数据量小// utils/cart.js const KEY hotpot_cart; function getCart() { return wx.getStorageSync(KEY) || []; } function addDish(dish) { const cart getCart(); const found cart.find(item item.id dish.id); if (found) { found.count 1; } else { cart.push({ id: dish.id, name: dish.name, price: dish.price, count: 1, spicy: 微辣 }); } wx.setStorageSync(KEY, cart); } function clearCart() { wx.removeStorageSync(KEY); } module.exports { getCart, addDish, clearCart };火锅店的辣度选择适合用radio-group选中的值随购物车项一起存进本地缓存提交订单时放到 items 里后端写进订单备注或明细字段radio-group bindchangeonSpicyChange>Page({ onLoad(options) { // 扫码进入时参数在 scene 里形如 tableId12 const scene decodeURIComponent(options.scene || ); const tableId scene.split()[1] || ; this.setData({ tableId }); }, submitOrder() { const cart getCart(); if (!cart.length) { wx.showToast({ title: 请先选菜, icon: none }); return; } request(/order/create, POST, { userId: wx.getStorageSync(userId), tableId: this.data.tableId, remark: this.data.remark, items: cart.map(item ({ dishId: item.id, count: item.count, spicy: item.spicy })) }).then(orderId { clearCart(); wx.redirectTo({ url: /pages/order-detail/order-detail?orderId${orderId} }); }); } });小程序码的 scene 参数有长度限制桌号这种短参数正好适用。如果入口是普通链接带 query参数会直接出现在options里比如options.tableId。桌号能进订单后厨打单才知道送到哪桌这是扫码点餐和普通外卖点餐的实质区别。5. Tomcat 部署、MySQL 索引验证与两个能直接照抄的运维脚本5.1 打包、部署、初始化一条 curl 确认接口可用环境上 JDK 8 加 Tomcat 8.5/9 加 MySQL 5.7/8.0 最省事。装完 JDK 先配置 JAVA_HOME 和 PATH命令行java -version能正常输出再继续。项目根目录执行mvn clean package -DskipTeststarget 下生成 war 包拷到 Tomcat 的 webapps 目录启动后访问http://localhost:8080/hotpot/看到页面说明容器起来了。数据库初始化用命令行执行 SQL 文件mysql -uroot -p -e create database hotpot_db default charset utf8mb4; mysql -uroot -p hotpot_db hotpot.sql然后验证登录接口curl -X POST http://localhost:8080/hotpot/api/user/login \ -H Content-Type: application/json \ -d {code:dev-code}后端对dev-code这种本地调试值直接返回假 openid 或固定 userId这样可以不依赖微信后台把整条链路跑通真机联调时再换真实 code。这个环境值短路的技巧在前后端分离项目里很实用。5.2 订单慢查询先别加缓存用 EXPLAIN 确认联合索引生效订单量起来后最明显的慢查询是我的订单列表。先看这条 SQL 走没走索引explain select * from t_order where user_id 4 order by create_time desc limit 20;看 explain 输出里的type和key两列type是 ref、key是idx_user_time说明联合索引生效如果type是 ALL 或key是 null就是全表扫描。联合索引的列顺序要和查询条件一致user_id在前 explain 才能命中。按 order_no 查订单走唯一索引type会是 const这类查询适合客服按单号搜单。索引不是越多越好点餐系统里最热的就是这两条查询索引建到这里就够了。5.3 两个可以直接照抄的 MySQL 脚本自动备份 bat 与造数存储过程Windows 上做每日自动备份写一个批处理配合任务计划程序每天凌晨执行echo off set MYSQL_BIND:\mysql-8.0\bin set BAK_DIRD:\hotpot_backup set DB_USERroot set DB_PASS123456 set DB_NAMEhotpot_db set STAMP%date:~0,4%%date:~5,2%%date:~8,2% %MYSQL_BIN%\mysqldump -u%DB_USER% -p%DB_PASS% --default-character-setutf8mb4 %DB_NAME% %BAK_DIR%\%DB_NAME%_%STAMP%.sqlmysqldump是 MySQL 自带工具备份文件名带日期不会互相覆盖恢复时执行mysql -uroot -p hotpot_db 备份文件.sql。造测试数据则用存储过程一次生成过去 30 天里分布均匀的订单delimiter $$ create procedure gen_orders(in days int) begin declare i int default 0; while i days * 200 do insert into t_order(order_no, user_id, table_id, total_amount, status, create_time) values (concat(date_format(now(), %Y%m%d%H%i%s), lpad(i, 6, 0)), 1 floor(rand() * 20), concat(T, 1 floor(rand() * 30)), round(100 rand() * 300, 2), floor(rand() * 5), date_sub(now(), interval floor(rand() * days) day)); set i i 1; end while; end$$ delimiter ; call gen_orders(30);执行一次call gen_orders(30)生成 6000 条订单答辩前用这批数据把分页、索引和状态筛选全部验证一遍比临时手写 insert 可靠得多。delimiter的作用只是让客户端把整个过程体识别为一个语句MySQL 5.7 和 8.0 写法一致。5.4 URL Scheme让顾客从公众号直接拉起带桌号的点餐页复购场景里顾客离店后再次点餐的入口往往在公众号菜单或短信里。可以在小程序后台生成 URL Scheme形如weixin://dl/business?t签名参数用户点击后直接拉起小程序指定页面。生成 scheme 时把页面路径设为pages/index/index参数里带上 tableId这样顾客从公众号进来落地页依然是带着桌号的点餐主页。注意 scheme 有有效期和生成数量限制建议按桌台动态生成并缓存复用不要每次点击都去调接口。把这条链路和桌号参数串起来从店内扫码到店外复购的闭环就完整了——这也是答辩时比能点餐更能加分的完整度设计。本文还有配套的精品资源点击获取
简介一套基于JavaSSMMySQL微信小程序开发的火锅店点餐系统毕业设计项目面向需要完成毕设、课程设计或期末大作业的高校学生以及希望快速搭建餐饮管理系统的开发者。系统集成了Spring、SpringMVC、MyBatis框架采用微信小程序作为前端交互平台覆盖顾客浏览菜品、选择锅底配菜、在线点餐以及后台订单管理、菜品管理、用户管理等完整业务流程。资源包共1367个文件大小约30.98MB核心类型包括java后端源码、vue管理端页面、小程序wxml/wxss/js、MySQL数据库脚本、XML配置及说明文档等目录结构规范便于按模块学习与二次开发。项目经过严格调试界面美观、操作简单功能齐全可直接作为高分毕设参考也可用于课程设计与期末大作业。目前已有38人学习浏览适合需要完整可运行项目以快速上手Java Web与小程序开发的学习者。1. 火锅店点餐系统的技术栈为什么偏偏是 SSM 加微信小程序火锅店最忙的晚市服务员一手菜单一手点菜宝在桌台间来回跑顾客催加菜、后厨喊单、前台算错账任何一环卡住整店体验就崩了。用 JavaSSMMySQL微信小程序做的火锅店点餐系统本质就是把这三件事搬进手机顾客在小程序里选锅底、挑荤素、定辣度、提交订单SSM 后端接收请求并完成下单事务MySQL 落库菜品和订单数据。对做毕设的同学来说这个组合技术栈不花哨但覆盖面广——Spring 的依赖注入和事务、SpringMVC 的接口映射、MyBatis 的动态 SQL、小程序的生命周期与本地缓存全是面试常考点。下面按从零搭这类订单系统的顺序推进数据模型与接口先行SSM 后端跟上小程序对接最后落到部署验证和 MySQL 优化。2. 先定 ER 图和接口再写代码SSM 分层结构与火锅店点餐的 MySQL 建表毕设项目最常见的烂尾原因不是代码写不完而是表结构先烂了订单状态不知道该放哪、菜品价格和订单价格混在一个字段、表之间没有外键也没有索引后端越写越拧巴。所以我习惯先把 ER 图和接口定下来再谈实现这一步省下的返工时间远超画图那点功夫。2.1 SSM 三个框架各管什么小程序和服务端怎么对接SSM 是 Spring、SpringMVC、MyBatis 的缩写拆开看职责很清晰Spring 管理对象和事务SpringMVC 处理 HTTP 请求的映射和参数绑定MyBatis 负责 SQL 与 Java 对象的转换。小程序和服务端的对接方式是 HTTP JSON 接口小程序端wx.request发请求后端RestController返回统一结构的 JSON。返回格式建议固定成{ code: 0, msg: ok, data: {} }code为 0 表示成功非 0 是业务错误码。前端只判断code不必为每个接口写一套 if/else。这个约定要在写第一个接口之前定下来前后端各存一份联调时才不会互相等。先把接口清单立住后端和小程序照着实现功能方法路径入参返回 data微信登录POST/api/user/login{ code }userId菜品分类GET/api/category/list无分类数组菜品列表GET/api/dish/listcategoryId菜品数组创建订单POST/api/order/createuserId, tableId, items[]orderId模拟支付POST/api/order/payorderIdpayTime订单列表GET/api/order/listuserId, status订单数组表里的接口基本就是小程序所有页面的数据来源。登录接口比较特殊传的不是用户名密码而是wx.login返回的临时 code菜品列表是只读接口查询时记得过滤status 0的下架菜品创建订单和支付两个接口一个写主表和明细一个改状态是后面事务和状态机的核心。2.2 点餐系统的 ER 图与建表 SQL用户、菜品、订单明细怎么落库先画 ER 图再建表。用户和订单是一对多一个订单对应多条订单明细菜品分类对菜品是一对多菜品和订单明细不建外键明细里存的是下单时的快照。桌台不单独建主表作为订单的属性table_id存放扫码进来的桌号直接落这里。下面这套建表 SQL 是 MySQL 5.7 和 8.0 都能直接跑通的最小版本-- 用户表小程序端通过 openid 识别身份不存密码 create table t_user ( id int primary key auto_increment, openid varchar(64) not null unique, nickname varchar(50), avatar varchar(255), create_time datetime default current_timestamp ) engine innodb default charset utf8mb4 comment 小程序用户; -- 菜品分类锅底、荤菜、素菜、小吃 create table t_category ( id int primary key auto_increment, name varchar(30) not null, sort int default 0 ) engine innodb default charset utf8mb4 comment 菜品分类; -- 菜品表price 用 decimal不用 float create table t_dish ( id int primary key auto_increment, category_id int not null, name varchar(50) not null, price decimal(10, 2) not null, stock int not null default 0, image varchar(255), status tinyint default 1 comment 1上架 0下架, create_time datetime default current_timestamp, key idx_category (category_id) ) engine innodb default charset utf8mb4 comment 火锅菜品; -- 订单主表status 用整数状态机 create table t_order ( id bigint primary key auto_increment, order_no varchar(32) not null, user_id int not null, table_id varchar(20), total_amount decimal(10, 2) not null, status tinyint default 0 comment 0待支付 1已支付 2制作中 3已完成 4已取消, remark varchar(200) comment 辣度/忌口备注, create_time datetime default current_timestamp, pay_time datetime, unique key uk_order_no (order_no), key idx_user_time (user_id, create_time) ) engine innodb default charset utf8mb4 comment 订单主表; -- 订单明细冗余菜名和价格保留下单快照 create table t_order_item ( id bigint primary key auto_increment, order_id bigint not null, dish_id int not null, dish_name varchar(50), price decimal(10, 2) not null, count int not null, key idx_order (order_id) ) engine innodb default charset utf8mb4 comment 订单明细;几个值得记住的设计用户表不存密码用openid唯一标识这是小程序登录的通行做法order_no有唯一键顾客和客服查单都靠它不用自增 id 对外暴露订单明细冗余dish_name和price菜品改名或调价后历史订单仍然能看到当时的菜名和价格这叫快照冗余点餐、外卖系统里是标配。2.3 建表时的三个硬规矩金额类型、索引顺序、快照冗余金额一律decimal(10,2)。float/double是二进制近似存储0.1 0.2会得到0.30000000000000004对账时能查出鬼来。Java 侧对应BigDecimal不要用Double接收价格。库存用整型扣减靠条件更新。update t_dish set stock stock - #{count} where id #{id} and stock #{count}影响行数为 0 就是库存不足比先 select 再 update 少一次查询还能避免并发超卖。索引跟着高频查询走。顾客端最高频的查询是按用户查订单按时间倒序所以建(user_id, create_time)联合索引order_no加唯一索引按单号查订单可以走到const。这个差别在数据量上万之后会非常明显第五章专门验证。提示建表阶段把这三条定死后面 Controller、Service、Mapper 怎么写都不会出大格。最怕的是中途发现金额类型错了改表结构连带改所有 SQL 和实体类。3. SSM 后端实现Controller-Service-Mapper 三层把登录、下单、扣库存串起来表结构定好之后后端就是顺着分层把接口一个个填上。SSM 项目最忌把业务逻辑堆在 Controller 里我的习惯是 Controller 只做参数接收和结果包装Service 处理业务Mapper 只碰 SQL谁越界谁难看。3.1 Maven 工程结构与三个配置文件先让 Spring 容器转起来用 Maven 建工程目录结构按包名com.hotpot组织hotpot-server ├── pom.xml └── src/main ├── java/com/hotpot │ ├── controller # 接口层RestController │ ├── service # 业务层事务在这里 │ ├── dao # MyBatis Mapper 接口 │ ├── entity # 实体类 │ └── common # Result 包装、异常类 └── resources ├── spring-mybatis.xml ├── spring-mvc.xml ├── jdbc.properties └── mapper # OrderMapper.xml 等 SQL 文件Spring 容器启动顺序值得注意web.xml里的ContextLoaderListener先加载spring-mybatis.xml创建根容器DispatcherServlet再加载spring-mvc.xml创建子容器子容器能看到父容器的 Bean反之不行。所以 Service、Mapper 放进根容器Controller 放进子容器。各文件职责如下配置文件职责关键配置web.xml启动入口ContextLoaderListener、DispatcherServletspring-mybatis.xml数据源、事务、会话工厂jdbc.properties、MapperScannerConfigurerspring-mvc.xml接口层注解驱动、Controller 包扫描jdbc.properties数据库连接url、username、password面试八股里常问的 SpringMVC 执行流程——请求先进DispatcherServlet经HandlerMapping找到 Controller 方法返回后由视图解析器处理——在这个项目里就是一次wx.request从进入到 JSON 返回的完整路径。你也可以借此把Spring 容器和 SpringMVC 容器什么关系讲清楚这是比背流程更有区分度的答法。3.2 微信登录接口wx.login 的 code 换取 openidRestController RequestMapping(/api/user) public class UserController { Autowired private UserService userService; PostMapping(/login) public Result login(RequestBody MapString, String params) { // 小程序端 wx.login 返回的临时 code5 分钟有效 String code params.get(code); String openid userService.code2Openid(code); Integer userId userService.findOrCreate(openid); return Result.ok(userId); } }Service 里code2Openid做的事是拿 code 请求微信的jscode2session接口把返回的 openid 在t_user里查一遍没有就插入新用户并返回自增 id。同一微信号在同一个小程序里的 openid 是固定的天然适合当用户主键。注意appid和secret只能放后端配置文件小程序端发出去的任何请求别人都能看到把 secret 写进小程序代码等于把钥匙挂在门口。3.3 创建订单的 Transactional 与乐观锁扣库存下单接口是整套系统里最容易写错的地方。一次下单实际包含四步生成订单主记录、遍历购物车明细、逐条扣库存、算总金额。四步要么全部成功要么全部回滚所以 Service 方法上必须加事务Service public class OrderServiceImpl implements OrderService { Override Transactional(rollbackFor Exception.class) public Long createOrder(CreateOrderDTO dto) { String orderNo generateOrderNo(); // 日期 随机数保证唯一 Order order new Order(); order.setOrderNo(orderNo); order.setUserId(dto.getUserId()); order.setTableId(dto.getTableId()); order.setStatus(0); // 待支付 order.setRemark(dto.getRemark()); // 辣度、忌口写这里 orderMapper.insert(order); BigDecimal total BigDecimal.ZERO; for (ItemDTO item : dto.getItems()) { // 条件更新影响行数为 0 说明库存不足 int rows orderMapper.deductStock(item.getDishId(), item.getCount()); if (rows 0) { throw new BizException(菜品库存不足 item.getDishName()); } Dish dish dishMapper.selectById(item.getDishId()); OrderItem oi new OrderItem(); oi.setOrderId(order.getId()); oi.setDishId(dish.getId()); oi.setDishName(dish.getName()); // 快照 oi.setPrice(dish.getPrice()); // 快照 oi.setCount(item.getCount()); orderItemMapper.insert(oi); total total.add(dish.getPrice().multiply(BigDecimal.valueOf(item.getCount()))); } order.setTotalAmount(total); orderMapper.updateAmount(order.getId(), total); return order.getId(); } }对应 Mapper 里的扣库存 SQL 就是 2.3 说的条件更新update iddeductStock update t_dish set stock stock - #{count} where id #{dishId} and stock #{count} /update提示Transactional默认只对RuntimeException回滚自定义业务异常要么继承RuntimeException要么在注解上写死rollbackFor Exception.class。见过太多 SSM 项目事务没生效一查是异常被 try/catch 吞掉或者异常类型不对事务根本没机会回滚。3.3.1 订单状态机待支付、已支付、制作中、已完成订单从创建到完成至少要经历四个状态0 待支付、1 已支付、2 制作中、3 已完成外加 4 取消。状态只允许向前流转不允许跳转或回退。实现上不写自由 if而是提供changeStatus(orderId, from, to)方法update 语句带and status #{from}影响行数为 0 就说明状态被并发改了直接报错。这样小程序、后厨、前台三端对同一订单改状态也不会乱。3.4 订单列表的 MyBatis 动态 SQL一个 select 顶三份订单查询的筛选条件在不同页面不一样顾客端只看自己的管理端可以按状态筛。用 MyBatis 的where加if标签把条件拼起来参数没传的分支自动忽略select idlistByUser resultTypeOrderVO select * from t_order where if testuserId ! nulland user_id #{userId}/if if teststatus ! nulland status #{status}/if /where order by create_time desc limit #{offset}, #{pageSize} /selectoffset的计算是(pageNum - 1) * pageSize这一步放 Service 里算别让前端传。MyBatis 的 Mapper 接口没有实现类Spring 启动时用 JDK 动态代理为每个接口生成代理对象方法调用最终落到 XML 里的 SQL这也是面试常考的MyBatis 怎么和 Spring 整合的答案核心。4. 微信小程序端实现菜品列表、购物车缓存到携带桌号提交订单后端接口就绪后小程序端要做的事很清晰启动时登录拿 userId点餐页拉分类和菜品购物车用本地缓存管理提交订单时带上桌号。用原生小程序实现完全够不必引框架。4.1 小程序目录与 app.json把启动页配成点餐主页miniprogram/ ├── app.js # 启动时 wx.login 拿 userId ├── app.json # 全局配置pages 第一项是启动页 ├── app.wxss ├── utils/ │ ├── request.js # wx.request 封装 │ └── cart.js # 购物车本地缓存 └── pages/ ├── index/ # 点餐主页分类 菜品列表 ├── cart/ # 购物车页 ├── order-confirm/ # 确认订单页桌号 备注 ├── order-list/ # 我的订单列表 └── order-detail/ # 订单详情页面数据来源对应关系是index 页调分类和菜品接口cart 页只读本地缓存order-confirm 页组合购物车缓存和桌号order-list 和 order-detail 分别调订单列表和详情接口。app.json 里pages数组的第一项就是小程序启动后进入的页面想改刚进入的加载页面把目标页挪到数组第一个位置即可。点餐类小程序通常不需要 tabBar一个主入口页面加几个跳转就能完成闭环。4.2 封装 wx.request统一 baseURL、loading 与错误提示// utils/request.js const BASE_URL http://localhost:8080/hotpot/api; function request(path, method GET, data {}) { return new Promise((resolve, reject) { wx.showLoading({ title: 加载中 }); wx.request({ url: ${BASE_URL}${path}, method, data, header: { Content-Type: application/json }, success(res) { if (res.statusCode 200 res.data.code 0) { resolve(res.data.data); } else { wx.showToast({ title: res.data.msg || 请求失败, icon: none }); reject(res.data); } }, fail(err) { wx.showToast({ title: 网络异常, icon: none }); reject(err); }, complete() { wx.hideLoading(); } }); }); } module.exports { request, BASE_URL };这个封装的要点是 Promise 化和统一收口页面里调用request(/dish/list, GET, { categoryId })拿到的直接是 data不用每处重复处理 loading 和错误弹窗。开发阶段用localhost没问题但手机真机预览时 localhost 指向手机自身要改成电脑的局域网 IP正式上线必须用已备案的 HTTPS 域名并在小程序后台配置 request 合法域名否则线上请求会被拦。这是小程序开发第一个容易卡住的地方。用 uniapp 开发的等价写法是uni.request封装思路完全一样。4.3 购物车本地缓存与辣度单选框从加菜到算总价购物车不需要服务端参与本地缓存足够。用同步 API 最简单因为购物车数据量小// utils/cart.js const KEY hotpot_cart; function getCart() { return wx.getStorageSync(KEY) || []; } function addDish(dish) { const cart getCart(); const found cart.find(item item.id dish.id); if (found) { found.count 1; } else { cart.push({ id: dish.id, name: dish.name, price: dish.price, count: 1, spicy: 微辣 }); } wx.setStorageSync(KEY, cart); } function clearCart() { wx.removeStorageSync(KEY); } module.exports { getCart, addDish, clearCart };火锅店的辣度选择适合用radio-group选中的值随购物车项一起存进本地缓存提交订单时放到 items 里后端写进订单备注或明细字段radio-group bindchangeonSpicyChange>Page({ onLoad(options) { // 扫码进入时参数在 scene 里形如 tableId12 const scene decodeURIComponent(options.scene || ); const tableId scene.split()[1] || ; this.setData({ tableId }); }, submitOrder() { const cart getCart(); if (!cart.length) { wx.showToast({ title: 请先选菜, icon: none }); return; } request(/order/create, POST, { userId: wx.getStorageSync(userId), tableId: this.data.tableId, remark: this.data.remark, items: cart.map(item ({ dishId: item.id, count: item.count, spicy: item.spicy })) }).then(orderId { clearCart(); wx.redirectTo({ url: /pages/order-detail/order-detail?orderId${orderId} }); }); } });小程序码的 scene 参数有长度限制桌号这种短参数正好适用。如果入口是普通链接带 query参数会直接出现在options里比如options.tableId。桌号能进订单后厨打单才知道送到哪桌这是扫码点餐和普通外卖点餐的实质区别。5. Tomcat 部署、MySQL 索引验证与两个能直接照抄的运维脚本5.1 打包、部署、初始化一条 curl 确认接口可用环境上 JDK 8 加 Tomcat 8.5/9 加 MySQL 5.7/8.0 最省事。装完 JDK 先配置 JAVA_HOME 和 PATH命令行java -version能正常输出再继续。项目根目录执行mvn clean package -DskipTeststarget 下生成 war 包拷到 Tomcat 的 webapps 目录启动后访问http://localhost:8080/hotpot/看到页面说明容器起来了。数据库初始化用命令行执行 SQL 文件mysql -uroot -p -e create database hotpot_db default charset utf8mb4; mysql -uroot -p hotpot_db hotpot.sql然后验证登录接口curl -X POST http://localhost:8080/hotpot/api/user/login \ -H Content-Type: application/json \ -d {code:dev-code}后端对dev-code这种本地调试值直接返回假 openid 或固定 userId这样可以不依赖微信后台把整条链路跑通真机联调时再换真实 code。这个环境值短路的技巧在前后端分离项目里很实用。5.2 订单慢查询先别加缓存用 EXPLAIN 确认联合索引生效订单量起来后最明显的慢查询是我的订单列表。先看这条 SQL 走没走索引explain select * from t_order where user_id 4 order by create_time desc limit 20;看 explain 输出里的type和key两列type是 ref、key是idx_user_time说明联合索引生效如果type是 ALL 或key是 null就是全表扫描。联合索引的列顺序要和查询条件一致user_id在前 explain 才能命中。按 order_no 查订单走唯一索引type会是 const这类查询适合客服按单号搜单。索引不是越多越好点餐系统里最热的就是这两条查询索引建到这里就够了。5.3 两个可以直接照抄的 MySQL 脚本自动备份 bat 与造数存储过程Windows 上做每日自动备份写一个批处理配合任务计划程序每天凌晨执行echo off set MYSQL_BIND:\mysql-8.0\bin set BAK_DIRD:\hotpot_backup set DB_USERroot set DB_PASS123456 set DB_NAMEhotpot_db set STAMP%date:~0,4%%date:~5,2%%date:~8,2% %MYSQL_BIN%\mysqldump -u%DB_USER% -p%DB_PASS% --default-character-setutf8mb4 %DB_NAME% %BAK_DIR%\%DB_NAME%_%STAMP%.sqlmysqldump是 MySQL 自带工具备份文件名带日期不会互相覆盖恢复时执行mysql -uroot -p hotpot_db 备份文件.sql。造测试数据则用存储过程一次生成过去 30 天里分布均匀的订单delimiter $$ create procedure gen_orders(in days int) begin declare i int default 0; while i days * 200 do insert into t_order(order_no, user_id, table_id, total_amount, status, create_time) values (concat(date_format(now(), %Y%m%d%H%i%s), lpad(i, 6, 0)), 1 floor(rand() * 20), concat(T, 1 floor(rand() * 30)), round(100 rand() * 300, 2), floor(rand() * 5), date_sub(now(), interval floor(rand() * days) day)); set i i 1; end while; end$$ delimiter ; call gen_orders(30);执行一次call gen_orders(30)生成 6000 条订单答辩前用这批数据把分页、索引和状态筛选全部验证一遍比临时手写 insert 可靠得多。delimiter的作用只是让客户端把整个过程体识别为一个语句MySQL 5.7 和 8.0 写法一致。5.4 URL Scheme让顾客从公众号直接拉起带桌号的点餐页复购场景里顾客离店后再次点餐的入口往往在公众号菜单或短信里。可以在小程序后台生成 URL Scheme形如weixin://dl/business?t签名参数用户点击后直接拉起小程序指定页面。生成 scheme 时把页面路径设为pages/index/index参数里带上 tableId这样顾客从公众号进来落地页依然是带着桌号的点餐主页。注意 scheme 有有效期和生成数量限制建议按桌台动态生成并缓存复用不要每次点击都去调接口。把这条链路和桌号参数串起来从店内扫码到店外复购的闭环就完整了——这也是答辩时比能点餐更能加分的完整度设计。本文还有配套的精品资源点击获取
