做农副产品线上商城这个项目是我在接下一个课程设计任务时开始认真琢磨的。当时甲方给的要求很简单做一个能跑起来的 Spring Boot 电商系统卖的是蔬菜水果、粮油禽蛋这类农副产品要有完整的用户购物流程和后台管理功能还得配一篇能过查重、达到一定字数的论文文档。听起来不复杂但真正把每个模块铺开之后才发现农副产品这个品类背后藏着一堆和普通电商不一样的业务细节——生鲜的保质期、不同规格的计价方式、库存扣减的并发控制、订单状态的流转……随便拎出一个都能写一大篇。这篇文章我就把自己从数据库设计、后端接口开发、前端页面联调到最终部署上线的完整过程捋一遍包括当时踩过的几个坑和最后怎么解决的。如果你是正在做同类毕业设计或者想学习 Spring Boot 电商项目搭建的开发者这套系统的设计思路和实操细节应该能帮你少走不少弯路。1. 农副产品商城这个选题为什么值得认真做1.1 传统农副产品销售的现实痛点我一开始也觉得农副产品商城无非就是个简化版淘宝把用户注册、商品列表、购物车、下单支付这一套流程跑通就算完事。但真正去农贸市场和几个做蔬菜批发的档口老板聊过之后发现这个赛道和卖衣服卖数码产品差别很大。农副产品的第一特点是非标准化。一斤土豆、一箱苹果、一只宰好的鸡在规格、重量、新鲜度上都有波动没法像工业品一样用统一的 SKU 去管理。第二特点是时效性强今天摘的菜明天就可能不新鲜订单和库存之间的时间窗口很短。第三特点是价格随行就市批发市场每天凌晨的价格都可能不同后台需要能灵活调价。这些痛点放在线上商城系统里直接影响了数据表设计——商品不能只有单一价格要支持按斤、按件、按箱多单位计价库存不能只记录数量还要考虑“今日库存”和“明日进货”的状态订单不能只有简单的待付款和已发货最好能区分出待接单、配送中、已签收这些和生鲜配送相关的环节。1.2 系统的总体定位与功能范围我做的这套系统项目代号 r7duh7er定位是一个面向中小型农副产品经销商的前后端分离商城核心覆盖三条业务主线买家端注册登录、浏览分类商品、搜索、加入购物车、提交订单、在线支付模拟、查看订单状态、确认收货、发表评价。卖家端运营后台商品上下架、库存调整、价格设置、订单处理发货、完成、查看销售统计。管理员端用户管理、类目管理、 Banner 轮播图管理、系统公告、订单全局干预。整个系统用 Spring Boot 提供 RESTful API前端采用 Vue 生态构建页面通过 JSON 进行数据交互。开发过程中我把论文文档、数据库脚本、部署说明都一并整理好了加起来超过一万字后面如果需要回查设计依据翻自己的文档比翻零散笔记方便得多。1.3 这套系统适合哪些人参考如果你是这几类人我觉得这套完整方案值得认真看一遍正在做电商类毕业设计、课程设计的学生需要一套功能完整、能演示、能写进论文的源码和设计思路。想系统学习 Spring Boot 整合 MyBatis-Plus、Redis、JWT 等主流技术栈的开发者想找一个业务逻辑不过于复杂但链路完整的案例。中小商户想做农产品线上销售的小程序或 Web 商城想先看看核心流程在技术上的落地方式。当然如果你完全没接触过 Java 后端这篇文章里涉及的一些概念可以先用生活化理解去代入我尽量把每个关键决策背后的“为什么”也讲清楚。2. 技术选型复盘Spring Boot 生态下的务实搭配2.1 为什么选 Spring Boot 而不是别的框架做这类商城系统市场上主流选项无非是 Spring Boot、PHPThinkPHP/Laravel、PythonDjango/Flask和 Node.js。我最终选择 Spring Boot主要不是因为它“流行”而是它在电商这种偏事务型、偏业务复杂度的场景里确实最稳。生态成熟主流电商中间件Redis、RabbitMQ、Elasticsearch和 Spring Boot 的整合资料最多出了问题很快能找到解决办法。事务管理农副产品的库存扣减、订单生成、支付回调需要强事务保障。Spring 的声明式事务把这一块处理得非常优雅。部署友好一个内置 Tomcat 的 jar 包就能跑对后面的服务器部署非常友好。学生群体最熟悉如果做毕业设计答辩时老师对 Spring Boot 的认可度高也更容易解释。有一点需要提醒Spring Boot 版本我选的是 2.7.x而不是 3.x。原因是 3.x 强制要求 Jakarta EE 规范部分老牌整合包比如某些代码生成器、开源后台模板兼容性还没完全跟上没必要在项目里冒这个兼容性风险。2.7.x 目前仍是中小企业项目里非常稳定的选择。2.2 持久层与前端方案的取舍持久层我用的是 MyBatis-Plus 而不是原生 MyBatis 或者 JPA。原因很简单MyBatis-Plus 提供了 BaseMapper 通用方法单表 CRUD 基本不用写 SQL配合它的条件构造器Wrapper代码量能省下一大半。而且它的分页插件、逻辑删除、字段自动填充这些功能在商城系统里几乎逐个用得上。前端部分我采用 Vue 2 Element UI 的组合。Vue 3 当然更好但考虑到后台管理类页面的快速开发Element UI 在 Vue 2 上依然非常成熟组件丰富文档多遇到问题好排查。买家端页面我单独写了几个页面整体保持清爽的绿色基调毕竟农副产品的品牌印象里“绿色”“新鲜”是核心关键词。项目结构上我采用了经典的分层架构com.r7duh7er ├── controller // 接口层 ├── service // 业务逻辑层 ├── mapper // 数据访问层 ├── entity // 实体类 ├── dto // 请求/响应对象 ├── config // 配置类 ├── common // 通用工具、统一返回、异常处理 └── utils // 工具类这样一个后端目录结构对团队协作和答辩展示都很友好评审看你代码结构的时候一眼就能知道你清楚“高内聚低耦合”这件事。2.3 统一响应与异常处理的细节很多新手写后端接口每个接口返回的数据结构都不一样有的返回 Map有的直接返回实体前端联调的时候非常痛苦。我从一开始就定义了一套统一的响应体{ code: 200, message: 操作成功, data: {} }后端所有 Controller 都返回这个结构前端只看 code 是否为 200 判断成功失败。配合全局异常处理器任何业务异常、参数校验失败、未知异常都会被捕获并转换成统一响应格式不会把一堆堆栈信息直接丢给前端。这个设计看起来很简单但它是整个前后端联调顺畅的前提。我在论文里也单独花了一节讲 API 设计规范答辩时老师问“你接口怎么设计的”可以直接把这一块抛出来。3. 核心功能模块拆解买家、卖家、管理员三条逻辑主线3.1 用户认证与权限控制一开始我想着用 Session 做登录状态但前后端分离 多端适配的场景下Session 的跨域处理和分布式扩展都比较麻烦所以我用了 JWTJSON Web Token方案。流程是这样的用户提交手机号和密码后端校验通过后生成一个带过期时间的 token 返回给前端前端把 token 存到 localStorage之后每次请求都在请求头里带上后端通过拦截器解析 token把用户信息放入请求上下文。权限控制方面我给用户表加了一个 role 字段0 表示买家1 表示卖家/运营2 表示管理员。拦截器里做简单的 URL 前缀匹配/admin/**开头的接口必须角色为管理员/seller/**开头必须角色为卖家买家端接口只要登录即可访问。密码存储一律用 BCrypt 加密这个细节虽然系统里只有几个地方体现但意义重大直接在论文的安全设计部分写清楚属于答辩加分项。3.2 农副产品分类与商品多规格管理农副产品的分类我设计了二级结构。一级分类比如“新鲜蔬菜”“时令水果”“肉禽蛋品”“粮油调味”二级分类如蔬菜下的“叶菜类”“根茎类”“瓜果类”。一个二级分类挂多个商品商品可以通过分类 ID 走分类浏览也可以通过关键词走搜索。商品表的设计是重点除了常规的标题、描述、主图、详情外我加了一个price字段和unit字段不支持多规格时直接用这个价格为了兼顾某些商品比如土鸡蛋可以按“盒”也可以按“个”卖我在商品详情表里保留了一个规格扩展字段以 JSON 字符串存储附加规格信息。库存字段stock是必须的但农副产品还要考虑预警。我加了一个min_stock字段当库存低于这个阈值时后台商品列表会标记“低库存”状态提醒运营补货。3.3 购物车、订单与库存扣减的并发处理购物车表设计相对简单user_id product_id quantity checked四个核心字段就够了。下单时要注意的细节比较多我拆成几步前端提交订单时带上购物车勾选商品的 ID 列表。后端逐条校验每个商品的库存是否充足。计算订单总金额。生成主订单记录订单号、总金额、状态、收货信息。生成订单明细记录。批量扣减商品库存。清空对应购物车记录。开启一个事务把这些步骤包起来。这里最关键的是库存扣减。如果直接先查库存再更新库存高并发下会出现超卖。我在 SQL 里用了一条带条件的更新语句UPDATE product SET stock stock - #{quantity} WHERE id #{productId} AND stock #{quantity}受影响的行数为 0 说明库存不足直接抛异常回滚事务。这种方式用数据库行锁天然解决了并发问题比先用 SELECT 再 UPDATE 的方式安全得多。订单号我用了“日期 随机字符串”的生成方式类似yyyyMMddHHmmss 6位随机数保证唯一性的同时方便按时间排序。有同学在答辩时会被问到“订单号为什么这么设计”这个设计理由要能说出来。3.4 订单状态机的流转系统里订单状态我用一个整数字段表示为了让状态流转清晰在 Java 枚举里把状态定义成状态值含义触发条件0待付款订单创建后1待发货支付成功后2已发货卖家后台点击发货3已签收买家点击确认收货4已完成确认收货后5已取消未支付时主动取消或超时取消每一状态变化时系统都会写一条订单日志记录操作人、操作时间、变化前后状态。这个日志表在后续开发或者排查问题时价值很大比如订单停在“待发货”很久了可以直接查日志看到底是哪一步没触发。模拟支付环节我用了一个简单的扫描支付页面点击“模拟支付”直接调用后端接口把订单状态改为已支付。真实对接支付宝或微信支付需要商户号和回调接口不在本系统的范围之内但我在代码里预留了payment接口和回调处理的位置论文里也说明如何扩展真实支付。3.5 后台管理端怎么组织模块后台管理端的功能我分成十个菜单模块仪表盘统计数据、商品管理、分类管理、订单管理、用户管理、轮播图管理、公告管理、评论管理、库存预警、系统设置。仪表盘上展示三块统计今日订单数、今日销售额、商品总库存量外加最近七天的订单趋势柱状图。这个统计页面不用搞很复杂的数据可视化平台用 ECharts 在页面里画两个图即可。对应后端接口是几个带日期条件的 COUNT 和 SUM 查询SQL 写起来都不难。这里有一个实用的思路不要想着把所有统计都实时计算比如“今日销售额”可以等到经理点开页面的时候才去查这两张表性能完全够用。没必要为了一个小页面引入一套实时数仓。4. 数据库设计农副产品场景下的几个关键决策4.1 核心表结构与关联关系这套系统一共设计了 12 张表核心的表关系我整理如下user用户表id, username, password, phone, role, avatar, create_timecategory商品分类表id, parent_id, name, sort, iconproduct商品表id, category_id, name, subtitle, main_image, images, detail, price, unit, stock, min_stock, sales_count, status, create_timecart购物车表id, user_id, product_id, quantity, checkedorder订单表id, order_no, user_id, total_amount, status, receiver_name, receiver_phone, receiver_address, remark, create_time, pay_timeorder_item订单明细表id, order_id, product_id, product_name, product_image, price, quantity, subtotalorder_log订单日志表id, order_id, operator, action, detail, create_timebanner轮播图表notice公告表comment评论表id, product_id, user_id, content, rating, create_timeadmin_user后台用户表因为前台用户和后台管理员在登录和权限上做了区分所以分开建表比较好管理。用 MyBatis-Plus 的代码生成器根据这些表结构能一键生成 entity、mapper、service、controller 骨架极大提升开发效率。4.2 索引、时间字段与逻辑删除普通字段外我在关键查询字段上建了索引product.category_id上建普通索引因为分类浏览是主入口。order.user_id上建普通索引因为用户查询“我的订单”高频。order.order_no上唯一索引因为订单号要保证全局唯一。cart.user_id上建索引避免查询购物车时全表扫描。时间字段我统一用datetime类型创建时间由 MyBatis-Plus 的TableField(fill FieldFill.INSERT)自动填充更新时间用同注解的INSERT_UPDATE自动处理。这样新增记录时不需要手动 set 时间减少漏填的隐患。逻辑删除我启用了 MyBatis-Plus 的全局逻辑删除配置删除商品、分类等数据时执行的是 UPDATE 把deleted字段置 1而不是真正 DELETE。这样即使误删也能恢复论文里也可以作为一个设计亮点写出来。4.3 为什么把商品图片存在本地目录商品详情和主图我选择存储在本机磁盘目录项目 resources 下配置的虚拟路径映射而不是直接塞进数据库的 BLOB 字段也不是上传到云对象存储。理由本地存储实现最简单一个文件上传工具类 一个路径映射配置即可不需要引入第三方依赖。课程设计和演示系统对并发要求不高本地磁盘完全够用。部署到服务器时只需要单独挂载一个/upload目录并做好 Nginx 或 Tomcat 的静态资源映射即可。这个方案有一个需要提前注意的点项目重新打包部署时上传目录必须脱离 jar 包本身的解压目录否则打包会丢失历史图片。后面我会专门在部署章节说明这个坑。5. 本地调试与服务器部署完整记录5.1 开发环境准备清单开发这套系统时我用的环境是一件件核对过的给一个可以直接照着装的清单工具版本说明JDK1.8 及以上我用的 1.8稳定优先Maven3.6.x管理项目依赖MySQL5.7 / 8.08.0 需要注意驱动版本Node.js14前端项目编译IDEIntelliJ IDEA后端开发特别注意 MySQL 8.0 的驱动类名是com.mysql.cj.jdbc.Driver5.7 则要用com.mysql.jdbc.Driver这个差异在启动报错时特别迷惑人。5.2 配置文件里必须认真核对的三处application.yml里最核心的配置是这三块spring: datasource: url: jdbc:mysql://localhost:3306/r7duh7er_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver servlet: multipart: max-file-size: 10MB max-request-size: 50MB redis: host: localhost port: 6379第一个是数据库连接串serverTimezone必须显式指定为Asia/Shanghai否则时间戳字段和 Java 里的 LocalDateTime 之间会出现 8 小时偏移。第二个是文件上传大小限制默认 1MB 根本不够传商品详情图要放开。第三个是 Redis 配置系统里了两个 Redis 用途缓存商品分类列表、记录购物车中选中状态如果 Redis 没启用项目虽然能启动但部分缓存相关功能会失效。5.3 本地跑通之后的打包部署后端打包用 Maven 命令最直接mvn clean package -DskipTests执行完成后target目录下会生成一个 jar 包。注意 Spring Boot Maven 插件要配置好repackage否则打出来的是普通 jar直接java -jar会提示没有主清单属性。前端部署前先执行npm run build生成dist目录然后把它放到服务器上通过 Nginx 进行静态资源映射。这里需要检查后端接口的跨域配置因为前后端分离部署之后前端域名和后端域名很可能不一样浏览器会拦截跨域请求。我的做法是在后端写了一个 CORS 配置类允许所有源访问Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); }部署上线后的验证流程我建议按这条链路走一遍访问前端首页确认页面能正常打开。执行一次注册、登录、浏览商品、加入购物车、下单、支付、发货、签收的完整流程。进入后台管理页尝试新增一个商品分类、上传一张轮播图、修改一次库存。刷新 Redis 缓存确认分类列表和推荐商品能正常从缓存读取。6. 踩坑冷记录三个让我折腾很久的问题6.1 图片上传成功却访问不到开发时商品图片上传接口返回成功但前端预览时 404。排查发现Spring Boot 默认不会把/upload/**这类路径映射到本地磁盘目录需要在配置类里重写addResourceHandlersOverride public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadPath /); }uploadPath 我配置成了一个可以在配置文件里覆盖的变量默认是项目根目录下的/upload/。后来部署到服务器时我把这个路径改成了/data/r7duh7er/upload/并在 Nginx 里把这个前缀反向代理到对应目录。6.2 前端请求接口总是报 401联调阶段前端一直报 401 未授权明明已经登录成功了。最后定位是拦截器对 preflight 请求的处理有问题。浏览器在发送跨域 POST 请求之前会先发一个 OPTIONS 请求做预检我的拦截器把所有请求都拦截并尝试解析 token预检请求自然没有 token就被拒绝了。解决方法是让拦截器放行所有 OPTIONS 请求跨域配置只负责跨域能力token 校验只对真正的业务请求生效if (OPTIONS.equalsIgnoreCase(httpServletRequest.getMethod())) { return true; }这个细节在论文里写成“CORS 预检请求处理流程”很多答辩老师会感兴趣。6.3 事务注解不生效的排查过程有一个接口需要同时更新订单状态和扣减商品库存我套了一个Transactional注解但测试时发现两步操作不会一起回滚故意把商品 ID 传错导致扣减库存时抛异常结果订单状态还是被提交了。最后发现原因很典型类内部方法调用导致事务失效。我在OrderService里写了一个createOrder()方法它内部直接调用了同类的deductStock()方法而deductStock()上的事务注解不会生效——因为 Spring 事务代理只拦截外部调用内部调用绕过了代理。修法是新建一个独立的InventoryService把deductStock()放进去在createOrder()里注入这个 Service 来调用。如果项目结构已经不允许新增类也可以用从 Spring 容器里取自身代理对象的办法但更推荐前者。事务这块我写进论文时用的是“调试与优化”章节当时记录的问题现象、定位过程、解决方案都写清楚了答辩时老师专门追问了“为什么内部调用会失效”其实把 AOP 代理机制讲明白就能过关。7. 做完整个项目之后我的一些个人体会按说项目到这里功能都跑通了论文也写完了但我还是想多聊几句这套系统背后的东西。农副产品商城和普通标准化商品商城在业务上确实有挺大差异。比如库存字段在普通商城就是个数字但在农副产品这里几乎要额外考虑“今日供应量”和“明日采购量”这样的分层价格也不是简单一个定价它和不同规格、不同包装方式强相关。如果你不是只做个演示系统而是真的想在某个区域市场把水果蔬菜订单跑起来我强烈建议把“商品规格”和“库存批次”这两个模块设计得再细一层。关于代码组织的体会是靠踩坑堆出来的。统一响应体这个习惯是我做项目过程中受益匪浅的一个决策前端同事后来跟我说“你接口永远一个格式我这边能少写一半判断逻辑”。这种细节不亲自做完一个前后端分离的完整项目很难有体感。另外想提一下文档和代码同步这件事。很多人是项目写完了才补论文文档我这次是边开发边写比如数据库变更记录、接口调整说明、部署步骤都在开发当天同步进文档。最后整理论文时时间压力小很多而且逻辑非常连贯因为每一步变更都有记录可追溯。这套系统的源码、数据库脚本、开发环境和部署文档我整体整理过一遍整个工程在本地环境的运行路径是清晰完整的。如果在复现这个项目的过程中遇到启动报错、接口不通、页面空白这类的具体问题建议优先按我上面写的“验证链路”逐节点排查大部分问题都出在环境配置或路径映射上。农副产品线上化这个大方向后面还能延展的方向还有很多比如对接电子秤称重下单、批发市场的价格行情展示、配送路线规划。有机会我可能会在现有这套系统的基础上继续迭代如果大家在做同类项目时有更好的电商库存方案或者生鲜配送经验也欢迎在评论区交流。