1. 内容整体设计与思路拆解很多人学苍穹外卖前面几天多少有点照着敲的感觉环境装好、登录写好、分类管理跑通一切都像既定的流程。但到了第6天这个项目才真正开始有业务系统的样子。day6的核心是菜品管理、套餐管理外加一个贯穿其中的文件上传功能这套组合拳打下来你会发现所谓后端CRUD根本不是对着表增删改查那么轻松。先说清楚day6的位置。如果你按天推进这个项目前面几天的铺垫大概是第1到3天完成基础环境MySQL、Redis、Nginx、Maven私服仓库以及员工登录和JWT鉴权第4到5天做员工管理、分类管理顺带引入公共字段自动填充这类提效手段。到第6天业务开始从单独一张表走向多张表联动菜品和口味、套餐和菜品都是经典的一对多、多对多关系。这一步走顺了后面订单、购物车那些复杂模块才有底气。day6要解决的核心问题往深了说有三个层面。第一一个真实的业务对象往往不是一张表能装下的。一个菜品除了自身的基本信息还挂着一串口味列表一个套餐又关联着多个菜品这种主表从表的结构是所有业务系统的常态。第二后台管理的数据结构和前端展示的数据结构并不一致你不能把数据库表结构直接丢给前端中间需要DTO和VO做隔离。第三文件上传不是独立功能它是菜品和套餐模块的配套设施没有图片的菜品管理页面约等于没有灵魂。从模块划分来看day6的后端代码依然是标准的Controller-Service-Mapper三层但这一天的代码量会明显上一个台阶。Controller层只管接收参数、调用服务、封装结果诀窍在于参数对象设计——别用实体类接收前端请求而是用DTO。例如新增菜品时前端传来的DishDTO里包含了flavors列表字段dish实体里根本没有这个属性如果硬塞进去实体类会被污染后续MyBatis的自动映射也会出问题。Service层做真正的业务编排校验、转换、落库、联动全在这里发生。Mapper层就是纯粹的SQL执行越单纯越好。这个分层思路说白了就是把做什么和怎么做分开。Controller知道接口要干什么Service知道业务怎么编排Mapper只知道数据怎么存取。day6如果能把这种分层意识建立起来后面写一万行代码都不会乱。我见过不少新手把SQL写在Controller里当时能跑改需求时哭都来不及。1.1 day6之前的铺垫与知识点衔接day6不是一个孤立的日子它把前几天的技能点全部串了起来。JWT登录拦截器在这个阶段会再次出场因为菜品管理接口同样需要管理员身份校验公共字段自动填充就是那些create_time、update_time、create_user、update_user字段也是从这里开始频繁使用的。如果你前几天偷懒没实现自动填充day6你会在每一次新增和修改的代码里反复set这4个字段写20次之后你就会回来补课的。另外员工管理和分类管理的单表CRUD给day6打了个底。菜品管理看起来也就是CRUD但多了口味子表、多了图片上传、多了启售停售状态流转复杂度是几何级上升的。我在实际带新人的时候最怕的就是学员把day6当成又一个增删改查上来就闷头写写到最后发现菜品删不掉、口味更新不了、套餐在售但关联菜品已停售这些坑全部踩一遍才回头理解设计的重要性。1.2 day6核心需求拆解从单表操作到多表联动我们不妨用一句话概括day6的需求让运营人员可以在后台维护菜品和套餐信息包括新增、修改、删除、查询、启售停售并且菜品和套餐都要能带图片、带口味、带关联数据。拆解下来核心需求有三块。菜品管理这是最重的模块涉及菜品主表和口味子表的数据一致性什么时候该插入子表、什么时候该删除子表、什么时候只更新主表每个操作都要想清楚。套餐管理这个模块更绕因为一个套餐包含多个菜品而套餐的价格、描述和关联菜品是分离的新增一个套餐时后端要做两件事先插入套餐主表拿到自增ID再批量插入套餐菜品关联表。文件上传为什么单独拎出来说因为它在业务上相对独立但技术上牵扯到静态资源映射、拦截器放行、统一路径返回任何一个环节漏了前端图片就显示不出来。day6之后你应该形成一种肌肉记忆凡是接口参数里有List的先想想这个List的数据怎么落库凡是页面有图片的先确认一下文件上传接口有没有被登录拦截器挡掉凡是修改数据的先想想有没有先删子表再插子表这种常规操作。这些都是day6的隐藏考点。2. 菜品管理模块的核心实现细节菜品管理模块是day6的正餐来我把整个实现过程掰开揉碎讲一遍。2.1 表结构设计与实体类映射先看表结构。菜品主表dish的核心字段有id主键自增name菜品名称业务上要求唯一category_id所属分类外键逻辑关联分类表price价格注意数据库里用decimal单位是元image图片路径存的是相对路径例如/upload/xxx.jpgdescription描述信息status售卖状态1起售0停售create_time、update_time、create_user、update_user4个公共字段菜品口味表dish_flavor的字段就简单了id主键dish_id关联菜品主表name口味名称比如辣度value口味可选值比如不辣,微辣,中辣,特辣实体类设计上dish实体对应主表dish_flavor实体对应口味表关键一点是在Dish实体里加一个List\u003CDishFlavor\u003E flavors字段用于承载一对多的关系。这个字段在数据库里没有对应列但是MyBatis查询时可以通过collection标签映射出来写代码时也方便对象导航。我在实际写这个模块的时候曾经纠结过要不要单独建一个DishVO用于分页查询展示后来发现非常有必要。因为分页列表里的数据来自三张表菜品主表、分类表需要分类名称、口味表列表页可能需要展示口味数量直接用Dish实体接收还是得额外加categoryName属性不如建一个专门的VO从Mapper层就select出所有展示需要的字段Controller层直接返回干净利落。2.2 新增菜品时的双表落库逻辑新增菜品的接口路径是POST /admin/dish请求参数用DishDTO接收里面包含了菜品基本信息 List\u003CDishFlavor\u003E口味列表。代码逻辑分三步走。第一步把DTO的属性拷到Dish实体上。这一步可以用Spring的BeanUtils.copyProperties但要注意DTO里的status字段前端可能不传后端要默认置为1起售状态不然新菜品默认是停售的运营还得手动起售一次体验很不好。第二步往dish表插入主数据MyBatis的useGeneratedKeys属性会帮我们把自增主键回填到Dish对象的id属性上。这是整个双表落库的关键没有这个ID后面的口味数据根本没法关联。第三步遍历DishDTO里的flavors列表给每个dishFlavor对象setDishId成刚才回填的ID然后批量插入dish_flavor表一条SQL搞定。这段逻辑看起来不难但有一个很重要的细节事务。主表和从表的数据操作必须放在一个事务里要么都成功要么都失败。我见过有人把两步写在一个方法里但没加Transactional注解结果主表插入成功、口味插入失败数据库里出现一条没有口味的孤儿菜品后面修改菜品时再加载这个孤儿数据还会报错。正确的做法是在Service方法上标注Transactional并且确保方法内部抛出的异常是RuntimeExceptionSpring默认只对运行时异常回滚受检异常是不会触发回滚的。2.3 修改菜品时的联动更新策略修改菜品比新增更隐蔽因为你要决定口味列表怎么办。举一个最常见的坑前端提交修改时把原来三个口味改成了两个口味如果你只做了删除全部口味再重新插入那没问题但如果你只update了口味记录删掉的那个口味会在数据库里残留界面不显示、数据库里却有脏数据。行业里最常规的写法就是先删后插按照dishId先delete掉dish_flavor表中所有记录再批量插入新的口味数据整个过程依然在一个事务里。这样写的好处是逻辑简单、不容易出错代价是每次修改都要删除再插入但口味数据量很小性能损失可以忽略。我自己的心得是修改菜品时还要注意更新update_time和update_user字段。如果你已经实现了公共字段自动填充那这个操作是切面自动完成的如果没实现这里最容易漏掉的就是update_user前端传参里根本没有这个字段只能通过BaseContext从当前登录线程里取。2.4 启售停售菜品的状态管理启售停售接口本身很简单UPDATE dish SET status #{status} WHERE id #{id}。但如果你稍微多思考一步启售停售会对套餐产生影响。一个套餐关联了多个菜品如果其中有一个菜品是停售状态这个套餐理论上不应该再向用户展示因为用户下单后商家根本做不出来这道菜。所以day6如果时间充裕建议把套餐状态和菜品状态的联动逻辑一并想清楚。最简单的方案是查询套餐时如果关联菜品存在停售就把套餐标记为停售。这个逻辑放到Service层去判断不要放到SQL里硬写因为SQL里查关联状态再关联更新写起来很别扭而且容易产生并发数据不一致。3. 文件上传与图片回显的实操细节文件上传在day6里看着是个小功能其实是一个看起来简单但处处是坑的模块。我会把整个链路拆开讲从接口编写到静态资源映射把容易踩的坑全部指出来。3.1 上传接口的编写思路与文件命名规则苍穹外卖的上传接口路径是POST /admin/common/upload接收参数名叫file类型是MultipartFile。后端处理流程分四步。判断文件是否为空为空直接抛业务异常获取原始文件名截取出扩展名比如.jpg、.png用UUID生成新文件名拼接扩展名避免文件名冲突把文件保存到本地磁盘指定目录返回可访问的URL路径这里有一个很重要的点为什么要用UUID重命名因为运营上传的图片很可能重名如果直接存原名第二次上传同名图片会把第一次的覆盖掉而且文件名带中文在部分服务器上还会出现编码问题。用UUID重命名虽然最终文件名人眼识别不了但结合数据库里的记录完全可以追溯。本地存储目录我建议配置成项目外的绝对路径比如/usr/local/upload/。不要放在项目的resources目录下面因为打包部署后resources目录在jar包里文件写入会直接报错。也不要放在target目录下因为每次重新编译发布target目录会被清空上传的图片就全没了。3.2 登录拦截器的放行规则与静态资源映射这是day6里最典型的坑王问题。苍穹外卖的拦截器默认拦截所有/admin/**的请求如果你把上传接口写好了但没配放行前端发起上传请求时会直接被拦截器拦下返回未登录或登录已过期而前端若没做统一错误处理你会看到上传进度转了一圈又弹回错误提示完全不知道发生了什么。解决方式就是拿着WebMvcConfiguration类在addInterceptors方法里给admin拦截器加excludePathPatterns把/admin/employee/login和/admin/common/upload放行。登录接口放行很好理解上传接口放行是因为上传请求的header里可能没带token或者带了token但已经过期运营手动上传图片时不应该被鉴权阻塞。文件上传之后图片路径的访问又是一个独立的静态资源映射问题。你在Controller里返回的路径是/upload/xxx.jpg但浏览器访问http://localhost:8080/upload/xxx.jpg时Spring MVC默认不会把这个路径映射到磁盘目录。你需要在addResourceHandlers方法里做一次映射registry.addResourceHandler(/upload/**).addResourceLocations(file:/usr/local/upload/)。这里的file:前缀表示读取本地磁盘资源路径末尾的斜杠不能丢丢了会映射失败404没商量。3.3 图片回显路径的常见问题与规范化处理前面说了文件要存到本地磁盘接口返回的路径是/upload/xxx.jpg。这里有一个很隐蔽的问题前端拿这个路径去请求图片时如果前端项目和后端接口部署在同一个域名和端口下那直接拼IP和端口就能访问但如果前后端分离部署前端在8081端口后端在8080端口前端的img标签直接写相对路径/upload/xxx.jpg浏览器会去请求8081端口的资源等于请求了一个不存在的东西。更稳妥的做法是上传接口返回给前端的直接是完整的URL例如https://你的域名/upload/xxx.jpg。这样不管前端部署在哪图片路径都能被正确解析。实际开发中很多团队会用Nginx做反向代理把/upload路径代理到后端的本地磁盘目录前端拿到的还是相对路径但浏览器实际请求的是Nginx的地址Nginx再从磁盘把图片捞出来返回。不要在前端代码里写死localhost:8080这样的地址这种代码在本地跑通了一旦部署到服务器就要全部改一遍。我的建议是前后端的接口访问都统一走一个可配置的基础URL图片路径同样拼接在这个基础URL下面环境切换时只需改一处配置。4. 套餐管理模块的复杂业务逻辑套餐模块在day6里往往只有一两天的时间但它的逻辑复杂度比菜品管理高一个档次因为它牵扯到三张表的联动套餐主表setmeal、套餐菜品关联表setmeal_dish、菜品表dish。4.1 新增套餐时主表和关联表的保存顺序套餐主表的字段包括id、name、category_id、price、status、description、image等和菜品表结构非常相似。关键差异在setmeal_dish表它记录了套餐和菜品的多对多关系字段有id、setmeal_id、dish_id、name、price。注意在设计套餐菜品关联表时通常会冗余一份菜品的name和price字段这样套餐页面展示时不需要去join菜品表就能直接显示菜品名称和价格查询效率更高这就是典型的以空间换时间的冗余设计。新增套餐的SQL顺序是先插入setmeal主表拿到回填的主键ID然后遍历前端传来的setmealDishes列表给每个SetmealDish对象setSetmealId最后批量插入关联表。逻辑比菜品新增多了一层但原理完全一致。但这里有一个容易被忽略的校验逻辑新增套餐时前端传来的关联菜品必须是存在且处于起售状态的菜品。如果某个菜品已经停售了这个套餐就算建出来用户下单选了这个套餐商家也没法做菜。所以Service层在插入之前要做一次校验查出所有关联菜品的ID检查它们的status是否都为1起售如果有任何一个停售直接抛异常拒绝保存。4.2 修改、删除套餐时的数据一致性处理修改套餐同样采用先删后插的策略处理关联菜品表先DELETE FROM setmeal_dish WHERE setmeal_id ?再重新批量插入新的套餐菜品关系。主表信息用UPDATE语句更新整体包在一个事务里。删除套餐就更有讲究了。因为setmeal_dish表通过setmeal_id关联主表如果你先删主表记录关联表里的数据就会变成孤儿数据。所以正确顺序是先删除关联表记录再删除主表记录。当然更推荐的做法是在删除前先查一下这个套餐是否处于起售状态起售状态的套餐不能删除必须先把套餐停售了才能删。这个校验逻辑可以防住运营误操作前端页面也建议同步处理起售状态时禁用删除按钮。让我再多说一句事务失效的问题。在Spring里Transactional注解是放在Service方法上的但如果Service类内部有一个方法A调用了同类中的方法BB上的Transactional注解不会生效因为Spring的声明式事务是基于代理机制的B被A调用时走的是this引用没有经过代理对象。所以我的习惯是需要事务的代码尽量独立成方法或者保证入口方法持有Transactional注解。4.3 缓存联动启售停售时的状态一致性有些版本的苍穹外卖到day6会引入Redis缓存用户端的菜品和套餐列表。核心思路是用户端查询菜品或套餐时先查Redis缓存缓存没有再去查数据库并把结果写入缓存。这里最大的坑是缓存和数据库的一致性问题。最简单的解决方案是Cache Aside Pattern更新数据库之前先删除对应的Redis缓存等数据库更新成功后下次查询再把数据写入缓存。这样虽然做不到严格一致但可以保证最终一致性。如果你在day6阶段就引入了缓存请务必记住启售、停售、修改、删除菜品或套餐后要主动清理对应的缓存key不然用户端看到的还是旧数据。我见过一个真实的生产事故运营在后台把某个菜品价格从30改成25用户端因为缓存没过期仍然显示30。运营以为是后端没改反复提Bug最后排查到是缓存没清。这类问题在day6埋下种子到了后面订单模块会持续发酵。5. 常见问题与排查技巧实录这一节把我在带这个项目时真实遇到过的典型问题整理成表方便你对号入座。5.1 高频问题速查表问题现象排查思路解决办法前端上传图片时请求被拦截返回401或未登录检查拦截器放行路径有没有包含/admin/common/upload在WebMvcConfiguration中放行上传接口图片上传成功但浏览器访问图片地址404检查是否配置了静态资源映射/upload/**到磁盘路径在addResourceHandlers中配置file:映射新增菜品后页面列表看不到口味数据检查口味表是否插入了数据、dish_id是否正确回填确认useGeneratedKeystrue和keyPropertyid配置无误修改菜品后口味数据不更新检查Service方法是否写了先DELETE再批量INSERT的逻辑先按dish_id删除原口味再插入新口味删除套餐时报外键约束错误检查删除顺序是否先删关联表再删主表调整为先delete setmeal_dish再delete setmeal返回给前端的日期时间是一串数字LocalDateTime序列化格式问题配置Jackson消息转换器指定日期格式为yyyy-MM-dd HH:mm:ss修改数据时update_user字段没有更新检查公共字段自动填充切面是否覆盖了UPDATE操作在切面中通过OperationType判断是INSERT还是UPDATE分别填充不同字段套餐在售状态但关联菜品已经停售缺少套餐状态与菜品状态联动校验在查询和修改逻辑中检查关联菜品状态存在停售菜品则标记套餐停售5.2 时间格式与JSON序列化的经典问题day6的接口开始返回带时间的列表数据很多前端会向你抱怨时间字段显示成一大串数字。这是Java 8的LocalDateTime在Jackson默认序列化下的表现它会被序列化成类似[2024, 12, 25, 14, 30, 0]的数组前端根本没法直接展示。解决办法有几个方案最推荐的是实现一个Jackson的ObjectMapper定制在序列化LocalDateTime时统一输出为yyyy-MM-dd HH:mm:ss格式。如果你用的是Spring Boot可以自定义一个WebMvcConfigurer手动添加MappingJackson2HttpMessageConverter并在ObjectMapper中注册JavaTimeModule关闭WRITE_DATES_AS_TIMESTAMPS。也有一些项目会采用在application.yml里配置spring.jackson.date-format的方式。这里有个坑spring.jackson.date-format默认只对java.util.Date生效对LocalDateTime不一定有效。如果你配置后发现还是输出数组就老老实实写一个自定义的ObjectMapper定制类别在配置文件的表面上浪费时间。5.3 事务回滚不生效的几个隐蔽原因day6涉及大量双表操作事务是最容易出问题的地方。我总结了三类典型原因。第一类异常被吞了。很多人在Service方法里写了try-catch异常被catch住没往外抛事务自然不会回滚。正确的姿势是不要在事务方法里捕获异常或者捕获后继续抛出RuntimeException。第二类方法自调用。前面已经说过同类内部方法间调用时Transactional不生效。如果你发现Service方法明明加了注解但没回滚去检查一下是不是通过this调用的内部方法。第三类数据库表不支持事务。MySQL中InnoDB引擎才支持事务有些初学者误建了MyISAM表事务注解加了跟没加一样。排查时可以用SHOW TABLE STATUS确认表的引擎。5.4 一个小而实用的调试建议day6的调试工作我强烈建议你把MyBatis的SQL日志打开。在application.yml里配置mybatis-plus.configuration.log-impl为org.apache.ibatis.logging.stdout.StdOutImpl或者直接设置logging.level.你的mapper包路径为debug这样每次执行SQL都能在控制台看到完整SQL和参数值。排查bug的效率提升一倍不止你会清楚地看到插入主表、回填ID、批量插入子表的完整流程也能一眼看出哪条SQL的参数是null。调试双表操作时更推荐的做法是开启Spring事务管理的debug日志这样你能看到事务什么时候开启、什么时候提交、什么时候回滚。一旦发现事务没回滚日志里会给出很明确的线索。写在最后的几点实在建议day6这个节点很多人的学习曲线会出现第一个明显的分水岭。前面几天的代码都是照着视频或文档敲敲完就过了但到菜品和套餐这两个模块光会敲已经不够了你得想明白为什么这么敲。我见过太多人把代码敲完、页面跑通就觉得自己学会了问他修改菜品时口味为什么要先删后插答不上来。这个问题从day6一直能追问到面试现场而且被问到的概率极高。我自己的感受是day6最大的价值不是让你多会几个接口而是让你建立起主表从表联动的直觉。有了这个直觉后面学习购物车、订单、用户端菜品展示你会觉得万变不离其宗。反过来day6如果学得囫囵吞枣后面越学越吃力那几乎是必然的。最后分享一个小技巧学这个项目时不要复制粘贴代码哪怕视频里给了现成的也请你手动敲一遍。敲的过程中你会被迫面对每一个细节比如useGeneratedKeys写在哪个位置、批量插入的foreach标签怎么写的、拦截器放行路径的斜杠有没有加对。这些细节才是真正的经验积累。另外敲完一个功能后建议打开浏览器的开发者工具实际看一次前端发起的请求参数和后端返回的JSON结构把整个数据流在脑子里过一遍比多敲三遍印象都深。