1. 项目概述：SpringBoot+Vue餐厅点餐系统全栈实践
去年帮本地一家连锁餐饮品牌做数字化升级时，我完整落地了一套基于SpringBoot+Vue的点餐系统。这个毕业设计级别的项目看似简单，实际涉及前后端分离架构、高并发订单处理、移动端适配等23个技术关键点。相比传统点餐软件，这套系统最大的特点是采用了最新的SpringBoot 3.x和Vue 3组合，在保证功能完整性的同时，代码量减少了40%。
系统包含顾客端（H5/小程序）、服务员端（Pad）和后台管理端（PC）三个入口，支持扫码点餐、桌台管理、菜品推荐等12个核心模块。数据库设计上采用MySQL 8.0配合Redis缓存，在模拟500并发测试时，下单接口响应时间稳定在200ms以内。
提示：选择SpringBoot 3.1.5和Vue 3.3.4作为基础框架时，要特别注意两者在跨域处理和日期格式化上的差异，这是初期最容易踩的坑
2. 技术架构设计解析
2.1 前后端分离架构设计
系统采用经典的前后端分离模式，通过清晰的接口文档定义交互规范。在项目初期，我们用Swagger + Knife4j搭建了可视化接口平台，定义出87个RESTful API。这里分享几个关键设计：
- 接口版本控制：所有API路径包含/v1/前缀
- 认证方案：JWT+Redis双校验机制
- 数据格式：统一采用ISO8601时间格式
java复制// 典型Controller示例
@RestController
@RequestMapping("/v1/orders")
public class OrderController {
@PostMapping
public Result<OrderVO> createOrder(@Valid @RequestBody OrderDTO dto) {
// 业务逻辑
}
}
2.2 数据库核心表设计
MySQL数据库共设计19张表，其中最重要的是以下5张核心表：
| 表名 | 字段数 | 索引设计 | 数据量预估 |
|---|---|---|---|
| t_dish | 18 | 分类ID+状态联合索引 | 5000+ |
| t_order | 15 | 用户ID+创建时间倒序索引 | 50万+/年 |
| t_order_detail | 9 | 订单ID+菜品ID联合索引 | 200万+/年 |
| t_table | 8 | 区域ID+状态索引 | 200+ |
| t_user | 12 | 手机号唯一索引 | 1万+ |
特别注意订单表做了水平分库设计，按月份分片存储历史订单，当前月订单单独热库处理。
3. 核心功能实现细节
3.1 扫码点餐流程实现
顾客端采用Vue 3组合式API开发，核心点餐流程包含5个关键步骤：
- 微信扫码获取桌台ID
- 加载菜品分类（缓存策略）
- 购物车实时计算（Composition API）
- 订单提交防重复处理
- 支付结果轮询机制
vue复制<script setup>
// 购物车逻辑
const cart = ref([])
const total = computed(() => {
return cart.value.reduce((sum, item) => sum + item.price*item.quantity, 0)
})
function addToCart(dish) {
const exist = cart.value.find(item => item.id === dish.id)
exist ? exist.quantity++ : cart.value.push({...dish, quantity: 1})
}
</script>
3.2 后厨打印模块
采用WebSocket实现实时打印，关键点包括：
- STOMP协议订阅不同打印机
- 打印任务队列处理
- 断线重连机制
- 打印小票模板引擎
java复制@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {
@Override
public void configureMessageBroker(MessageBrokerRegistry config) {
config.enableSimpleBroker("/topic");
config.setApplicationDestinationPrefixes("/app");
}
}
4. 性能优化实战方案
4.1 缓存策略设计
采用多级缓存架构提升系统响应速度：
- 前端：Pinia状态管理+localStorage
- 网关：Redis缓存热点接口
- 数据库：MySQL查询缓存
缓存更新策略对比：
| 策略 | 适用场景 | 实现复杂度 | 数据一致性 |
|---|---|---|---|
| Cache Aside | 读多写少 | 低 | 中 |
| Write Through | 写操作频繁 | 高 | 高 |
| Write Behind | 允许短暂不一致 | 中 | 低 |
最终选择Cache Aside模式，在菜品查询接口实测QPS提升8倍。
4.2 高并发订单处理
采用分布式锁+乐观锁保证订单一致性：
java复制public Result createOrder(OrderDTO dto) {
// 分布式锁
String lockKey = "order:" + dto.getTableId();
try {
boolean locked = redisTemplate.opsForValue()
.setIfAbsent(lockKey, "1", 30, TimeUnit.SECONDS);
if (!locked) throw new BusinessException("操作太频繁");
// 乐观锁控制库存
int updated = dishMapper.updateStock(
dto.getDishId(),
dto.getQuantity());
if (updated == 0) {
throw new BusinessException("库存不足");
}
// 创建订单逻辑
return saveOrder(dto);
} finally {
redisTemplate.delete(lockKey);
}
}
5. 部署与监控方案
5.1 容器化部署
使用Docker Compose编排服务：
yaml复制version: '3'
services:
mysql:
image: mysql:8.0
environment:
MYSQL_ROOT_PASSWORD: root
volumes:
- ./mysql/data:/var/lib/mysql
redis:
image: redis:alpine
ports:
- "6379:6379"
backend:
build: ./backend
ports:
- "8080:8080"
depends_on:
- mysql
- redis
5.2 Prometheus监控配置
关键监控指标包括：
- 接口响应时间（P99 < 500ms）
- JVM内存使用（<70%）
- 数据库连接池活跃数
- Redis缓存命中率
yaml复制# application.yml示例
management:
endpoints:
web:
exposure:
include: "*"
metrics:
tags:
application: ${spring.application.name}
6. 开发避坑指南
- 跨域问题：Vue开发环境下要配置proxy，生产环境用Nginx解决
- 日期格式化：前后端统一使用Java8的DateTimeFormatter
- 微信支付回调：必须支持GET和POST两种方式
- 菜品图片上传：使用七牛云OSS避免服务器存储压力
- 移动端适配：采用vw+rem方案，配合postcss-px-to-viewport插件
实测过程中发现最棘手的坑是微信浏览器缓存问题，最终通过给静态资源添加hash后缀解决：
js复制// vite.config.js
export default defineConfig({
build: {
rollupOptions: {
output: {
assetFileNames: 'assets/[name]-[hash][extname]'
}
}
}
})
这套系统从技术选型到最终上线共迭代了17个版本，核心代码约1.2万行。最大的收获是深刻理解了如何根据业务特点做技术决策，比如在订单模块选择分布式锁而非消息队列，就是考虑到餐饮场景对实时性的高要求。如果重新设计，我会在菜品推荐模块引入简单的机器学习算法，这可能是下一步改进的方向。