简介这是一份基于SSM框架的星巴克咖啡店管理系统毕业设计文档专门面向Java方向的学生、毕业设计选题者及中小型餐饮信息化开发人员。文档围绕B/S架构采用Java语言、MySQL数据库与Tomcat服务器实现咖啡信息管理、订单处理、库存监控、员工考勤和财务管理等核心模块的数字化管理完整覆盖需求分析、可行性分析、技术选型、功能设计、数据库结构设计以及系统功能测试等环节能帮助读者快速理解Spring、SpringMVC和MyBatis三个框架的整合方式并直接复用其中的项目文档结构。资源共1个文件为docx格式压缩包约3.37MB已有49人浏览学习。文档中不仅展示了各主要功能模块的设计界面和操作说明还详细阐述了数据库表设计思路与测试要点可作为高校毕业设计撰写模板和模块划分参考同时也为咖啡店等连锁餐饮企业的信息化改造提供了可落地的系统方案。1. 基于 Java 的星巴克咖啡店管理系统在解决什么业务闭环与选型方向在后端岗位上摸过一阵子的人都会遇到一类项目基于 Java 的星巴克咖啡店管理系统或者类似的商品/进销存后台管理系统。它不只是把 CRUD 拼在一起核心难点是让点单、支付、库存、会员和报表形成一条不丢数据、不超卖的闭环。这类系统特别适合拿来做 Java 后台管理系统的练手也是很多工程师第一次独立负责一个小型全栈项目时的常见课题。我就按自己的落地习惯把需求拆分、数据库设计、后端接口、前端联调以及高频踩坑点完整过一遍让你拿到标题后能知道先做什么、后做什么以及哪些参数必须调。2. 需求拆分与数据库设计先想清楚业务边界再写建表语句2.1 咖啡店业务的三个闭环点单、库存、报表星巴克咖啡店表面看是卖咖啡但落到管理系统里其实是三个业务闭环。第一个是点单-支付-制作顾客确认订单后生成订单头和明细支付成功进入制作列表第二个是制作-扣库存每一杯咖啡背后是咖啡豆、牛奶、糖浆这些原料卖出商品时扣的是原料库存不是虚拟的商品库存第三个是营业对账-报表每天按门店、按员工、按商品统计销售额和销量管理层用来做决策。常见做法是把这三个闭环画成流程图我推荐用一张状态机图把订单生命周期定下来待支付、已支付、制作中、已完成、已取消。这里有一个很重要的边界取消订单发生在哪个状态待支付时可以随便取消已支付后取消要触发退款和库存回补制作中取消要区分是否已经开始制作。新手最容易把取消逻辑写成一刀切后面对账必出问题。功能模块先列清楚方便后面建表时对号入座模块核心场景关键数据商品管理分类、SKU、上下架category, product, sku订单管理下单、支付、取消、退款orders, order_item会员管理注册、余额、积分customer库存管理入库、扣减、预警、流水sku.stock, stock_log报表管理日销售、单品排行、会员消费orders, order_item这不是给星巴克官方做的系统而是给一个可运行的门店后台做的设计。别把需求做成全供应链采购、物流、排班这些可以先放掉。我一般把多门店的store_id提前加到所有核心表里哪怕现在只有一个门店后面扩展分店时不需要回填数据。2.2 核心表结构订单明细独立成表金额冗余但可控数据库用 MySQL引擎统一 InnoDB字符集 utf8mb4。主键用自增 id 可以但业务唯一键一定要单独建立比如订单号order_no。外键不要加让业务层保证一致性不然高并发下外键会变成锁瓶颈。订单主表的建表语句CREATE TABLE orders ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单号业务唯一, customer_id bigint DEFAULT NULL COMMENT 会员id散客为NULL, store_id bigint NOT NULL COMMENT 门店id预留多门店, total_amount decimal(10,2) NOT NULL DEFAULT 0.00 COMMENT 订单总额冗余汇总, status tinyint NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2制作中 3已完成 4已取消, pay_type tinyint DEFAULT NULL COMMENT 1微信 2支付宝 3余额, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_store_status (store_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单主表;关键点total_amount是冗余字段它由明细汇总而来。为什么要冗余因为列表页、报表页经常只查订单头每次 join 明细会让查询变慢。冗余的代价是必须保证一致性所以我在事务里写订单头时一定是从明细算好再写入而不是先写头再回头改。status用 tinyint不用 varchar配合状态机更省空间。订单明细表要保留商品快照CREATE TABLE order_item ( id bigint NOT NULL AUTO_INCREMENT, order_id bigint NOT NULL, sku_id bigint NOT NULL, product_name varchar(64) NOT NULL, sku_name varchar(64) NOT NULL COMMENT 规格名如中杯/大杯/超大杯, quantity int NOT NULL, unit_price decimal(10,2) NOT NULL COMMENT 成交单价快照, subtotal decimal(10,2) NOT NULL, PRIMARY KEY (id), KEY idx_order_id (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单明细;product_name、sku_name、unit_price都是快照商品改名改价不影响历史订单。subtotal在代码里算好不要在查询时再乘避免每个接口重复写乘法也避免顺序问题导致精度不一致。SKU 表里直接带库存和乐观锁版本号CREATE TABLE sku ( id bigint NOT NULL AUTO_INCREMENT, product_id bigint NOT NULL, name varchar(32) NOT NULL COMMENT 规格名称, price decimal(10,2) NOT NULL COMMENT 基础价, delta_price decimal(10,2) NOT NULL DEFAULT 0.00 COMMENT 加价如加3元, stock int NOT NULL DEFAULT 0, version int NOT NULL DEFAULT 0 COMMENT 乐观锁版本号, status tinyint NOT NULL DEFAULT 1, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;version字段用于乐观锁后面下单会用到。如果你不想加 version也可以只用stock qty条件更新但有了 version 可以顺便做更精细的并发控制。最后是库存流水表这是排障的后悔药CREATE TABLE stock_log ( id bigint NOT NULL AUTO_INCREMENT, sku_id bigint NOT NULL, change_type tinyint NOT NULL COMMENT 1入库 2扣减 3回补, change_qty int NOT NULL, after_qty int NOT NULL, order_id bigint DEFAULT NULL, created_at datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_sku_id (sku_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT库存流水;有了流水如果发现库存对不上可以按时间倒排查订单比对after_qty是否连续。没有这张表对账就只能一张张翻订单那是真的想骂人。2.3 金额、状态和时间的硬约束float 不能用状态流转要收口数据库里金额全部用decimal(10,2)Java 对应 BigDecimal千万别用 double。为什么0.10.2 在二进制浮点里不等于 0.3订单汇总差一分钱对账的时候就是血泪经验。MyBatis-Plus 的实体类字段用 BigDecimalMySQL 的 decimal 会自动映射不需要额外处理。状态字段我一般用整数枚举而不是字符串。Java 侧定义枚举public enum OrderStatus { PENDING(0, 待支付), PAID(1, 已支付), MAKING(2, 制作中), COMPLETED(3, 已完成), CANCELED(4, 已取消); private final int code; private final String desc; OrderStatus(int code, String desc) { this.code code; this.desc desc; } public static boolean canTransit(int from, int to) { // 只允许: 0-1, 1-2, 2-3, 0-4, 1-4 return false; } }状态流转的合法性校验要集中在一个方法里业务代码里不要到处写if status 1。比如订单支付时只允许待支付转已支付不然重复点击支付会把已支付订单再刷一次。canTransit方法里用 switch 或者查表实现这里只写注释不展开。时间字段数据库用 datetimeJava 用 LocalDateTime连接参数serverTimezoneAsia/Shanghai。统一时区是底线不然避坑章节里还会再撞上。另外不用外键而是用索引加应用层逻辑。咖啡店系统并发量不算高但订单表会持续增长外键在插入和更新时会让数据库多一次一致性检查容易成为性能浪费。商品删除用软删除不直接物理删这也算行业惯例。3. Spring Boot 后端落地项目结构、登录鉴权和下单事务3.1 项目结构三层分包与 Maven 依赖怎么配Spring Boot 项目我会用官方 Initializr 生成然后调整成 controller/service/mapper/entity/common/config。不要把所有类放一个包这不是强迫症是给后面的排障留线索。典型结构src/main/java/com/starbucks ├── common/ # 统一返回体、异常、常量 │ ├── Result.java │ ├── BusinessException.java │ └── GlobalExceptionHandler.java ├── config/ # 拦截器、Jackson、CORS 配置 ├── controller/ # 接口层 ├── service/ # 业务层 │ └── impl/ ├── mapper/ # MyBatis-Plus Mapper ├── entity/ # 数据库实体 ├── dto/ # 入参对象 └── vo/ # 出参对象controller 里不写 SQLservice 里不写 HTTP 参数解析mapper 只负责持久化。这样接口改动成本最低后面前端字段变了只改 VO 和 DTO不影响 service 核心逻辑。Maven 依赖关键部分dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-api/artifactId version0.11.5/version /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-impl/artifactId version0.11.5/version scoperuntime/scope /dependency /dependenciesMyBatis-Plus 3.5.x 是目前稳定常用版本如果你用 Spring Boot 2.x 完全没问题如果你用 Spring Boot 3.x注意 starter 的包名变化。这里不追求最新稳定最重要。3.2 JWT 登录鉴权用拦截器放行登录其余接口都要校验登录接口实现RestController RequestMapping(/api/auth) public class AuthController { Autowired private UserService userService; PostMapping(/login) public ResultString login(RequestBody LoginDTO dto) { User user userService.findByUsername(dto.getUsername()); if (user null || !userService.checkPassword(dto.getPassword(), user.getPassword())) { throw new BusinessException(用户名或密码错误); } return Result.ok(JwtUtil.createToken(user.getId(), user.getRole())); } }密码不能明文存至少用 BCrypt 加密checkPassword里做校验。接着是拦截器public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String auth request.getHeader(Authorization); if (auth ! null auth.startsWith(Bearer )) { try { Claims claims JwtUtil.parseToken(auth.substring(7)); request.setAttribute(userId, Long.valueOf(claims.getSubject())); request.setAttribute(role, claims.get(role, String.class)); return true; } catch (Exception e) { return writeUnauthorized(response); } } return writeUnauthorized(response); } private boolean writeUnauthorized(HttpServletResponse response) throws IOException { response.setStatus(401); response.setContentType(application/json;charsetUTF-8); response.getWriter().write({\code\:401,\msg\:\未登录或登录过期\}); return false; } }注册拦截器时放行登录接口Configuration public class WebConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new AuthInterceptor()) .addPathPatterns(/api/**) .excludePathPatterns(/api/auth/login); } }JWT 密钥在JwtUtil里用于演示直接生成真实项目要从配置读取不然每次重启密钥变化旧 token 全部失效。这个坑很容易忽略。过期时间我设了 8 小时后台管理系统够用。如果你担心 token 泄露可以加 refresh token但小系统先不要过度设计。3.3 下单接口事务与乐观锁把并发扣库存放在一条 SQL 里下单核心逻辑Service public class OrderServiceImpl implements OrderService { Autowired private OrdersMapper ordersMapper; Autowired private OrderItemMapper orderItemMapper; Autowired private SkuMapper skuMapper; Autowired private StockLogMapper stockLogMapper; Override Transactional(rollbackFor Exception.class) public OrderVO createOrder(CreateOrderDTO dto) { String orderNo generateOrderNo(dto.getStoreId()); Long exist ordersMapper.selectCount(new LambdaQueryWrapperOrders() .eq(Orders::getOrderNo, orderNo)); if (exist 0) { throw new BusinessException(订单号重复请重试); } Orders order new Orders(); order.setOrderNo(orderNo); order.setStoreId(dto.getStoreId()); order.setCustomerId(dto.getCustomerId()); order.setStatus(OrderStatus.PENDING.getCode()); order.setTotalAmount(BigDecimal.ZERO); ListOrderItem itemList new ArrayList(); for (CreateOrderDTO.Item itemDTO : dto.getItems()) { int rows skuMapper.deductStock(itemDTO.getSkuId(), itemDTO.getQuantity()); if (rows 0) { throw new BusinessException(库存不足或商品不存在); } Sku sku skuMapper.selectById(itemDTO.getSkuId()); OrderItem item new OrderItem(); item.setSkuId(sku.getId()); item.setProductName(sku.getProductName()); item.setSkuName(sku.getName()); item.setQuantity(itemDTO.getQuantity()); item.setUnitPrice(sku.getPrice().add(sku.getDeltaPrice())); item.setSubtotal(item.getUnitPrice().multiply(BigDecimal.valueOf(itemDTO.getQuantity()))); itemList.add(item); } order.setTotalAmount(itemList.stream() .map(OrderItem::getSubtotal) .reduce(BigDecimal.ZERO, BigDecimal::add)); ordersMapper.insert(order); for (OrderItem item : itemList) { item.setOrderId(order.getId()); orderItemMapper.insert(item); } return OrderVO.from(order); } }这段代码有一个隐藏细节先扣库存再查 SKU 信息。为什么不在扣库存前查因为查了也没用库存判断必须由 UPDATE 语句完成否则就有并发风险。如果扣库存成功说明商品存在且有货再查详情做快照顺序不影响正确性。事务方法里发生异常时Transactional会回滚所以中间抛错库存扣减也会回滚。幂等性我用了服务端生成的订单号做唯一约束但generateOrderNo如果包含随机数重复点击会产生不同订单号幂等就失效了。常见做法是前端在下单时生成一个clientRequestId后端用这个 ID 做唯一键。为了演示我写的是服务端生成实际项目最好接收客户端幂等键。Mapper 里的扣库存 SQLpublic interface SkuMapper extends BaseMapperSku { Update(UPDATE sku SET stock stock - #{qty}, version version 1 WHERE id #{skuId} AND stock #{qty}) int deductStock(Param(skuId) Long skuId, Param(qty) Integer qty); }这条 SQL 是防超卖的关键。如果库存充足两个并发请求都执行数据库行锁会让第二个等待第一个成功第二个再执行时 stock 可能已经不足影响行数为 0抛异常。这是单体应用里最简单可靠的方案。4. 前端后台实现与联调Vue3 Element Plus 的页面骨架4.1 动态菜单和路由后端给菜单前端按权限注册前端项目用 Vite Vue3 Element Plus。我不推荐把菜单写死在路由表里因为后台管理系统通常有多个角色店长、收银员、库存管理员。后端登录时返回菜单列表前端动态注册路由。菜单数据格式[ { path: /order/list, name: OrderList, meta: { title: 订单管理, icon: list } } ]前端使用router.addRoute动态添加const modules import.meta.glob(../views/**/*.vue); function addDynamicRoutes(menus) { menus.forEach(menu { const component modules[../views${menu.path}/index.vue]; router.addRoute({ path: menu.path, name: menu.name, component, meta: menu.meta }); }); }这里让前端页面路径与后端返回的 path 保持一致减少映射表维护。如果菜单较多注意在路由守卫里加一个“已加载”标记避免刷新后重复注册。4.2 点单页与订单提交购物车状态管理的核心代码点单页是咖啡店系统的门面。购物车状态用 Vue3 组合式 API 管理const cart ref([]); function addSku(sku) { const line cart.value.find(item item.skuId sku.id); if (line) { line.quantity 1; } else { cart.value.push({ skuId: sku.id, productName: sku.productName, skuName: sku.name, priceInCents: sku.priceInCents, // 后端返回以分为单位的整数 quantity: 1 }); } } const totalAmount computed(() cart.value.reduce((sum, item) sum item.priceInCents * item.quantity, 0) );价格用“分”为单位避免浮点误差这是我个人的习惯。后端在 SKU 接口里返回priceInCents整数前端做整数运算展示时再除以 100。提交订单时只传商品数量和会员 ID总价由后端计算。提交订单async function submitOrder() { const res await api.post(/order/create, { customerId: currentCustomerId.value, storeId: currentStoreId.value, items: cart.value.map(item ({ skuId: item.skuId, quantity: item.quantity })) }); if (res.code 0) { ElMessage.success(下单成功); cart.value []; } }前端不传金额只传商品数量和会员 ID总价由后端计算避免用户构造参数改价格。这条原则适用于所有交易系统金额永远以服务端为准。4.3 联调的三个坑跨域代理、日期回显、金额类型第一个是跨域。Vite 开发服务器端口是 5173后端是 8080浏览器直接请求会跨域。我是用代理而不是后端加 CORS// vite.config.js export default { server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }这样前端请求/api/xxx会被转发到后端 8080。生产环境用 Nginx 做同样的事。第二个是日期回显。后端返回 LocalDateTimeJackson 默认序列化成数组或 ISO 字符串前端显示很难看。统一配置spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai这个是全局 ObjectMapper 配置LocalDateTime 在 JavaTimeModule 下会使用该格式。第三个是金额类型。后端返回 BigDecimal 时Jackson 默认转成 numberJavaScript 处理大数字有精度隐患。解决方法是给 VO 里的金额字段加注解JsonSerialize(using ToStringSerializer.class) private BigDecimal totalAmount;或者干脆在 VO 里定义为 String。总额精度丢失比日期错乱更隐蔽所以一定要在接口层就处理。5. 排查手记让系统翻车的五个高频坑5.1 现象订单汇总金额对不上原因double 精度丢失解决decimal 加 BigDecimal有一次测试发现今天订单总额是 458.13但明细把单价乘数量加起来是 458.12差一分钱。一开始以为是 SQL 写错后来发现订单明细表的单价字段用的是 doubleJava 实体也用 Double。MySQL 里 Double 是浮点0.29 在内存里可能是 0.29000000000000004乘以 2 就是 0.5800000000000001最后汇总出问题。原因就是二进制浮点无法精确表示十进制小数只要涉及乘除法就必然有误差。解决把数据库字段改成decimal(10,2)Java 实体改成 BigDecimal。注意在 MyBatis-Plus 中BigDecimal 字段映射没问题但如果你在 service 里用了 Double 做中间计算精度会被污染回去。所以约定所有金额相关的实体、DTO、VO 全部用 BigDecimal不用 Double/Float。如果前端需要传金额比如退款后端要拒绝 Double 类型参数用 String 接收再new BigDecimal。我在接口参数里为此加过校验注解防止有人传 0.1 被转成 0.100000000000000005。5.2 现象库存被扣成负数原因先查再改解决update 条件扣减模拟两个收银员同时卖最后一杯咖啡页面都显示库存 1两个订单都成功库存变成 -1。原因是代码先查库存if stock 0失败再update stock stock - 1。两个请求都读到 1都通过 if然后 update 时没有 where 条件限制导致都成功。解决把“判断”和“扣减”合并为一条 update 语句WHERE 里带上stock qty。前面 3.3 已经给了 SQL这里再强调不要先 select 再 update除非加悲观锁for update但那样并发性能差。条件更新返回影响行数为 0 就抛异常。这个方案在单体应用和多数并发场景下够用。如果要做跨天对账可以在stock_log里记录after_qty一旦发现负库存比对流水很快定位是哪个订单扣的。没有流水只能翻库这就是血泪经验。5.3 现象接口偶发超时原因连接池占满解决HikariCP 参数调优系统上线两周后每天下午高峰期订单接口偶发 2-3 秒延迟偶尔报“连接不可用”。重启后恢复过几天又来。查日志发现是数据库连接池获取连接超时。原因HikariCP 默认maximum-pool-size是 10而应用里有个报表接口查询没有走索引每次扫描 20 万行订单占住连接 800ms。高峰期 20 个请求就把连接池打满正常订单接口只能排队等连接。解决先优化慢查询给orders表的created_at和store_id建联合索引。然后调连接池到合理大小spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 30000 idle-timeout: 600000连接池不是越大越好20 个连接对于中小型门店后台足够单库连接太多反而增加数据库线程上下文切换。关键是连接池参数要和慢查询一起改不然临时调大只是推迟问题。5.4 现象前端时间比本地晚 8 小时原因时区三处不一致解决统一 Asia/Shanghai测试环境日期显示 2025-06-01 08:00但数据库里的created_at存的是 2025-06-01 00:00。前端用 dayjs 格式化后变成 2025-06-01 08:00用户以为订单是在早上 8 点下的。原因MySQL 连接 URL 里没指定serverTimezoneJDBC 驱动用了服务器 UTCSpring Boot 的 Jackson 默认用 JVM 时区JVM 时区又可能是 UTC前端浏览器在中国显示时又加上 8 小时。三个环节各加一次时间就漂移了。解决统一三处。数据库连接 URLjdbc:mysql://localhost:3306/starbucks?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiSpring Boot 配置spring: jackson: time-zone: Asia/Shanghai date-format: yyyy-MM-dd HH:mm:ss如果上面还不行检查代码里是不是用了new Date()或System.currentTimeMillis()这些和 JVM 默认时区相关。数据库服务器如果是 Docker 容器也可能默认 UTC在 MySQL 启动参数加--default-time-zone08:00。5.5 现象上传图片重启后丢失原因本地绝对路径解决可配置存储目录商品图片上传成功页面也显示但系统重启或重新部署后图片全部 404。原因上传时把文件写到了项目目录下的 uploads 文件夹或者写了 /tmp 下的临时目录打包发布后目录被重建或清空。解决把上传目录做成配置项并挂载到服务器固定位置app: upload-dir: /data/starbucks/imagesController 里写入该目录然后通过资源映射访问Configuration public class StaticResourceConfig implements WebMvcConfigurer { Value(${app.upload-dir}) private String uploadDir; Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/images/**) .addResourceLocations(file: uploadDir /); } }这个配置还能顺带解决备份问题直接备份 /data 目录即可。生产环境建议考虑对象存储但小系统用固定目录加 Nginx 反代已经够。6. 验证到扩展让系统可持续演进的三个习惯6.1 用接口自测清单做回归没有自动化也有一条能点的路径项目交付前我会维护一张接口自测清单按业务顺序点一遍。这张表既是验收单也是回归测试的底线。接口方法请求参数预期结果/api/auth/loginPOSTadmin/123456返回 token/api/order/createPOSTskuId1, qty2订单号生成库存减少/api/order/payPOSTorderId状态变已支付/api/report/dailyGETdate返回当日销售额先用 curl 拿 tokencurl -X POST http://localhost:8080/api/auth/login \ -H Content-Type: application/json \ -d {username:admin,password:123456}然后后续请求带上Authorization: Bearer token。每次改动完按顺序点一遍能发现八成的问题。6.2 三个扩展位套餐、优惠券、多门店一开始就留好字段第一个扩展是套餐。套餐本质是商品组需要新建combo表和combo_item表下单时同时校验套餐内商品的库存。第二个是优惠券优惠券与用户、订单关联注意“券前金额”和“实付金额”要分开存否则对账时很痛苦。第三个是多门店我已经在所有核心表里加了store_id后面只要增加门店表和分店员工报表按store_id汇总即可。我早期做咖啡店项目时没有加库存流水库存对不上只能一边骂一边翻订单后来在新项目里第一张表就是stock_log排障几分钟搞定。设计系统时把可追踪性放在第一位比追求花哨功能管用得多。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/30 17:02:47 · 阅读 1.2k 星巴克咖啡店管理系统实战：Java后端与订单库存闭环
简介这是一份基于SSM框架的星巴克咖啡店管理系统毕业设计文档专门面向Java方向的学生、毕业设计选题者及中小型餐饮信息化开发人员。文档围绕B/S架构采用Java语言、MySQL数据库与Tomcat服务器实现咖啡信息管理、订单处理、库存监控、员工考勤和财务管理等核心模块的数字化管理完整覆盖需求分析、可行性分析、技术选型、功能设计、数据库结构设计以及系统功能测试等环节能帮助读者快速理解Spring、SpringMVC和MyBatis三个框架的整合方式并直接复用其中的项目文档结构。资源共1个文件为docx格式压缩包约3.37MB已有49人浏览学习。文档中不仅展示了各主要功能模块的设计界面和操作说明还详细阐述了数据库表设计思路与测试要点可作为高校毕业设计撰写模板和模块划分参考同时也为咖啡店等连锁餐饮企业的信息化改造提供了可落地的系统方案。1. 基于 Java 的星巴克咖啡店管理系统在解决什么业务闭环与选型方向在后端岗位上摸过一阵子的人都会遇到一类项目基于 Java 的星巴克咖啡店管理系统或者类似的商品/进销存后台管理系统。它不只是把 CRUD 拼在一起核心难点是让点单、支付、库存、会员和报表形成一条不丢数据、不超卖的闭环。这类系统特别适合拿来做 Java 后台管理系统的练手也是很多工程师第一次独立负责一个小型全栈项目时的常见课题。我就按自己的落地习惯把需求拆分、数据库设计、后端接口、前端联调以及高频踩坑点完整过一遍让你拿到标题后能知道先做什么、后做什么以及哪些参数必须调。2. 需求拆分与数据库设计先想清楚业务边界再写建表语句2.1 咖啡店业务的三个闭环点单、库存、报表星巴克咖啡店表面看是卖咖啡但落到管理系统里其实是三个业务闭环。第一个是点单-支付-制作顾客确认订单后生成订单头和明细支付成功进入制作列表第二个是制作-扣库存每一杯咖啡背后是咖啡豆、牛奶、糖浆这些原料卖出商品时扣的是原料库存不是虚拟的商品库存第三个是营业对账-报表每天按门店、按员工、按商品统计销售额和销量管理层用来做决策。常见做法是把这三个闭环画成流程图我推荐用一张状态机图把订单生命周期定下来待支付、已支付、制作中、已完成、已取消。这里有一个很重要的边界取消订单发生在哪个状态待支付时可以随便取消已支付后取消要触发退款和库存回补制作中取消要区分是否已经开始制作。新手最容易把取消逻辑写成一刀切后面对账必出问题。功能模块先列清楚方便后面建表时对号入座模块核心场景关键数据商品管理分类、SKU、上下架category, product, sku订单管理下单、支付、取消、退款orders, order_item会员管理注册、余额、积分customer库存管理入库、扣减、预警、流水sku.stock, stock_log报表管理日销售、单品排行、会员消费orders, order_item这不是给星巴克官方做的系统而是给一个可运行的门店后台做的设计。别把需求做成全供应链采购、物流、排班这些可以先放掉。我一般把多门店的store_id提前加到所有核心表里哪怕现在只有一个门店后面扩展分店时不需要回填数据。2.2 核心表结构订单明细独立成表金额冗余但可控数据库用 MySQL引擎统一 InnoDB字符集 utf8mb4。主键用自增 id 可以但业务唯一键一定要单独建立比如订单号order_no。外键不要加让业务层保证一致性不然高并发下外键会变成锁瓶颈。订单主表的建表语句CREATE TABLE orders ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单号业务唯一, customer_id bigint DEFAULT NULL COMMENT 会员id散客为NULL, store_id bigint NOT NULL COMMENT 门店id预留多门店, total_amount decimal(10,2) NOT NULL DEFAULT 0.00 COMMENT 订单总额冗余汇总, status tinyint NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2制作中 3已完成 4已取消, pay_type tinyint DEFAULT NULL COMMENT 1微信 2支付宝 3余额, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_store_status (store_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单主表;关键点total_amount是冗余字段它由明细汇总而来。为什么要冗余因为列表页、报表页经常只查订单头每次 join 明细会让查询变慢。冗余的代价是必须保证一致性所以我在事务里写订单头时一定是从明细算好再写入而不是先写头再回头改。status用 tinyint不用 varchar配合状态机更省空间。订单明细表要保留商品快照CREATE TABLE order_item ( id bigint NOT NULL AUTO_INCREMENT, order_id bigint NOT NULL, sku_id bigint NOT NULL, product_name varchar(64) NOT NULL, sku_name varchar(64) NOT NULL COMMENT 规格名如中杯/大杯/超大杯, quantity int NOT NULL, unit_price decimal(10,2) NOT NULL COMMENT 成交单价快照, subtotal decimal(10,2) NOT NULL, PRIMARY KEY (id), KEY idx_order_id (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单明细;product_name、sku_name、unit_price都是快照商品改名改价不影响历史订单。subtotal在代码里算好不要在查询时再乘避免每个接口重复写乘法也避免顺序问题导致精度不一致。SKU 表里直接带库存和乐观锁版本号CREATE TABLE sku ( id bigint NOT NULL AUTO_INCREMENT, product_id bigint NOT NULL, name varchar(32) NOT NULL COMMENT 规格名称, price decimal(10,2) NOT NULL COMMENT 基础价, delta_price decimal(10,2) NOT NULL DEFAULT 0.00 COMMENT 加价如加3元, stock int NOT NULL DEFAULT 0, version int NOT NULL DEFAULT 0 COMMENT 乐观锁版本号, status tinyint NOT NULL DEFAULT 1, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;version字段用于乐观锁后面下单会用到。如果你不想加 version也可以只用stock qty条件更新但有了 version 可以顺便做更精细的并发控制。最后是库存流水表这是排障的后悔药CREATE TABLE stock_log ( id bigint NOT NULL AUTO_INCREMENT, sku_id bigint NOT NULL, change_type tinyint NOT NULL COMMENT 1入库 2扣减 3回补, change_qty int NOT NULL, after_qty int NOT NULL, order_id bigint DEFAULT NULL, created_at datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_sku_id (sku_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT库存流水;有了流水如果发现库存对不上可以按时间倒排查订单比对after_qty是否连续。没有这张表对账就只能一张张翻订单那是真的想骂人。2.3 金额、状态和时间的硬约束float 不能用状态流转要收口数据库里金额全部用decimal(10,2)Java 对应 BigDecimal千万别用 double。为什么0.10.2 在二进制浮点里不等于 0.3订单汇总差一分钱对账的时候就是血泪经验。MyBatis-Plus 的实体类字段用 BigDecimalMySQL 的 decimal 会自动映射不需要额外处理。状态字段我一般用整数枚举而不是字符串。Java 侧定义枚举public enum OrderStatus { PENDING(0, 待支付), PAID(1, 已支付), MAKING(2, 制作中), COMPLETED(3, 已完成), CANCELED(4, 已取消); private final int code; private final String desc; OrderStatus(int code, String desc) { this.code code; this.desc desc; } public static boolean canTransit(int from, int to) { // 只允许: 0-1, 1-2, 2-3, 0-4, 1-4 return false; } }状态流转的合法性校验要集中在一个方法里业务代码里不要到处写if status 1。比如订单支付时只允许待支付转已支付不然重复点击支付会把已支付订单再刷一次。canTransit方法里用 switch 或者查表实现这里只写注释不展开。时间字段数据库用 datetimeJava 用 LocalDateTime连接参数serverTimezoneAsia/Shanghai。统一时区是底线不然避坑章节里还会再撞上。另外不用外键而是用索引加应用层逻辑。咖啡店系统并发量不算高但订单表会持续增长外键在插入和更新时会让数据库多一次一致性检查容易成为性能浪费。商品删除用软删除不直接物理删这也算行业惯例。3. Spring Boot 后端落地项目结构、登录鉴权和下单事务3.1 项目结构三层分包与 Maven 依赖怎么配Spring Boot 项目我会用官方 Initializr 生成然后调整成 controller/service/mapper/entity/common/config。不要把所有类放一个包这不是强迫症是给后面的排障留线索。典型结构src/main/java/com/starbucks ├── common/ # 统一返回体、异常、常量 │ ├── Result.java │ ├── BusinessException.java │ └── GlobalExceptionHandler.java ├── config/ # 拦截器、Jackson、CORS 配置 ├── controller/ # 接口层 ├── service/ # 业务层 │ └── impl/ ├── mapper/ # MyBatis-Plus Mapper ├── entity/ # 数据库实体 ├── dto/ # 入参对象 └── vo/ # 出参对象controller 里不写 SQLservice 里不写 HTTP 参数解析mapper 只负责持久化。这样接口改动成本最低后面前端字段变了只改 VO 和 DTO不影响 service 核心逻辑。Maven 依赖关键部分dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-api/artifactId version0.11.5/version /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-impl/artifactId version0.11.5/version scoperuntime/scope /dependency /dependenciesMyBatis-Plus 3.5.x 是目前稳定常用版本如果你用 Spring Boot 2.x 完全没问题如果你用 Spring Boot 3.x注意 starter 的包名变化。这里不追求最新稳定最重要。3.2 JWT 登录鉴权用拦截器放行登录其余接口都要校验登录接口实现RestController RequestMapping(/api/auth) public class AuthController { Autowired private UserService userService; PostMapping(/login) public ResultString login(RequestBody LoginDTO dto) { User user userService.findByUsername(dto.getUsername()); if (user null || !userService.checkPassword(dto.getPassword(), user.getPassword())) { throw new BusinessException(用户名或密码错误); } return Result.ok(JwtUtil.createToken(user.getId(), user.getRole())); } }密码不能明文存至少用 BCrypt 加密checkPassword里做校验。接着是拦截器public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String auth request.getHeader(Authorization); if (auth ! null auth.startsWith(Bearer )) { try { Claims claims JwtUtil.parseToken(auth.substring(7)); request.setAttribute(userId, Long.valueOf(claims.getSubject())); request.setAttribute(role, claims.get(role, String.class)); return true; } catch (Exception e) { return writeUnauthorized(response); } } return writeUnauthorized(response); } private boolean writeUnauthorized(HttpServletResponse response) throws IOException { response.setStatus(401); response.setContentType(application/json;charsetUTF-8); response.getWriter().write({\code\:401,\msg\:\未登录或登录过期\}); return false; } }注册拦截器时放行登录接口Configuration public class WebConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new AuthInterceptor()) .addPathPatterns(/api/**) .excludePathPatterns(/api/auth/login); } }JWT 密钥在JwtUtil里用于演示直接生成真实项目要从配置读取不然每次重启密钥变化旧 token 全部失效。这个坑很容易忽略。过期时间我设了 8 小时后台管理系统够用。如果你担心 token 泄露可以加 refresh token但小系统先不要过度设计。3.3 下单接口事务与乐观锁把并发扣库存放在一条 SQL 里下单核心逻辑Service public class OrderServiceImpl implements OrderService { Autowired private OrdersMapper ordersMapper; Autowired private OrderItemMapper orderItemMapper; Autowired private SkuMapper skuMapper; Autowired private StockLogMapper stockLogMapper; Override Transactional(rollbackFor Exception.class) public OrderVO createOrder(CreateOrderDTO dto) { String orderNo generateOrderNo(dto.getStoreId()); Long exist ordersMapper.selectCount(new LambdaQueryWrapperOrders() .eq(Orders::getOrderNo, orderNo)); if (exist 0) { throw new BusinessException(订单号重复请重试); } Orders order new Orders(); order.setOrderNo(orderNo); order.setStoreId(dto.getStoreId()); order.setCustomerId(dto.getCustomerId()); order.setStatus(OrderStatus.PENDING.getCode()); order.setTotalAmount(BigDecimal.ZERO); ListOrderItem itemList new ArrayList(); for (CreateOrderDTO.Item itemDTO : dto.getItems()) { int rows skuMapper.deductStock(itemDTO.getSkuId(), itemDTO.getQuantity()); if (rows 0) { throw new BusinessException(库存不足或商品不存在); } Sku sku skuMapper.selectById(itemDTO.getSkuId()); OrderItem item new OrderItem(); item.setSkuId(sku.getId()); item.setProductName(sku.getProductName()); item.setSkuName(sku.getName()); item.setQuantity(itemDTO.getQuantity()); item.setUnitPrice(sku.getPrice().add(sku.getDeltaPrice())); item.setSubtotal(item.getUnitPrice().multiply(BigDecimal.valueOf(itemDTO.getQuantity()))); itemList.add(item); } order.setTotalAmount(itemList.stream() .map(OrderItem::getSubtotal) .reduce(BigDecimal.ZERO, BigDecimal::add)); ordersMapper.insert(order); for (OrderItem item : itemList) { item.setOrderId(order.getId()); orderItemMapper.insert(item); } return OrderVO.from(order); } }这段代码有一个隐藏细节先扣库存再查 SKU 信息。为什么不在扣库存前查因为查了也没用库存判断必须由 UPDATE 语句完成否则就有并发风险。如果扣库存成功说明商品存在且有货再查详情做快照顺序不影响正确性。事务方法里发生异常时Transactional会回滚所以中间抛错库存扣减也会回滚。幂等性我用了服务端生成的订单号做唯一约束但generateOrderNo如果包含随机数重复点击会产生不同订单号幂等就失效了。常见做法是前端在下单时生成一个clientRequestId后端用这个 ID 做唯一键。为了演示我写的是服务端生成实际项目最好接收客户端幂等键。Mapper 里的扣库存 SQLpublic interface SkuMapper extends BaseMapperSku { Update(UPDATE sku SET stock stock - #{qty}, version version 1 WHERE id #{skuId} AND stock #{qty}) int deductStock(Param(skuId) Long skuId, Param(qty) Integer qty); }这条 SQL 是防超卖的关键。如果库存充足两个并发请求都执行数据库行锁会让第二个等待第一个成功第二个再执行时 stock 可能已经不足影响行数为 0抛异常。这是单体应用里最简单可靠的方案。4. 前端后台实现与联调Vue3 Element Plus 的页面骨架4.1 动态菜单和路由后端给菜单前端按权限注册前端项目用 Vite Vue3 Element Plus。我不推荐把菜单写死在路由表里因为后台管理系统通常有多个角色店长、收银员、库存管理员。后端登录时返回菜单列表前端动态注册路由。菜单数据格式[ { path: /order/list, name: OrderList, meta: { title: 订单管理, icon: list } } ]前端使用router.addRoute动态添加const modules import.meta.glob(../views/**/*.vue); function addDynamicRoutes(menus) { menus.forEach(menu { const component modules[../views${menu.path}/index.vue]; router.addRoute({ path: menu.path, name: menu.name, component, meta: menu.meta }); }); }这里让前端页面路径与后端返回的 path 保持一致减少映射表维护。如果菜单较多注意在路由守卫里加一个“已加载”标记避免刷新后重复注册。4.2 点单页与订单提交购物车状态管理的核心代码点单页是咖啡店系统的门面。购物车状态用 Vue3 组合式 API 管理const cart ref([]); function addSku(sku) { const line cart.value.find(item item.skuId sku.id); if (line) { line.quantity 1; } else { cart.value.push({ skuId: sku.id, productName: sku.productName, skuName: sku.name, priceInCents: sku.priceInCents, // 后端返回以分为单位的整数 quantity: 1 }); } } const totalAmount computed(() cart.value.reduce((sum, item) sum item.priceInCents * item.quantity, 0) );价格用“分”为单位避免浮点误差这是我个人的习惯。后端在 SKU 接口里返回priceInCents整数前端做整数运算展示时再除以 100。提交订单时只传商品数量和会员 ID总价由后端计算。提交订单async function submitOrder() { const res await api.post(/order/create, { customerId: currentCustomerId.value, storeId: currentStoreId.value, items: cart.value.map(item ({ skuId: item.skuId, quantity: item.quantity })) }); if (res.code 0) { ElMessage.success(下单成功); cart.value []; } }前端不传金额只传商品数量和会员 ID总价由后端计算避免用户构造参数改价格。这条原则适用于所有交易系统金额永远以服务端为准。4.3 联调的三个坑跨域代理、日期回显、金额类型第一个是跨域。Vite 开发服务器端口是 5173后端是 8080浏览器直接请求会跨域。我是用代理而不是后端加 CORS// vite.config.js export default { server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }这样前端请求/api/xxx会被转发到后端 8080。生产环境用 Nginx 做同样的事。第二个是日期回显。后端返回 LocalDateTimeJackson 默认序列化成数组或 ISO 字符串前端显示很难看。统一配置spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai这个是全局 ObjectMapper 配置LocalDateTime 在 JavaTimeModule 下会使用该格式。第三个是金额类型。后端返回 BigDecimal 时Jackson 默认转成 numberJavaScript 处理大数字有精度隐患。解决方法是给 VO 里的金额字段加注解JsonSerialize(using ToStringSerializer.class) private BigDecimal totalAmount;或者干脆在 VO 里定义为 String。总额精度丢失比日期错乱更隐蔽所以一定要在接口层就处理。5. 排查手记让系统翻车的五个高频坑5.1 现象订单汇总金额对不上原因double 精度丢失解决decimal 加 BigDecimal有一次测试发现今天订单总额是 458.13但明细把单价乘数量加起来是 458.12差一分钱。一开始以为是 SQL 写错后来发现订单明细表的单价字段用的是 doubleJava 实体也用 Double。MySQL 里 Double 是浮点0.29 在内存里可能是 0.29000000000000004乘以 2 就是 0.5800000000000001最后汇总出问题。原因就是二进制浮点无法精确表示十进制小数只要涉及乘除法就必然有误差。解决把数据库字段改成decimal(10,2)Java 实体改成 BigDecimal。注意在 MyBatis-Plus 中BigDecimal 字段映射没问题但如果你在 service 里用了 Double 做中间计算精度会被污染回去。所以约定所有金额相关的实体、DTO、VO 全部用 BigDecimal不用 Double/Float。如果前端需要传金额比如退款后端要拒绝 Double 类型参数用 String 接收再new BigDecimal。我在接口参数里为此加过校验注解防止有人传 0.1 被转成 0.100000000000000005。5.2 现象库存被扣成负数原因先查再改解决update 条件扣减模拟两个收银员同时卖最后一杯咖啡页面都显示库存 1两个订单都成功库存变成 -1。原因是代码先查库存if stock 0失败再update stock stock - 1。两个请求都读到 1都通过 if然后 update 时没有 where 条件限制导致都成功。解决把“判断”和“扣减”合并为一条 update 语句WHERE 里带上stock qty。前面 3.3 已经给了 SQL这里再强调不要先 select 再 update除非加悲观锁for update但那样并发性能差。条件更新返回影响行数为 0 就抛异常。这个方案在单体应用和多数并发场景下够用。如果要做跨天对账可以在stock_log里记录after_qty一旦发现负库存比对流水很快定位是哪个订单扣的。没有流水只能翻库这就是血泪经验。5.3 现象接口偶发超时原因连接池占满解决HikariCP 参数调优系统上线两周后每天下午高峰期订单接口偶发 2-3 秒延迟偶尔报“连接不可用”。重启后恢复过几天又来。查日志发现是数据库连接池获取连接超时。原因HikariCP 默认maximum-pool-size是 10而应用里有个报表接口查询没有走索引每次扫描 20 万行订单占住连接 800ms。高峰期 20 个请求就把连接池打满正常订单接口只能排队等连接。解决先优化慢查询给orders表的created_at和store_id建联合索引。然后调连接池到合理大小spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 30000 idle-timeout: 600000连接池不是越大越好20 个连接对于中小型门店后台足够单库连接太多反而增加数据库线程上下文切换。关键是连接池参数要和慢查询一起改不然临时调大只是推迟问题。5.4 现象前端时间比本地晚 8 小时原因时区三处不一致解决统一 Asia/Shanghai测试环境日期显示 2025-06-01 08:00但数据库里的created_at存的是 2025-06-01 00:00。前端用 dayjs 格式化后变成 2025-06-01 08:00用户以为订单是在早上 8 点下的。原因MySQL 连接 URL 里没指定serverTimezoneJDBC 驱动用了服务器 UTCSpring Boot 的 Jackson 默认用 JVM 时区JVM 时区又可能是 UTC前端浏览器在中国显示时又加上 8 小时。三个环节各加一次时间就漂移了。解决统一三处。数据库连接 URLjdbc:mysql://localhost:3306/starbucks?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiSpring Boot 配置spring: jackson: time-zone: Asia/Shanghai date-format: yyyy-MM-dd HH:mm:ss如果上面还不行检查代码里是不是用了new Date()或System.currentTimeMillis()这些和 JVM 默认时区相关。数据库服务器如果是 Docker 容器也可能默认 UTC在 MySQL 启动参数加--default-time-zone08:00。5.5 现象上传图片重启后丢失原因本地绝对路径解决可配置存储目录商品图片上传成功页面也显示但系统重启或重新部署后图片全部 404。原因上传时把文件写到了项目目录下的 uploads 文件夹或者写了 /tmp 下的临时目录打包发布后目录被重建或清空。解决把上传目录做成配置项并挂载到服务器固定位置app: upload-dir: /data/starbucks/imagesController 里写入该目录然后通过资源映射访问Configuration public class StaticResourceConfig implements WebMvcConfigurer { Value(${app.upload-dir}) private String uploadDir; Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/images/**) .addResourceLocations(file: uploadDir /); } }这个配置还能顺带解决备份问题直接备份 /data 目录即可。生产环境建议考虑对象存储但小系统用固定目录加 Nginx 反代已经够。6. 验证到扩展让系统可持续演进的三个习惯6.1 用接口自测清单做回归没有自动化也有一条能点的路径项目交付前我会维护一张接口自测清单按业务顺序点一遍。这张表既是验收单也是回归测试的底线。接口方法请求参数预期结果/api/auth/loginPOSTadmin/123456返回 token/api/order/createPOSTskuId1, qty2订单号生成库存减少/api/order/payPOSTorderId状态变已支付/api/report/dailyGETdate返回当日销售额先用 curl 拿 tokencurl -X POST http://localhost:8080/api/auth/login \ -H Content-Type: application/json \ -d {username:admin,password:123456}然后后续请求带上Authorization: Bearer token。每次改动完按顺序点一遍能发现八成的问题。6.2 三个扩展位套餐、优惠券、多门店一开始就留好字段第一个扩展是套餐。套餐本质是商品组需要新建combo表和combo_item表下单时同时校验套餐内商品的库存。第二个是优惠券优惠券与用户、订单关联注意“券前金额”和“实付金额”要分开存否则对账时很痛苦。第三个是多门店我已经在所有核心表里加了store_id后面只要增加门店表和分店员工报表按store_id汇总即可。我早期做咖啡店项目时没有加库存流水库存对不上只能一边骂一边翻订单后来在新项目里第一张表就是stock_log排障几分钟搞定。设计系统时把可追踪性放在第一位比追求花哨功能管用得多。希望帮到你。本文还有配套的精品资源点击获取