1. 为什么水果品类是学习 Spring Boot 的绝佳练习场1.1 水果生鲜业务的特殊性在哪里先说结论水果购物管理系统看起来只是普通电商系统换了个商品类目实际上它踩中了生鲜电商最典型的多个痛点做一遍比做十遍“通用后台管理”学到的东西都多。做普通商品管理系统你只需要管好SKU、价格、库存三个字段就够了。但水果类目不一样水果有产地、规格、单位斤/盒/个、保鲜等级、采摘日期、上架批次、损耗率这些生鲜专属属性。同一个“山东红富士苹果”可能因为规格不同单果70mm/80mm/90mm分成多个价格档位库存状态还受季节和物流影响断货、下架、补货都比标准品频繁得多。这些业务规则逼着你在数据库表设计阶段就把数据模型打通而不是像写课程作业一样堆几个CRUD接口糊弄过去。再往深一层说水果购物管理系统的核心诉求是“快速浏览便捷下单订单状态透明”。用户进入首页不是去看PDF说明书而是要看当天哪些水果有货、促销价是多少、能不能直接加购结算。所以这个系统天然要求商品列表、购物车、订单、支付这几个模块形成一条丝滑的业务链路。谁能把这条链路的数据一致性、状态流转、异常补偿讲清楚谁就真正掌握了Spring Boot后端开发最值钱的那部分能力。1.2 技术选型的底层逻辑我见过不少人在开始这类项目时纠结为什么非要用Spring Boot而不是Gin、Django或者Node.js这里有个很实际的答案Spring Boot在高校教学、企业面试、中小型项目交付三个场景里覆盖率最高。你查任何一份Java后端实习岗位说明几乎都写了“熟悉Spring Boot”课程设计展示时答辩老师默认你用的是Spring Boot后续想扩展成微服务或者接中间件Spring Boot生态的成熟组件也最全。技术选型上我建议按这个组合来基础框架Spring Boot 2.7.x或3.x根据JDK版本决定别盲目上最新版ORMMyBatis-Plus比纯MyBatis省掉大量XML手写又比JPA更可控、更好教学数据库MySQL 8.0存储核心业务数据缓存Redis做验证码存储、首页热点水果缓存、购物车临时数据可选鉴权Sa-Token或JWT二选一即可不要两大套都写在项目里吓唬自己前端Vue 3 Element Plus或者Spring Boot自带的Thymeleaf模板引擎为什么这么组合核心原因有三个一是MyBatis-Plus的代码生成器能在几分钟内把实体类、Mapper、Service层全部生成好让你把精力聚焦在业务逻辑上二是Redis的引入刚好踩在“够用且不突兀”的复杂度线上既不会因为引入分布式事务这类重组件把自己卡死又能让答辩时有性能优化内容可以展开讲三是前端无论选Vue还是ThymeleafSpring Boot的后端接口设计方式都一样不会被前端框架绑架。提示这个项目最忌讳过度设计。我见过有人把Nacos、网关、分布式锁、消息队列全部塞进一个课程级别的购物系统里结果项目连启动都要排错两小时。先把单体闭环做扎实再谈扩展。2. 系统整体设计与核心表结构拆解2.1 模块划分从登录到售后的完整闭环一个能拿得出手的水果购物管理系统功能上至少应该覆盖三种角色的完整操作路径普通用户注册登录、浏览水果分类、搜索水果、查看详情、加入购物车、下订单、在线支付或模拟支付、查看订单状态、申请售后/评价管理员商品管理增删改查、上下架、库存调整、分类管理、订单管理发货、退款处理、用户管理、数据统计销量、销售额、热门商品系统支撑登录拦截、异常处理、日志记录、文件上传商品图片我实际划分代码包时是按这样的分层来做的controller // 接收请求、参数校验、返回统一结果 service // 业务逻辑事务控制都在这一层 mapper // MyBatis-Plus的Mapper接口 entity // 数据库实体 dto/vo // 入参出参对象避免前端直接面对实体类 config // 跨域配置、拦截器配置、Redis配置等 common // 统一返回体、异常枚举、工具类这个包结构最大的好处是职责清晰Controller不写任何业务代码只做“翻译”Service实现真正的下单扣库存逻辑并且加上Transactional事务注解Mapper层只做最简单的方法声明。很多人写Spring Boot项目最大的问题就是Controller里塞了几百行业务代码看起来快了后面排查问题时想死的心都有。2.2 数据库设计水果商品表与订单表的核心字段逻辑数据库设计是整个项目的灵魂也是答辩时最容易被追问的地方。水果购物管理系统至少需要7张表用户表、水果分类表、水果商品表、购物车表、订单表、订单明细表、充值记录表如果有余额功能。先看水果商品表。我建议字段这样设计字段名类型说明fruit_idbigint主键商品IDcategory_idbigint关联分类表fruit_namevarchar(100)水果名称origin_placevarchar(100)产地unitvarchar(20)计价单位斤/盒/个pricedecimal(10,2)售价original_pricedecimal(10,2)原价用来显示折扣stockint库存sales_countint销量image_urlvarchar(255)商品图片路径statustinyint上架状态 0下架 1上架create_timedatetime创建时间这里有个容易踩坑的地方价格必须用decimal(10,2)不要用float或double。答辩时如果被问“为什么”标准答案是二进制浮点数无法精确表示0.1这样的十进制小数在做金额累加时会出误差。这个知识点只要主动说出来基本能证明你有真实项目经验。再来看订单表和订单明细表这是逻辑最重的部分订单表字段建议包括订单号、用户ID、订单总金额、优惠金额、实付金额、收货人姓名、手机号、省市区地址、订单状态、创建时间、支付时间、发货时间、完成时间。订单明细表一定要包含水果商品ID、商品快照名称、商品快照图片、购买单价、购买数量、小计金额。很多新手不理解为什么要存“快照”。原因是商品信息会变今天卖9.9元明天改成12.8元如果订单明细里不锁定下单那一刻的商品名和价格用户的历史订单显示就会跟着商品表变动出现“订单金额对不上”的严重事故。存快照是电商系统最基础但最容易被忽略的设计。订单状态字段我建议用tinyint管理并且枚举定义为状态值含义0待付款1待发货已付款2待收货已发货3已完成4已取消5退款中6已退款这个状态建议把数值固定在一个字段里不要拆分多个布尔字段。否则后面做订单列表筛选和状态流转的时候SQL和Java判断都会变得极其痛苦。3. 核心业务功能实现与关键代码解析3.1 商品模块库存与状态的联动处理商品模块看起来只是增删改查实际上的核心难点在于“库存”和“上架状态”要联动。我见过一个很常见的错误实现管理员直接在前端改一个stock字段或者下架商品时只改了status结果用户在详情页还能看到商品但点“立即购买”时才提示“已下架”体验很糟糕。合理的做法是把管理操作拆成几个明确的接口新增商品、编辑商品基本信息、修改库存、上下架商品。其中上下架接口要额外做一次校验下架时如果商品正在参与活动或者有未完成的订单至少要有个提示或确认。同时商品列表给用户端展示时SQL条件必须带status 1而不是把状态交给前端判断。贴一段用户端查询水果列表的Service层示例Override public PageResultFruitVO getFruitPage(FruitQueryDTO queryDTO) { // 只查询上架商品配合分页插件使用 LambdaQueryWrapperFruit wrapper new LambdaQueryWrapper(); wrapper.eq(Fruit::getStatus, 1); if (StringUtils.hasText(queryDTO.getName())) { wrapper.like(Fruit::getFruitName, queryDTO.getName()); } if (queryDTO.getCategoryId() ! null) { wrapper.eq(Fruit::getCategoryId, queryDTO.getCategoryId()); } // 按销量排序让热门水果排前面 wrapper.orderByDesc(Fruit::getSalesCount); PageFruit page new Page(queryDTO.getPageNum(), queryDTO.getPageSize()); PageFruit result fruitMapper.selectPage(page, wrapper); // 实体转VO隐藏库存等用户不需要的字段 ListFruitVO voList result.getRecords().stream() .map(fruit - { FruitVO vo new FruitVO(); BeanUtils.copyProperties(fruit, vo); // 库存字段不返回给前端避免暴露真实库存 vo.setStock(null); return vo; }).collect(Collectors.toList()); return new PageResult(voList, result.getTotal()); }这里有两个细节值得在答辩和实战中强调一是用户端列表不返回真实库存字段避免被恶意刷接口探测库存压力二是排序策略按销量倒序这是零售场景里最简单的推荐策略效果比不排序好得多。3.2 购物车与下单流程的幂等设计购物车的实现方案有Session、Redis、数据库三种。这个小项目里我推荐数据库实现因为代码简单、不需要额外引入状态管理复杂度而且可以直接展示给用户“我的购物车持久化保存”的能力。购物车表设计时有一个联合唯一约束很重要(user_id, fruit_id)。用户添加同一商品时应该走“数量累加”逻辑而不是每次创建一个新记录。下单接口是整个系统的核心也是面试官最爱问的场景。这里必须先讲清楚“超卖问题”。如果用户并发抢购同一个水果用普通的“先查库存再扣减”写法会出大问题// 错误做法先查再改多线程下会超卖 Integer stock fruitMapper.selectStock(fruitId); if (stock count) { throw new BusinessException(库存不足); } fruitMapper.decreaseStock(fruitId, count);这个错误做法的根源在于两次SQL操作之间没有加锁其他请求可以读到未扣减的旧库存。正确的做法有很多种最简单有效的是“乐观锁条件更新”也就是把库存扣减写成一条带条件的SQLint rows fruitMapper.deductStock(fruitId, count); // 更新条件stock count // UPDATE fruit SET stock stock - #{count} // WHERE fruit_id #{fruitId} AND stock #{count} if (rows 0) { throw new BusinessException(库存不足); }用受影响行数来判断是否扣减成功天然避免了超卖而且不需要引入悲观锁或者Redis分布式锁。在答辩时可以主动讲出这个方案行锁在数据库层面自动生效同一时间只有一个事务能更新同一行配合事务回滚既能保证不多卖也能保证数据一致。创建订单时还要加上防重复提交机制。最朴素的做法是前端在提交按钮上做loading禁用但后端也必须校验。我常用的方案是前端生成一个请求唯一编号requestId随下单请求提交后端在Redis里以requestId为key写入标记如果重复请求直接拒绝。这个方案实现成本低又能覆盖大多数误触和网络重试场景。3.3 订单状态机与支付回调的对接思路订单创建之后状态不是随便改着玩的一定要有一套状态机约束。比如“待发货”不能直接跳到“已完成”“已取消”不可能变成“待付款”。实现上有简单和复杂两条路。复杂的是用Spring StateMachine框架配置状态转换表简单但有效的做法是用一个状态校验方法在下单、支付、发货、确认收货、取消各个方法里统一校验初始状态private void assertOrderStatus(Order order, int expectStatus) { if (order.getStatus() ! expectStatus) { throw new BusinessException(订单状态异常当前状态 order.getStatus()); } }支付回调这块我不建议真的接入微信支付或支付宝。因为个体开发者很难申请到商户号而且沙箱环境配置繁琐。我建议做一个“模拟支付接口”用户点击“去支付”后后端生成一条支付流水直接把订单状态从0变成1同时记录支付时间和流水号。但要注意即使模拟也要设计成接口形式方便以后替换成真实支付public void mockPay(Long orderId, Long userId) { Order order orderMapper.selectById(orderId); // 校验订单存在且属于当前用户 if (order null || !order.getUserId().equals(userId)) { throw new BusinessException(订单不存在); } assertOrderStatus(order, 0); // 模拟支付成功更新订单状态和支付时间 order.setStatus(1); order.setPayTime(new Date()); orderMapper.updateById(order); }真正的支付回调原理也要能讲清楚支付平台回调你的接口通知支付结果回调里要验签、要保证幂等、要更新订单状态。你可以把这个流程画成一张时序图放在文档里让文档更专业。4. 权限控制、接口规范与前端对接4.1 会话与权限方案怎么选用户登录之后后端怎么识别“你是你”是一个绕不开的问题。Session方案和JWT方案我都用过小项目我建议用Sa-Token或JWT原因有两个前后端分离时JWT可以放在请求头里传递不依赖CookieRedis可以很好地支持Token在线管理退出登录也能主动失效。但如果把项目定位成课程设计或者单体模板用Spring Boot自带的Session机制反而更省事登录成功后往Session里放用户ID后续请求通过拦截器从Session取用户数据。好处是不用处理Token过期、续期、注销等一堆细节代码量减少一半。缺点是不能水平扩展服务节点但这显然超出了这个项目的范围。我的建议是如果你打算在简历里体现“懂前后端分离、懂JWT”就用JWT方案如果想快速稳定跑通就老老实实用Session。这两个方案在答辩时都不扣分关键看你能否把选择理由讲清楚。无论选哪种方案一定要配备一个登录拦截器或全局HandlerInterceptor。比如要做管理员接口拦截public class AdminAuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { // 从请求头取Token或者从Session取登录用户 Object loginUser request.getSession().getAttribute(loginUser); if (loginUser null) { // 返回未登录结果而不是重定向到登录页 throw new BusinessException(未登录或登录已过期请先登录); } return true; } }拦截器里有一个细节容易被忽视接口返回给前端时如果未登录应该返回JSON格式的401状态和统一错误通知而不是跳转HTML登录页。因为前端页面是用Vue渲染的跳转会导致前端路由混乱。4.2 接口返回结构与错误码约定接口返回结构统一是前后端协作里最容易出成果也最容易被忽视的一环。我这边的习惯是定义一个通用的ResultT类public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT error(Integer code, String message) { ResultT result new Result(); result.setCode(code); result.setMessage(message); return result; } }每个Controller的方法统一返回Result对象配合全局异常处理器RestControllerAdvice把业务异常、参数异常、系统异常全部转换为标准JSON结构。这样做的好处是前端只需要写一套响应拦截逻辑后端出什么错误都能统一展示。错误码建议这样分区间错误码含义200成功401未登录或Token失效403无权限400参数校验失败500服务器内部错误10001业务异常基础码10002库存不足10003订单状态异常10004支付失败错误码不要乱定义尽量在枚举类里统一管理。答辩时能说出“我封装了全局异常业务异常和未知异常分开处理”这已经是中级工程师的思维了。5. 性能优化与安全加固的实操经验5.1 列表查询慢索引和缓存这样配水果购物管理系统在数据量小的时候什么查询都快但一旦商品数据上了万条、用户访问量突然上来很多隐藏问题就暴露了。性能优化不需要一来就上Redis、上消息队列先做两件性价比最高的事加索引和分页优化。商品表建议给category_id和status建联合索引因为用户端最常见查询是“查某个分类下所有上架商品”。SQL写WHERE category_id ? AND status 1时联合索引能直接把扫描行数从几千条降到几十条速度提升肉眼可见。分页上不要用LIMIT 100000, 10这种深分页写法。数据量大的时候会越来越慢因为数据库要扫描并丢弃前十万行。优化方案是记录上一次查询的最大ID然后用WHERE id ? ORDER BY id ASC LIMIT 10。用户端水果列表基本不存在跳页需求这种“下一页”式分页完全够用。如果做了Redis缓存优先缓存首页轮播图、热门水果TOP10这类读多写少的数据。缓存更新的策略最老实的做法是“更新数据库后删除缓存”下一次请求重建缓存。这个模式叫Cache Aside Pattern对付这个小项目绰绰有余完全不需要引入Canal或者消息队列去搞最终一致性。5.2 订单金额与库存安全的防线安全这块大部分人的注意力都放在SQL注入上和XSS上但水果购物系统真正的风险点在金额篡改和接口越权。金额篡改是我见过最典型的攻击方式。魔鬼藏在细节里如果前端提交订单时把“商品总价”也作为参数传过来攻击者完全可以把100元改成0.01元。正确做法是后端根据购物车明细重新计算总金额前端传过来的金额只做展示参考绝不能作为结算依据。我处理这个需求时会写一个计算金额的内部方法只允许Service层调用不允许Controller直接组装金额。还有一类问题是越权。很多新手在写“查看订单详情”接口时只用了订单ID作为参数没有校验这个订单是否属于当前登录用户// 错误做法任何人传入订单ID都能查到 Order order orderMapper.selectById(orderId); // 正确做法绑定用户ID LambdaQueryWrapperOrder wrapper new LambdaQueryWrapper(); wrapper.eq(Order::getId, orderId); wrapper.eq(Order::getUserId, currentUserId); Order order orderMapper.selectOne(wrapper); if (order null) { throw new BusinessException(订单不存在); }这个点一定要在代码里写清楚横向越权是安全性漏洞中最常见的一类也是答辩时最容易被问到的一个点。顺便把密码存储也提一下用户密码必须用BCrypt加密不要用MD5因为MD5可以彩虹表反查。6. 常见问题排查与避坑实录6.1 高频报错现象与解决对照表我在带几个开发者做同类项目时整理过一份高频问题对照表这里直接放出来报错现象可能原因解决办法启动报Failed to configure a DataSource没有配置数据源或依赖缺失检查application.yml的数据库连接配置和MySQL驱动依赖访问接口返回404Controller没有被扫描到或路径错误检查启动类是否在Controller同级或父包下RestController和RequestMapping路径要标注正确日期字段返回“2023-01-01T00:00:00”格式Jackson默认序列化格式不含指定格式在application.yml里配置spring.jackson.date-format或加JsonFormat订单扣库存后库存变成负数没有使用条件更新或事务失效改用UPDATE ... WHERE stock #{count}写法检查Transactional是否被同类调用绕过登录后刷新失效Session未持久化到Redis小项目不需要处理否则需要引入spring-session-data-redis图片上传成功但访问404静态资源映射没配置配置WebMvcConfigurer里的addResourceHandlers映射本地文件目录跨域请求拿不到数据缺少跨域配置实现WebMvcConfigurer的addCorsMappings允许指定前端地址访问每个问题都是真实踩过的坑尤其是Controller的扫描路径问题。很多人的启动类放在com.example.controller的同级包下但是Controller却放在com.example.controller.admin路径不匹配导致接口找不到这是初学者最容易忽视的地方。6.2 我踩过的几个典型坑第一个坑是MyBatis-Plus的字段自动填充。建实体类时如果create_time字段用了FieldFill.INSERT自动填充但忘记在实体上配置TableField(fill FieldFill.INSERT)就会造成插入数据库时报空值异常。更稳妥的写法是用数据库的DEFAULT CURRENT_TIMESTAMP兜底代码里即使没赋值也不会出错。第二个坑是服务层事务自调用失效。在同一个类里一个方法methodA调用另一个Transactional方法methodB时事务是不会起作用的因为Spring事务是通过动态代理实现的同类调用是直接调用目标对象绕过代理。解决办法是把需要事务的公有方法放在不同类里或者自己注入自己。这个知识点几乎每次答辩都会被追问。第三个坑是“测试环境一切正常上线后订单我付不了款”。排查半天发现是支付回调接口没设置白名单/回调地址写成了localhost。虽然我们用的是模拟支付但这个排查过程对我的启发是接口联調时一定要提前确认环境地址、端口和防火墙配置不要等到联调现场再折腾。第四个坑个更隐蔽Redis缓存了首页水果列表管理员改完价格后首页依旧显示旧价格。这就是典型的缓存一致性问题。我最后用的办法是改价格的后端接口里主动删除对应的缓存key保证下次读取时重新从数据库加载。不要迷信“过期时间能解决一切”写入频繁的数据必须主动失效缓存。注意这类系统的测试数据不要太随意。至少准备20种以上的水果分类数据、三种不同角色账号管理员、普通用户、受限用户并且订单数据要有覆盖所有状态的样本。答辩演示时直接操作真实状态比临时造数据从容得多。最后再分享一个个人经验这种Spring Boot水果购物管理系统真正做完一遍之后你最大的收获不是“会写接口了”而是理解了业务状态和数据建模之间的耦合关系。后续再做其他管理类系统只要把商品换成图书、服装、课程整套设计思路都能平移过去。如果你正在做类似项目建议把精力优先花在订单状态流转、库存安全、权限校验这三个点上它们才是这个系统的灵魂。 
长河君 · 2026/10/21 14:10:52 · 阅读 1.2k Spring Boot水果购物系统开发：订单库存与权限设计实战
1. 为什么水果品类是学习 Spring Boot 的绝佳练习场1.1 水果生鲜业务的特殊性在哪里先说结论水果购物管理系统看起来只是普通电商系统换了个商品类目实际上它踩中了生鲜电商最典型的多个痛点做一遍比做十遍“通用后台管理”学到的东西都多。做普通商品管理系统你只需要管好SKU、价格、库存三个字段就够了。但水果类目不一样水果有产地、规格、单位斤/盒/个、保鲜等级、采摘日期、上架批次、损耗率这些生鲜专属属性。同一个“山东红富士苹果”可能因为规格不同单果70mm/80mm/90mm分成多个价格档位库存状态还受季节和物流影响断货、下架、补货都比标准品频繁得多。这些业务规则逼着你在数据库表设计阶段就把数据模型打通而不是像写课程作业一样堆几个CRUD接口糊弄过去。再往深一层说水果购物管理系统的核心诉求是“快速浏览便捷下单订单状态透明”。用户进入首页不是去看PDF说明书而是要看当天哪些水果有货、促销价是多少、能不能直接加购结算。所以这个系统天然要求商品列表、购物车、订单、支付这几个模块形成一条丝滑的业务链路。谁能把这条链路的数据一致性、状态流转、异常补偿讲清楚谁就真正掌握了Spring Boot后端开发最值钱的那部分能力。1.2 技术选型的底层逻辑我见过不少人在开始这类项目时纠结为什么非要用Spring Boot而不是Gin、Django或者Node.js这里有个很实际的答案Spring Boot在高校教学、企业面试、中小型项目交付三个场景里覆盖率最高。你查任何一份Java后端实习岗位说明几乎都写了“熟悉Spring Boot”课程设计展示时答辩老师默认你用的是Spring Boot后续想扩展成微服务或者接中间件Spring Boot生态的成熟组件也最全。技术选型上我建议按这个组合来基础框架Spring Boot 2.7.x或3.x根据JDK版本决定别盲目上最新版ORMMyBatis-Plus比纯MyBatis省掉大量XML手写又比JPA更可控、更好教学数据库MySQL 8.0存储核心业务数据缓存Redis做验证码存储、首页热点水果缓存、购物车临时数据可选鉴权Sa-Token或JWT二选一即可不要两大套都写在项目里吓唬自己前端Vue 3 Element Plus或者Spring Boot自带的Thymeleaf模板引擎为什么这么组合核心原因有三个一是MyBatis-Plus的代码生成器能在几分钟内把实体类、Mapper、Service层全部生成好让你把精力聚焦在业务逻辑上二是Redis的引入刚好踩在“够用且不突兀”的复杂度线上既不会因为引入分布式事务这类重组件把自己卡死又能让答辩时有性能优化内容可以展开讲三是前端无论选Vue还是ThymeleafSpring Boot的后端接口设计方式都一样不会被前端框架绑架。提示这个项目最忌讳过度设计。我见过有人把Nacos、网关、分布式锁、消息队列全部塞进一个课程级别的购物系统里结果项目连启动都要排错两小时。先把单体闭环做扎实再谈扩展。2. 系统整体设计与核心表结构拆解2.1 模块划分从登录到售后的完整闭环一个能拿得出手的水果购物管理系统功能上至少应该覆盖三种角色的完整操作路径普通用户注册登录、浏览水果分类、搜索水果、查看详情、加入购物车、下订单、在线支付或模拟支付、查看订单状态、申请售后/评价管理员商品管理增删改查、上下架、库存调整、分类管理、订单管理发货、退款处理、用户管理、数据统计销量、销售额、热门商品系统支撑登录拦截、异常处理、日志记录、文件上传商品图片我实际划分代码包时是按这样的分层来做的controller // 接收请求、参数校验、返回统一结果 service // 业务逻辑事务控制都在这一层 mapper // MyBatis-Plus的Mapper接口 entity // 数据库实体 dto/vo // 入参出参对象避免前端直接面对实体类 config // 跨域配置、拦截器配置、Redis配置等 common // 统一返回体、异常枚举、工具类这个包结构最大的好处是职责清晰Controller不写任何业务代码只做“翻译”Service实现真正的下单扣库存逻辑并且加上Transactional事务注解Mapper层只做最简单的方法声明。很多人写Spring Boot项目最大的问题就是Controller里塞了几百行业务代码看起来快了后面排查问题时想死的心都有。2.2 数据库设计水果商品表与订单表的核心字段逻辑数据库设计是整个项目的灵魂也是答辩时最容易被追问的地方。水果购物管理系统至少需要7张表用户表、水果分类表、水果商品表、购物车表、订单表、订单明细表、充值记录表如果有余额功能。先看水果商品表。我建议字段这样设计字段名类型说明fruit_idbigint主键商品IDcategory_idbigint关联分类表fruit_namevarchar(100)水果名称origin_placevarchar(100)产地unitvarchar(20)计价单位斤/盒/个pricedecimal(10,2)售价original_pricedecimal(10,2)原价用来显示折扣stockint库存sales_countint销量image_urlvarchar(255)商品图片路径statustinyint上架状态 0下架 1上架create_timedatetime创建时间这里有个容易踩坑的地方价格必须用decimal(10,2)不要用float或double。答辩时如果被问“为什么”标准答案是二进制浮点数无法精确表示0.1这样的十进制小数在做金额累加时会出误差。这个知识点只要主动说出来基本能证明你有真实项目经验。再来看订单表和订单明细表这是逻辑最重的部分订单表字段建议包括订单号、用户ID、订单总金额、优惠金额、实付金额、收货人姓名、手机号、省市区地址、订单状态、创建时间、支付时间、发货时间、完成时间。订单明细表一定要包含水果商品ID、商品快照名称、商品快照图片、购买单价、购买数量、小计金额。很多新手不理解为什么要存“快照”。原因是商品信息会变今天卖9.9元明天改成12.8元如果订单明细里不锁定下单那一刻的商品名和价格用户的历史订单显示就会跟着商品表变动出现“订单金额对不上”的严重事故。存快照是电商系统最基础但最容易被忽略的设计。订单状态字段我建议用tinyint管理并且枚举定义为状态值含义0待付款1待发货已付款2待收货已发货3已完成4已取消5退款中6已退款这个状态建议把数值固定在一个字段里不要拆分多个布尔字段。否则后面做订单列表筛选和状态流转的时候SQL和Java判断都会变得极其痛苦。3. 核心业务功能实现与关键代码解析3.1 商品模块库存与状态的联动处理商品模块看起来只是增删改查实际上的核心难点在于“库存”和“上架状态”要联动。我见过一个很常见的错误实现管理员直接在前端改一个stock字段或者下架商品时只改了status结果用户在详情页还能看到商品但点“立即购买”时才提示“已下架”体验很糟糕。合理的做法是把管理操作拆成几个明确的接口新增商品、编辑商品基本信息、修改库存、上下架商品。其中上下架接口要额外做一次校验下架时如果商品正在参与活动或者有未完成的订单至少要有个提示或确认。同时商品列表给用户端展示时SQL条件必须带status 1而不是把状态交给前端判断。贴一段用户端查询水果列表的Service层示例Override public PageResultFruitVO getFruitPage(FruitQueryDTO queryDTO) { // 只查询上架商品配合分页插件使用 LambdaQueryWrapperFruit wrapper new LambdaQueryWrapper(); wrapper.eq(Fruit::getStatus, 1); if (StringUtils.hasText(queryDTO.getName())) { wrapper.like(Fruit::getFruitName, queryDTO.getName()); } if (queryDTO.getCategoryId() ! null) { wrapper.eq(Fruit::getCategoryId, queryDTO.getCategoryId()); } // 按销量排序让热门水果排前面 wrapper.orderByDesc(Fruit::getSalesCount); PageFruit page new Page(queryDTO.getPageNum(), queryDTO.getPageSize()); PageFruit result fruitMapper.selectPage(page, wrapper); // 实体转VO隐藏库存等用户不需要的字段 ListFruitVO voList result.getRecords().stream() .map(fruit - { FruitVO vo new FruitVO(); BeanUtils.copyProperties(fruit, vo); // 库存字段不返回给前端避免暴露真实库存 vo.setStock(null); return vo; }).collect(Collectors.toList()); return new PageResult(voList, result.getTotal()); }这里有两个细节值得在答辩和实战中强调一是用户端列表不返回真实库存字段避免被恶意刷接口探测库存压力二是排序策略按销量倒序这是零售场景里最简单的推荐策略效果比不排序好得多。3.2 购物车与下单流程的幂等设计购物车的实现方案有Session、Redis、数据库三种。这个小项目里我推荐数据库实现因为代码简单、不需要额外引入状态管理复杂度而且可以直接展示给用户“我的购物车持久化保存”的能力。购物车表设计时有一个联合唯一约束很重要(user_id, fruit_id)。用户添加同一商品时应该走“数量累加”逻辑而不是每次创建一个新记录。下单接口是整个系统的核心也是面试官最爱问的场景。这里必须先讲清楚“超卖问题”。如果用户并发抢购同一个水果用普通的“先查库存再扣减”写法会出大问题// 错误做法先查再改多线程下会超卖 Integer stock fruitMapper.selectStock(fruitId); if (stock count) { throw new BusinessException(库存不足); } fruitMapper.decreaseStock(fruitId, count);这个错误做法的根源在于两次SQL操作之间没有加锁其他请求可以读到未扣减的旧库存。正确的做法有很多种最简单有效的是“乐观锁条件更新”也就是把库存扣减写成一条带条件的SQLint rows fruitMapper.deductStock(fruitId, count); // 更新条件stock count // UPDATE fruit SET stock stock - #{count} // WHERE fruit_id #{fruitId} AND stock #{count} if (rows 0) { throw new BusinessException(库存不足); }用受影响行数来判断是否扣减成功天然避免了超卖而且不需要引入悲观锁或者Redis分布式锁。在答辩时可以主动讲出这个方案行锁在数据库层面自动生效同一时间只有一个事务能更新同一行配合事务回滚既能保证不多卖也能保证数据一致。创建订单时还要加上防重复提交机制。最朴素的做法是前端在提交按钮上做loading禁用但后端也必须校验。我常用的方案是前端生成一个请求唯一编号requestId随下单请求提交后端在Redis里以requestId为key写入标记如果重复请求直接拒绝。这个方案实现成本低又能覆盖大多数误触和网络重试场景。3.3 订单状态机与支付回调的对接思路订单创建之后状态不是随便改着玩的一定要有一套状态机约束。比如“待发货”不能直接跳到“已完成”“已取消”不可能变成“待付款”。实现上有简单和复杂两条路。复杂的是用Spring StateMachine框架配置状态转换表简单但有效的做法是用一个状态校验方法在下单、支付、发货、确认收货、取消各个方法里统一校验初始状态private void assertOrderStatus(Order order, int expectStatus) { if (order.getStatus() ! expectStatus) { throw new BusinessException(订单状态异常当前状态 order.getStatus()); } }支付回调这块我不建议真的接入微信支付或支付宝。因为个体开发者很难申请到商户号而且沙箱环境配置繁琐。我建议做一个“模拟支付接口”用户点击“去支付”后后端生成一条支付流水直接把订单状态从0变成1同时记录支付时间和流水号。但要注意即使模拟也要设计成接口形式方便以后替换成真实支付public void mockPay(Long orderId, Long userId) { Order order orderMapper.selectById(orderId); // 校验订单存在且属于当前用户 if (order null || !order.getUserId().equals(userId)) { throw new BusinessException(订单不存在); } assertOrderStatus(order, 0); // 模拟支付成功更新订单状态和支付时间 order.setStatus(1); order.setPayTime(new Date()); orderMapper.updateById(order); }真正的支付回调原理也要能讲清楚支付平台回调你的接口通知支付结果回调里要验签、要保证幂等、要更新订单状态。你可以把这个流程画成一张时序图放在文档里让文档更专业。4. 权限控制、接口规范与前端对接4.1 会话与权限方案怎么选用户登录之后后端怎么识别“你是你”是一个绕不开的问题。Session方案和JWT方案我都用过小项目我建议用Sa-Token或JWT原因有两个前后端分离时JWT可以放在请求头里传递不依赖CookieRedis可以很好地支持Token在线管理退出登录也能主动失效。但如果把项目定位成课程设计或者单体模板用Spring Boot自带的Session机制反而更省事登录成功后往Session里放用户ID后续请求通过拦截器从Session取用户数据。好处是不用处理Token过期、续期、注销等一堆细节代码量减少一半。缺点是不能水平扩展服务节点但这显然超出了这个项目的范围。我的建议是如果你打算在简历里体现“懂前后端分离、懂JWT”就用JWT方案如果想快速稳定跑通就老老实实用Session。这两个方案在答辩时都不扣分关键看你能否把选择理由讲清楚。无论选哪种方案一定要配备一个登录拦截器或全局HandlerInterceptor。比如要做管理员接口拦截public class AdminAuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { // 从请求头取Token或者从Session取登录用户 Object loginUser request.getSession().getAttribute(loginUser); if (loginUser null) { // 返回未登录结果而不是重定向到登录页 throw new BusinessException(未登录或登录已过期请先登录); } return true; } }拦截器里有一个细节容易被忽视接口返回给前端时如果未登录应该返回JSON格式的401状态和统一错误通知而不是跳转HTML登录页。因为前端页面是用Vue渲染的跳转会导致前端路由混乱。4.2 接口返回结构与错误码约定接口返回结构统一是前后端协作里最容易出成果也最容易被忽视的一环。我这边的习惯是定义一个通用的ResultT类public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT error(Integer code, String message) { ResultT result new Result(); result.setCode(code); result.setMessage(message); return result; } }每个Controller的方法统一返回Result对象配合全局异常处理器RestControllerAdvice把业务异常、参数异常、系统异常全部转换为标准JSON结构。这样做的好处是前端只需要写一套响应拦截逻辑后端出什么错误都能统一展示。错误码建议这样分区间错误码含义200成功401未登录或Token失效403无权限400参数校验失败500服务器内部错误10001业务异常基础码10002库存不足10003订单状态异常10004支付失败错误码不要乱定义尽量在枚举类里统一管理。答辩时能说出“我封装了全局异常业务异常和未知异常分开处理”这已经是中级工程师的思维了。5. 性能优化与安全加固的实操经验5.1 列表查询慢索引和缓存这样配水果购物管理系统在数据量小的时候什么查询都快但一旦商品数据上了万条、用户访问量突然上来很多隐藏问题就暴露了。性能优化不需要一来就上Redis、上消息队列先做两件性价比最高的事加索引和分页优化。商品表建议给category_id和status建联合索引因为用户端最常见查询是“查某个分类下所有上架商品”。SQL写WHERE category_id ? AND status 1时联合索引能直接把扫描行数从几千条降到几十条速度提升肉眼可见。分页上不要用LIMIT 100000, 10这种深分页写法。数据量大的时候会越来越慢因为数据库要扫描并丢弃前十万行。优化方案是记录上一次查询的最大ID然后用WHERE id ? ORDER BY id ASC LIMIT 10。用户端水果列表基本不存在跳页需求这种“下一页”式分页完全够用。如果做了Redis缓存优先缓存首页轮播图、热门水果TOP10这类读多写少的数据。缓存更新的策略最老实的做法是“更新数据库后删除缓存”下一次请求重建缓存。这个模式叫Cache Aside Pattern对付这个小项目绰绰有余完全不需要引入Canal或者消息队列去搞最终一致性。5.2 订单金额与库存安全的防线安全这块大部分人的注意力都放在SQL注入上和XSS上但水果购物系统真正的风险点在金额篡改和接口越权。金额篡改是我见过最典型的攻击方式。魔鬼藏在细节里如果前端提交订单时把“商品总价”也作为参数传过来攻击者完全可以把100元改成0.01元。正确做法是后端根据购物车明细重新计算总金额前端传过来的金额只做展示参考绝不能作为结算依据。我处理这个需求时会写一个计算金额的内部方法只允许Service层调用不允许Controller直接组装金额。还有一类问题是越权。很多新手在写“查看订单详情”接口时只用了订单ID作为参数没有校验这个订单是否属于当前登录用户// 错误做法任何人传入订单ID都能查到 Order order orderMapper.selectById(orderId); // 正确做法绑定用户ID LambdaQueryWrapperOrder wrapper new LambdaQueryWrapper(); wrapper.eq(Order::getId, orderId); wrapper.eq(Order::getUserId, currentUserId); Order order orderMapper.selectOne(wrapper); if (order null) { throw new BusinessException(订单不存在); }这个点一定要在代码里写清楚横向越权是安全性漏洞中最常见的一类也是答辩时最容易被问到的一个点。顺便把密码存储也提一下用户密码必须用BCrypt加密不要用MD5因为MD5可以彩虹表反查。6. 常见问题排查与避坑实录6.1 高频报错现象与解决对照表我在带几个开发者做同类项目时整理过一份高频问题对照表这里直接放出来报错现象可能原因解决办法启动报Failed to configure a DataSource没有配置数据源或依赖缺失检查application.yml的数据库连接配置和MySQL驱动依赖访问接口返回404Controller没有被扫描到或路径错误检查启动类是否在Controller同级或父包下RestController和RequestMapping路径要标注正确日期字段返回“2023-01-01T00:00:00”格式Jackson默认序列化格式不含指定格式在application.yml里配置spring.jackson.date-format或加JsonFormat订单扣库存后库存变成负数没有使用条件更新或事务失效改用UPDATE ... WHERE stock #{count}写法检查Transactional是否被同类调用绕过登录后刷新失效Session未持久化到Redis小项目不需要处理否则需要引入spring-session-data-redis图片上传成功但访问404静态资源映射没配置配置WebMvcConfigurer里的addResourceHandlers映射本地文件目录跨域请求拿不到数据缺少跨域配置实现WebMvcConfigurer的addCorsMappings允许指定前端地址访问每个问题都是真实踩过的坑尤其是Controller的扫描路径问题。很多人的启动类放在com.example.controller的同级包下但是Controller却放在com.example.controller.admin路径不匹配导致接口找不到这是初学者最容易忽视的地方。6.2 我踩过的几个典型坑第一个坑是MyBatis-Plus的字段自动填充。建实体类时如果create_time字段用了FieldFill.INSERT自动填充但忘记在实体上配置TableField(fill FieldFill.INSERT)就会造成插入数据库时报空值异常。更稳妥的写法是用数据库的DEFAULT CURRENT_TIMESTAMP兜底代码里即使没赋值也不会出错。第二个坑是服务层事务自调用失效。在同一个类里一个方法methodA调用另一个Transactional方法methodB时事务是不会起作用的因为Spring事务是通过动态代理实现的同类调用是直接调用目标对象绕过代理。解决办法是把需要事务的公有方法放在不同类里或者自己注入自己。这个知识点几乎每次答辩都会被追问。第三个坑是“测试环境一切正常上线后订单我付不了款”。排查半天发现是支付回调接口没设置白名单/回调地址写成了localhost。虽然我们用的是模拟支付但这个排查过程对我的启发是接口联調时一定要提前确认环境地址、端口和防火墙配置不要等到联调现场再折腾。第四个坑个更隐蔽Redis缓存了首页水果列表管理员改完价格后首页依旧显示旧价格。这就是典型的缓存一致性问题。我最后用的办法是改价格的后端接口里主动删除对应的缓存key保证下次读取时重新从数据库加载。不要迷信“过期时间能解决一切”写入频繁的数据必须主动失效缓存。注意这类系统的测试数据不要太随意。至少准备20种以上的水果分类数据、三种不同角色账号管理员、普通用户、受限用户并且订单数据要有覆盖所有状态的样本。答辩演示时直接操作真实状态比临时造数据从容得多。最后再分享一个个人经验这种Spring Boot水果购物管理系统真正做完一遍之后你最大的收获不是“会写接口了”而是理解了业务状态和数据建模之间的耦合关系。后续再做其他管理类系统只要把商品换成图书、服装、课程整套设计思路都能平移过去。如果你正在做类似项目建议把精力优先花在订单状态流转、库存安全、权限校验这三个点上它们才是这个系统的灵魂。