做超市果蔬销售商城这种毕业设计项目最怕的不是功能写不出来而是技术栈选得乱、表结构设计得随意、后期改需求改到崩溃。SpringBoot加SSM这套组合在Java Web领域里算是非常成熟的搭配了尤其适合商城这类业务逻辑清晰、前后端交互频繁的系统。这篇文章就以“springboot_ssm880超市果蔬销售商城管理系统”为例从项目整体设计、数据库建模、核心模块实现到常见问题排查完整讲一遍实际开发中会踩到的坑和值得留意的细节给正在做类似课题的同学一个可以直接参考的落地思路。1. 项目整体设计与技术选型思路1.1 为什么是SpringBoot SSM而不是其他组合先把这个最容易被忽略的问题说清楚。很多同学拿到课题就急着写代码结果写到一半发现技术栈选得别扭改起来特别痛苦。SSM原本指Spring Spring MVC MyBatis这三件套而SpringBoot本身并不是用来替代SSM的它是把Spring生态里那一堆繁琐的XML配置给“自动装配”掉了。也就是说SpringBoot SSM的实际含义是用SpringBoot作为项目骨架内部仍然使用Spring MVC处理请求、MyBatis操作数据库但不需要再手写web.xml、spring-mvc.xml、mybatis-config.xml那一堆配置文件。市面上很多商城管理系统用的还是传统的SSM工程结构手动配置数据源、事务管理器、Mapper扫描路径每加一个模块都要改配置维护成本确实高。而SpringBoot用application.yml一个文件就能搞定数据源、端口、日志、MyBatis映射等核心配置配合注解式开发代码量能少三分之一。对于果蔬销售商城这种需要频繁调整商品分类、库存、促销规则的场景SpringBoot的快速迭代优势非常明显。再说为什么不用SpringCloud或者微服务。商城管理系统作为毕业设计或者中小型项目用户量、数据量都远没到需要分布式的地步。单机部署、单体架构完全够用强行拆成用户服务、商品服务、订单服务反而把事务问题搞复杂了。果蔬商城的核心是新鲜度、价格波动、库存变动这些业务强依赖数据库事务单体架构里一个Transactional就能搞定的问题拆成微服务就得引入分布式事务框架纯粹是给自己挖坑。1.2 项目功能模块划分基于标题中的“超市果蔬销售商城”这个定位我把它拆成两大类角色前台用户端和后台管理端。很多同学会把这两块混在一起写后续维护特别痛苦这里建议从一开始就明确模块边界。前台用户端主要包含用户注册与登录普通用户后续可以扩展微信登录果蔬商品浏览按分类、按关键词搜索、按销量或价格排序商品详情展示图片、价格、库存、产地、上架时间购物车管理加入购物车、修改数量、删除、批量结算订单确认与提交收货地址、订单备注、支付模拟个人中心订单列表、订单详情、取消订单、收货确认后台管理端主要包含管理员登录独立账号体系或基于角色权限商品管理新增、编辑、上下架、库存调整分类管理水果、蔬菜、进口果蔬、有机果蔬等层级分类订单管理查看、发货、完成订单、退款处理用户管理用户列表、启用禁用数据统计销售概况、果蔬销量排行、库存预警在实际开发中我建议把前后台做成同一个SpringBoot项目里的两个模块或者两个包路径比如/admin/**和/api/**而不是拆成两个独立工程。理由很简单毕业设计答辩时老师大概率会关注你的项目能不能一键跑起来拆成两个工程意味着要同时启动两个端口演示成本和出错的概率都翻倍。一个工程、两套Controller、一套Service既节省时间也让代码结构更清晰。1.3 开发环境与工具清单直接给出一套我实际用过的、比较省心的组合这一步极其关键因为不同JDK版本和依赖版本搭配导致的问题是开发期浪费时间的重灾区JDK 8SpringBoot 2.x 最稳定的基准版本网上绝大多数资料、排错经验都基于这个组合。如果项目要求必须用JDK 17那就老老实实选SpringBoot 3.x但很多老教程里的写法会不兼容。Maven 3.6统一管理依赖版本。SpringBoot 2.7.182.x里最新的维护版本稳定兼容性好。MyBatis 2.3.xSpringBoot starter加 mybatis-plus 3.5.x如果你想要条件构造器、分页插件这些现成能力强烈建议直接用mybatis-plus能省大量重复SQL。注意普通mybatis和mybatis-plus的starter不要同时引入会冲突。MySQL 8.0默认字符集utf8mb4避免中文乱码和特殊表情符号问题。Redis可选果蔬商城首页的轮播图、热销榜单这类数据变动不频繁用Redis做缓存能明显提升响应速度。如果只是毕业设计这部分可以作为加分项不是必选项。前端Thymeleaf 模板引擎适合前后端不分离快或者 纯HTML Vue Axios前后端分离调用接口。我的建议是看你的答辩侧重点。如果老师更看重项目完整性Thymeleaf一条龙搞定如果老师关注工程化能力选前后端分离。提示项目命名和包名建议用有意义的英文比如com.example.fruitmarket不要用com.demo.ssm880这种看起来像随机生成的包名。一个好的包名结构本身就在向评审老师展示你的代码规范意识。2. 数据库建模与核心表设计2.1 果蔬商城表结构设计原则数据库设计是商城系统的地基。果蔬销售和其他商城有个明显区别商品有“新鲜度”和“库存时效”属性水果蔬菜普遍是称重计价的而且价格波动比工业品频繁得多。所以表结构不能照搬图书商城或者服装商城的设计必须针对果蔬场景单独做调整。我通常把核心表拆成六张用户表、后台管理员表、商品分类表、商品信息表、购物车表、订单主表、订单明细表。等一下这样说是七张实际上订单相关的还有一张订单状态日志表用来记录订单从待付款到已取消、已发货、已完成的全过程状态流转。这八张表基本覆盖一个商城系统的所有核心数据模型。举一个订单状态日志表的例子。商城订单不是简单的一张表顶到底的因为每个订单的状态可能被修改多次如果只在订单表里用一个status字段存当前状态那你就永远无法追溯这个订单经历过哪些状态。果蔬类商品在配送过程中还可能出现“缺货退款”、“腐烂拒收”这些特殊情况所以日志表一定要设计。CREATE TABLE order_status_log ( id bigint(20) NOT NULL AUTO_INCREMENT, order_id bigint(20) DEFAULT NULL COMMENT 订单ID, order_status tinyint(4) DEFAULT NULL COMMENT 状态0待付款 1待发货 2已发货 3已完成 4已取消 5退款中, change_reason varchar(255) DEFAULT NULL COMMENT 变更原因, create_time datetime DEFAULT NULL COMMENT 创建时间, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单状态日志表;2.2 商品表和分类表的字段设计细节果蔬商品表的核心字段除了一般的商品名、图片、价格、库存、销量之外要额外注意这几个unit单位斤、个、盒、把。果蔬称重商品多套用“件”这个概念会让人理解混乱。origin产地水果蔬菜对产地很敏感用户也会关注商品列表页能不能按产地筛选也要靠这个字段。shelf_life保质期用于后台展示“保鲜期”部分系统还可以做临期提醒。is_on_sale上架状态果蔬价格波动大运营经常要临时下架某种商品这个字段必加。stock库存果蔬有变质损耗的可能实际开发中要支持后台手动调整库存比如报损减少不要只有销售减库存一条路径。分类表建议设计成支持父子级联的因为果蔬会有“水果 - 热带水果 - 榴莲”这类层级关系。用一个parent_id字段就可以实现无限级分类。前端展示时一级分类作为导航栏的大类二级分类作为下拉或者侧边栏过滤条件。CREATE TABLE category ( id bigint(20) NOT NULL AUTO_INCREMENT, parent_id bigint(20) DEFAULT 0 COMMENT 父分类ID0表示顶级分类, name varchar(50) NOT NULL COMMENT 分类名称, sort int(11) DEFAULT 0 COMMENT 排序值越小越靠前, is_deleted tinyint(1) DEFAULT 0 COMMENT 逻辑删除标志, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品分类表;这里有个在实际项目中很容易被忽略的细节排序字段sort必须是int而不是int(11)默认为0就行后面你会发现运营在后台调整商品顺序是特别高频的操作。另外一定要设置逻辑删除is_deleted因为商品分类一旦被删除底下所有商品就全成了“无家可归”的孤儿数据。如果采用物理删除哪怕只是手滑删了一个分类都得写脚本去恢复关联关系非常痛苦。2.3 购物车与订单表的关系设计果蔬商城的购物车表有两种设计风格。一种是像京东淘宝那样购物车作为一个独立实体用户退出登录、换设备之后购物车数据还在另一种是轻量级的购物车数据不落库只放在Session或者Redis里。我建议毕业设计还是设计成落库的购物车表理由有两个一是前后端分离的情况下Session管理购物车会很费劲二是有真实的购物车表订单结算流程会有更强的逻辑支撑力。购物车表的核心字段user_idproduct_idquantity数量checked是否选中用于批量结算唯一索引uk_user_product避免同一用户同一商品重复插入用Insert...OnDuplicateKeyUpdate订单主表和订单明细表是典型的一对多关系。order主表存订单号、总金额、用户ID、收货信息、订单状态order_item明细表存商品快照——注意是商品快照不要直接关联商品表。果蔬商品价格每天都在变如果订单明细里不记录“购买时的价格”到时候用户查历史订单就会看到现在的价格完全乱套。所以order_item里必须冗余一份商品名称、商品图片、单价、数量、小计。3. 核心功能实现与关键代码解析3.1 用户登录与权限校验商城系统里用户和管理员是两套完全不同的身份体系。有的同学喜欢用一张表加一个role字段搞定但实际开发中我更推荐拆成两张表user和admin。理由很简单用户端需要维护收货地址、积分、会员等级等一大堆用户资料字段管理员只需要账号、密码、手机号、最后登录IP这些基本信息。混在一张表里会导致大量字段为空查询效率低不说代码里还得到处判断角色特别不舒服。登录校验这块SpringBoot生态里最常用的方案有两个Session 拦截器、JWT令牌。如果做的是Thymeleaf这种前后端不分离的项目用Session配合拦截器就够了简单直接如果做前后端分离的Vue项目建议用JWT。这里用JWT做一个示例因为前后端分离是当前的主流要求。引入依赖dependency groupIdcom.auth0/groupId artifactIdjava-jwt/artifactId version3.19.2/version /dependency登录接口核心逻辑PostMapping(/api/user/login) public Result login(RequestBody LoginVO loginVO) { User user userService.login(loginVO.getUsername(), loginVO.getPassword()); if (user null) { return Result.error(用户名或密码错误); } // 生成JWT令牌 MapString, Object claims new HashMap(); claims.put(userId, user.getId()); claims.put(username, user.getUsername()); String token JWT.create() .withClaim(userId, user.getId()) .withClaim(username, user.getUsername()) .withExpiresAt(new Date(System.currentTimeMillis() 7 * 24 * 3600 * 1000)) .sign(Algorithm.HMAC256(your-secret-key)); return Result.success(token); }拦截器校验public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || token.isEmpty()) { response.setStatus(401); return false; } try { DecodedJWT verify JWT.require(Algorithm.HMAC256(your-secret-key)).build().verify(token); request.setAttribute(userId, verify.getClaim(userId).asInt()); return true; } catch (JWTVerificationException e) { response.setStatus(401); return false; } } }切记JWT的密钥不要硬编码在代码里虽然毕业设计不影响但这是真实项目里的大忌。可以用Value(${jwt.secret})从配置文件中读取。3.2 商品管理与MyBatis分页查询商品管理模块最核心的点是分页和多条件筛选。果蔬商城的商品列表页用户通常要同时按分类、价格范围、关键词、产地来筛选如果还用LIMIT offset, size手写分页每加一个筛选条件就要改一次SQL效率太低。推荐直接用MyBatis-Plus自带的分页插件。配置方式很简单Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }之后分页查询只需要一行PageProduct page new Page(pageNum, pageSize); LambdaQueryWrapperProduct wrapper new LambdaQueryWrapper(); wrapper.eq(Product::getCategoryId, categoryId) .like(StringUtils.hasText(keyword), Product::getName, keyword) .orderByDesc(Product::getSales); productMapper.selectPage(page, wrapper);这段代码看起来简单但有几个细节值得展开讲。第一LambdaQueryWrapper的优势是类型安全的字段名写错了在编译期就能发现不用等运行时报Unknown column。第二条件构造器里不要手动拼接字符串防止SQL注入。第三如果筛选条件是“价格区间”直接用between但注意Java里用BigDecimal接收价格字段不要在数据库用float或double存价格浮点误差会直接导致结算金额不对。在实际做果蔬商城的过程里我踩过一个大坑商品表按销量排序但销量是哪个时间范围的全时间段总销量还是最近30天销量如果导出的排行榜一直是那几样水果霸榜用户会失去新鲜感而且果蔬是强季节性的夏季西瓜销量暴涨冬季几乎归零。因此我建议多加一个monthly_sales字段每周跑一次定时任务把上周销量汇总进去榜单用这个字段排序更能反映真实市场热度。3.3 购物车与下单的事务处理果蔬商城的购物车逻辑比普通商城要更小心因为库存变动的频率太高了。用户把一盒草莓放进购物车过5分钟再结算可能库存已经归零了。所以结算时的库存校验逻辑绝不能省。下单接口的核心流程分五步根据购物车选中的商品ID集合查出所有商品的当前库存和价格。逐个比对购物车数量和库存如果库存不足直接告诉用户哪个商品库存不够。计算订单总金额注意满减、优惠券这类逻辑如果没有可以忽略。生成订单主表记录和订单明细快照。扣减库存、清空对应购物车记录。这五步必须在同一个事务里执行否则就会出现“订单创建成功但库存没扣”这种恶性bug。写法上直接用Transactional(rollbackFor Exception.class)Transactional(rollbackFor Exception.class) public Order createOrder(Long userId, ListCartItemVO cartItems, AddressVO address) { // 1. 遍历购物车生成订单明细快照 BigDecimal totalAmount BigDecimal.ZERO; ListOrderItem orderItems new ArrayList(); for (CartItemVO item : cartItems) { Product product productMapper.selectById(item.getProductId()); if (product null || product.getStock() item.getQuantity()) { throw new BizException(商品库存不足 product.getName()); } OrderItem orderItem new OrderItem(); orderItem.setProductId(product.getId()); orderItem.setProductName(product.getName()); orderItem.setProductImage(product.getImage()); orderItem.setPrice(product.getPrice()); orderItem.setQuantity(item.getQuantity()); orderItem.setSubTotal(product.getPrice().multiply(BigDecimal.valueOf(item.getQuantity()))); totalAmount totalAmount.add(orderItem.getSubTotal()); orderItems.add(orderItem); } // 2. 创建订单主表 Order order new Order(); order.setOrderNo(generateOrderNo()); order.setUserId(userId); order.setTotalAmount(totalAmount); order.setStatus(0); orderMapper.insert(order); // 3. 批量插入订单明细 orderItemMapper.batchInsert(order.getId(), orderItems); // 4. 扣减库存这里用乐观锁 for (CartItemVO item : cartItems) { productMapper.deductStock(item.getProductId(), item.getQuantity()); } // 5. 清空购物车 cartMapper.deleteByUserIdAndProductIds(userId, productIds); return order; }扣减库存要用乐观锁SQL大概是UPDATE product SET stock stock - #{quantity} WHERE id #{productId} AND stock #{quantity}这样即使两个用户同时下单也不会出现超卖。这里为什么不直接select ... for update因为那样会锁住商品行高并发时性能下降而且查询再更新两步操作之间容易产生时间窗口。一条带stock #{quantity}条件的update语句天然就实现了原子性的库存扣减。3.4 订单状态机与模拟支付果蔬商城的订单状态流转建议用一个枚举来维护public enum OrderStatus { PENDING_PAYMENT(0, 待付款), PENDING_DELIVERY(1, 待发货), DELIVERED(2, 已发货), COMPLETED(3, 已完成), CANCELLED(4, 已取消), REFUNDING(5, 退款中); private final int code; private final String desc; // 构造方法和getter省略 }很多同学会把订单状态直接写成status字段的数值然后在前端页面用if(status 0)去判断这样可读性很差。用枚举的好处是代码里写OrderStatus.PENDING_PAYMENT回读性非常清楚而且枚举可以携带code和desc返回给前端时可以直接把中文描述一起带出去。关于支付环节毕业设计不建议对接真实的支付宝或微信支付SDK又需要企业资质又需要域名备案非常繁琐。更合理的做法是做“模拟支付”用户点击支付后系统生成一条支付流水记录模拟第三方支付回调接口更新订单状态。核心代码如下PostMapping(/api/order/pay) public Result pay(RequestParam Long orderId) { Order order orderMapper.selectById(orderId); if (order null || order.getStatus() ! OrderStatus.PENDING_PAYMENT.getCode()) { return Result.error(订单状态异常); } // 生成支付流水 PaymentLog paymentLog new PaymentLog(); paymentLog.setOrderId(orderId); paymentLog.setAmount(order.getTotalAmount()); paymentLog.setPayType(MOCK); paymentLog.setStatus(1); paymentLogService.save(paymentLog); // 模拟支付成功回调更新订单状态 order.setStatus(OrderStatus.PENDING_DELIVERY.getCode()); orderMapper.updateById(order); return Result.success(支付成功); }这个模拟支付流程用了PaymentLog表记录流水好处是以后如果真要接入支付宝只需要替换支付接口的实现订单状态机不用动。这种“面向扩展”的设计思路在答辩时很加分——你不仅是做了一个功能你还考虑了将来怎么演进。3.5 数据统计与销售看板果蔬商城的管理后台一般要有个首页数据看板展示今日销售额、今日订单数、总商品数、低库存预警、近七天销售趋势。这些数据如果每次都是实时从订单表里SUM出来数据量大的时候会很卡所以我建议做一个简单的统计缓存。方案是维护一张daily_summary统计表定时任务每天凌晨跑一次把前一天的订单总额、订单数、成交用户数汇总进去。首页看板的数据大部分读这张表即可近七天的趋势图也直接从这表里查七行数据。实时性要求特别高的“今日销售”数据可以用Redis的INCR自增计数每下一单就累加一次。4. 开发过程中的常见问题与排查技巧4.1 SpringBoot项目启动报错排查这一节必须重点说因为我在指导别人的时候发现刚开始写SpringBootSSM项目60%的时间都花在“启动不起来”这个问题上。常见的有三种。第一种Failed to configure a DataSource: url attribute is not specified。这个报错的意思是数据源没配置。多半是因为application.yml里没写spring.datasource.*配置或者写了但文件后缀不对。SpringBoot 2.x默认加载application.yml或application.properties如果你的配置文件叫application.yaml也能识别但注意文件名不能写错。第二种Invalid bound statement (not found)。这个报错是MyBatis的Mapper接口和Mapper XML映射对不上。排查方向依次是XML文件里的namespace是不是Mapper接口的全限定名XML文件里的id是否和接口方法名一致XML文件有没有被Maven打包进去。最后这个很隐蔽——如果你的XML文件放在src/main/java目录下而pom.xml没有配置resources包含**/*.xml那么XML文件根本不会进入target/classesMyBatis自然找不到。标准做法是把Mapper XML放在src/main/resources/mapper/目录下。第三种Port 8080 was already in use。端口被占用了。用netstat -ano | findstr 8080找到对应PID然后taskkill /F /PID 进程号干掉进程。或者在application.yml里改端口server.port8081。有些同学启动失败是因为忘了关掉上一次运行的实例这个最基础但最常见。4.2 前后端联调时的跨域问题如果前端是Vue等独立工程本地开发时前端跑在localhost:5173后端跑在localhost:8080跨域问题会立刻冒出来。解决办法不复杂SpringBoot中添加一个CORS配置类Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }注意如果用了JWT加Authorization请求头allowedHeaders(*)要确保放行Authorization否则拦截器拿不到token。如果是生产环境allowedOriginPatterns(*)不建议放开而应该配置成实际的域名。4.3 数据库连接池与中文乱码用SpringBoot连接MySQL时pom.xml里的依赖坐标不能写错。常见坑是用了mysql-connector-java老版本驱动在MySQL 8.0下连接报Public Key Retrieval is not allowed。解决方案有两个一是连接字符串加上allowPublicKeyRetrievaltrueuseSSLfalse二是升级到com.mysql:mysql-connector-j即可。中文乱码的问题本质上是字符集三层要统一数据库表结构utf8mb4、连接字符串characterEncodingutf8、前端页面Content-Type: text/html; charsetutf-8。如果只改了连接字符串而建表时用了latin1照样乱码。所以我建议建库语句里就固定CREATE DATABASE fruit_market DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;4.4 MyBatis分页查询失效MyBatis-Plus的分页插件有个经典坑selectPage返回的记录总数total一直是0。原因是你没有注册分页插件或者注册了但被其他拦截器覆盖了。检查一下配置类上是否加了Configuration分页插件的Bean是否被Spring容器管理。另外如果使用了多数据源每个数据源都要注册对应的分页拦截器否则也会失效。4.5 金额与库存的精度问题商城的金额计算是绝对不能出错的。我在开发果蔬商城时就遇到过一个很典型的Bug用户下单结算时商品单价是9.9元购买3份前端计算结果是29.7但后端订单表存的是29.699999999999997。原因是Java里用了double或float做乘法运算。解决方案只有一个所有金额相关字段一律用BigDecimal数据库用decimal(10,2)前端传参用字符串或整数分避免直接传浮点数。5. 项目部署与后续扩展建议5.1 本地打包与一键启动项目开发完成后需要打包成可执行的Jar包。在项目根目录执行mvn clean package -DskipTests打包成功后target目录下会生成xxx.jar。启动命令特别简单java -jar target/fruit-market.jar这其实就是SpringBoot相比传统SSM的最大优势不需要再装Tomcat不需要配置server.xml、context.xml一个Jar包双击就能跑。如果是给老师演示我建议把数据库脚本、Jar包、演示账号统一放在一个部署说明.docx里避免现场演示时找不到数据。如果要在服务器上部署最简单的做法是使用nohupnohup java -jar fruit-market.jar --spring.profiles.activeprod app.log 21 --spring.profiles.activeprod对应的是application-prod.yml里面配置生产环境的数据库连接、端口等。这种“多环境配置文件”的习惯在真实项目中也是必备的。5.2 引入Redis缓存与接口优化果蔬商城首页的商品列表、轮播图、热销推荐如果每次请求都去MySQL里查询哪怕是加了索引数据库的压力也不小。引入Redis后可以把这些热点数据缓存起来减少数据库访问次数。商品详情缓存的大致思路是先从Redis查查不到再到数据库查查到后回写Redis并设置过期时间。类似public Product getProductById(Long id) { String key product: id; String json redisTemplate.opsForValue().get(key); if (json ! null) { return JSON.parseObject(json, Product.class); } Product product productMapper.selectById(id); if (product ! null) { redisTemplate.opsForValue().set(key, JSON.toJSONString(product), 30, TimeUnit.MINUTES); } return product; }需要注意的是写了缓存就一定要考虑缓存和数据库一致性的问题。果蔬商品的价格、库存更新非常频繁如果商品被修改了缓存必须同步失效。最简单的方式是在修改商品的方法里主动删除对应缓存redisTemplate.delete(product: productId);这个方案叫Cache Aside Pattern是实际项目里最常用、最容易理解的缓存更新策略。5.3 后续可以扩展的功能点果蔬销售商城这个选题做完基础功能后其实有非常多可以做“小而美”扩展的方向。我给下面几个方向排个优先级会员积分与等级下单返还积分积分可抵扣现金。这个能让用户体系更有黏性实现也不难在订单结算时增加积分计算逻辑即可。果蔬新鲜度标签给商品打上“产地直采”“当季热销”“有机认证”标签在商品列表页展示彩色标签。这个纯粹是前端展示层面的扩展但很契合果蔬商城的气质。定时下架与临期提醒设置商品的售卖截止时间到期自动下架。对果蔬这种保质期敏感的商品来说这个功能非常实用。Excel报表导出用EasyExcel导出商品列表、订单报表。很多企业项目都会要求报表导出功能写进简历里也是一个亮点。对接热门AI接口做智能推荐根据用户历史购买记录推荐可能喜欢的果蔬。每个扩展点都可以独立写个小文章来介绍但核心的SpringBootSSM骨架、数据库设计思路和事务处理逻辑都在这篇文章的范畴内把地基打牢上面这些扩展点都是水到渠成的事。5.4 写在最后的心得做果蔬销售商城这类系统最大的价值不在于把增删改查写出来而在于你能不能把“商品—库存—订单—支付—统计”这条链路完整地跑通并解释清楚。我在实际开发里最大的体会是表结构设计是最花时间的环节千万不要一上来就写代码。你把订单快照、库存乐观锁、状态日志这几张表想明白了后面的ServiceImpl写起来就是顺水推舟。倒是那些看似不起眼的金额精度、分页插件、跨域配置问题才是真正会在答辩现场让你卡壳的点。如果时间充裕建议把JWT登录、Redis缓存、模拟支付这三个点都做进去。它们分别代表了权限、性能、业务闭环三个维度足以把你的项目从“又一个增删改查”提升到“有完整工程思维”的高度。遇到问题多去看看SpringBoot官方文档和MyBatis-Plus的代码注释比到处复制粘贴要靠谱得多。
