1. 套餐管理模块的业务场景与核心挑战外卖平台的套餐管理模块看似简单实则暗藏玄机。想象一下你开了一家餐厅需要把几道菜品组合成套餐出售。这个过程中你需要确保套餐里的每道菜都处于可售状态套餐价格要合理还要能随时调整套餐内容。这就是我们开发套餐管理模块时面临的真实场景。在实际开发中最大的挑战来自多表关联操作。套餐本身是一个独立实体但它又和菜品、分类等多个实体产生关联。比如新增一个豪华双人餐套餐里面包含牛排、沙拉和饮料三道菜。这时候就需要在套餐表创建记录的同时还要在套餐-菜品关联表中建立这三组关系。我曾经在一个项目中就因为没有处理好这种关联关系导致用户下单后厨房收到的菜单里漏掉了配菜被客户投诉了好几次。另一个容易踩坑的点是状态一致性管理。套餐有起售/停售状态每道菜品也有自己的状态。当我们要上架一个套餐时必须确保套餐内所有菜品都是可售状态。有次我在测试环境就遇到一个bug系统允许将包含停售菜品的套餐设置为起售状态结果导致用户端展示的套餐无法正常下单。2. 数据库设计与多表关联策略2.1 表结构设计要点套餐管理的核心是两张表setmeal(套餐主表)和setmeal_dish(套餐菜品关联表)。主表存储套餐基本信息关联表则记录套餐包含哪些菜品。这种设计遵循了数据库规范化的原则避免了数据冗余。在setmeal表中有几个关键字段需要特别注意status字段表示套餐状态1起售/0停售默认值一定要设为0category_id关联到分类表确保每个套餐都有归属分类价格字段使用decimal类型避免浮点数计算精度问题setmeal_dish表的设计有个小技巧除了保存菜品ID外还冗余存储了菜品名称和单价。这样即使菜品信息后续有变更也能保留套餐创建时的原始信息。我在一次系统升级时就因为这个设计避免了历史订单信息显示异常的问题。2.2 关联查询优化实践当需要展示套餐列表时我们往往需要同时显示套餐所属分类的名称。这时就需要用到多表关联查询。在我的项目中是这样处理分页查询的SELECT s.*, c.name AS categoryName FROM setmeal s LEFT JOIN category c ON s.category_id c.id WHERE s.name LIKE %双人餐% ORDER BY s.create_time DESC特别注意要使用LEFT JOIN而不是INNER JOIN这样可以确保即使分类被删除套餐信息仍然能正常显示。曾经有个项目因为用了INNER JOIN导致一些老套餐在分类调整后从列表中神秘消失排查了好久才发现这个问题。3. 新增套餐的业务实现细节3.1 接口设计与参数校验新增套餐的接口需要接收一个复合DTO对象包含套餐基本信息和菜品列表。前端传参大概长这样{ name: 豪华双人餐, categoryId: 1, price: 88.00, image: meal.jpg, description: 包含牛排沙拉饮料, setmealDishes: [ {dishId: 1, copies: 1}, {dishId: 2, copies: 1}, {dishId: 3, copies: 2} ] }在Controller层我们需要用RequestBody接收这个JSON数据。这里有个坑我踩过忘记加RequestBody注解会导致前端传的参数全部为null。Spring的参数绑定机制在这种情况下不会报错但就是拿不到数据调试起来特别费劲。3.2 事务处理与数据一致性新增套餐的核心业务逻辑涉及两个数据库操作插入套餐主表和插入套餐菜品关联表。这两个操作必须在一个事务中完成否则可能出现套餐创建成功但菜品关联失败的情况。在Spring中我们只需要在Service方法上加Transactional注解即可。但要注意的是默认的事务传播行为是REQUIRED如果外层已经有事务就会加入现有事务。我在一个复杂业务场景中就遇到过嵌套事务导致的问题最后通过明确指定Transactional(propagation Propagation.REQUIRES_NEW)解决了。Service public class SetmealServiceImpl implements SetmealService { Transactional public void saveWithDish(SetmealDTO setmealDTO) { // 插入套餐主表 Setmeal setmeal new Setmeal(); BeanUtils.copyProperties(setmealDTO, setmeal); setmeal.setStatus(0); // 明确设置停售状态 setmealMapper.insert(setmeal); // 处理套餐菜品关系 Long setmealId setmeal.getId(); ListSetmealDish dishes setmealDTO.getSetmealDishes() .stream() .map(d - { d.setSetmealId(setmealId); return d; }).collect(Collectors.toList()); // 批量插入关联关系 setmealDishMapper.insertBatch(dishes); } }4. 套餐状态管理的核心逻辑4.1 起售/停售的业务规则套餐状态变更不是简单的字段更新而是有严格的业务规则停售套餐可以直接操作没有额外限制起售套餐时必须检查套餐内所有菜品是否都处于起售状态如果套餐包含停售菜品需要明确提示具体是哪些菜品导致不能起售实现这个逻辑时我建议先查询再更新避免直接更新后出现不一致。代码结构可以这样组织public void startOrStop(Integer status, Long id) { if (status 1) { // 起售操作 ListDish invalidDishes dishMapper.getBySetmealId(id) .stream() .filter(d - d.getStatus() 0) .collect(Collectors.toList()); if (!invalidDishes.isEmpty()) { String dishNames invalidDishes.stream() .map(Dish::getName) .collect(Collectors.joining(,)); throw new BusinessException(以下菜品未起售 dishNames); } } // 更新状态 Setmeal setmeal new Setmeal(); setmeal.setId(id); setmeal.setStatus(status); setmealMapper.updateById(setmeal); }4.2 状态变更的并发处理在高并发场景下多个管理员可能同时操作同一个套餐的状态。这时候需要考虑乐观锁机制。我们可以在套餐表中增加一个version字段更新时检查版本号UPDATE setmeal SET status #{status}, version version 1 WHERE id #{id} AND version #{version}如果更新影响行数为0说明期间有其他操作修改了数据应该提示用户刷新后重试。这个优化虽然增加了少量复杂度但能有效避免状态覆盖问题。我在一个日订单量上万的系统中就遇到过因为状态竞争导致的业务异常引入乐观锁后才彻底解决。5. 套餐删除与修改的注意事项5.1 删除操作的完整性约束删除套餐不是简单的DELETE操作需要遵循以下规则检查套餐是否处于起售状态起售套餐不能删除先删除套餐菜品关联表中的数据最后删除套餐主表记录这个顺序很重要如果先删主表记录关联表就会留下孤儿数据。我曾经在紧急修复一个生产问题时就犯了这个错误导致数据库里积累了大量无效关联记录。public void deleteWithDish(ListLong ids) { // 检查套餐状态 ListSetmeal invalidMeals setmealMapper.selectBatchIds(ids) .stream() .filter(m - m.getStatus() 1) .collect(Collectors.toList()); if (!invalidMeals.isEmpty()) { throw new BusinessException(存在起售套餐无法删除); } // 先删除关联关系 setmealDishMapper.deleteBySetmealIds(ids); // 再删除主表 setmealMapper.deleteBatchIds(ids); }5.2 修改套餐的数据一致性修改套餐信息时最稳妥的做法是先更新套餐主表信息删除所有旧的套餐菜品关联插入新的关联关系这样虽然会产生额外的删除/插入操作但能确保关联数据的准确性。我曾经尝试过智能比对只修改差异部分结果因为逻辑复杂引入了更多bug。public void updateWithDish(SetmealDTO setmealDTO) { // 更新主表 Setmeal setmeal new Setmeal(); BeanUtils.copyProperties(setmealDTO, setmeal); setmealMapper.updateById(setmeal); // 删除旧关联 setmealDishMapper.deleteBySetmealIds( Collections.singletonList(setmeal.getId())); // 插入新关联 ListSetmealDish dishes setmealDTO.getSetmealDishes() .stream() .peek(d - d.setSetmealId(setmeal.getId())) .collect(Collectors.toList()); setmealDishMapper.insertBatch(dishes); }6. 分页查询与性能优化6.1 复杂条件分页实现套餐分页查询通常需要支持多条件筛选比如按分类、按名称搜索、按状态过滤等。MyBatis的动态SQL非常适合这种场景select idpageQuery resultTypeSetmealVO SELECT s.*, c.name AS categoryName FROM setmeal s LEFT JOIN category c ON s.category_id c.id where if testname ! null s.name LIKE CONCAT(%, #{name}, %) /if if testcategoryId ! null AND s.category_id #{categoryId} /if if teststatus ! null AND s.status #{status} /if /where ORDER BY s.create_time DESC /select这里有个性能优化点当使用LIKE模糊查询时如果数据量大应该在name字段上建立索引。但要注意前导通配符(%开头)会使索引失效。在我的一个项目中套餐表达到10万条记录后模糊查询明显变慢后来通过调整查询方式解决了这个问题。6.2 分页插件的最佳实践使用PageHelper分页插件时要注意以下几点PageHelper.startPage()必须紧跟在查询方法前调用分页参数应该从DTO中获取而不是硬编码返回给前端的PageResult对象应该包含总记录数和当前页数据public PageResult pageQuery(SetmealPageQueryDTO dto) { PageHelper.startPage(dto.getPage(), dto.getPageSize()); PageSetmealVO page setmealMapper.pageQuery(dto); return new PageResult(page.getTotal(), page.getResult()); }我曾经遇到过内存泄漏问题后来发现是因为在循环中误用了PageHelper。切记分页查询不要放在循环体内否则会导致分页参数堆积。