拓冰网站定制 
每年下半年的毕业设计咨询季我接到最多的题目之一就是“助农电商平台”。很多同学找我时手里只有一句话做一个Java的农产品批发与零售系统。但等真正开始动手才发现“批发”和“零售”根本不是在一个购物车里加两个价格那么轻松。这篇文章我就以“阳阳助农电商平台”为例把整个项目的设计思路、技术选型、数据库建模、核心代码实现和踩坑经历完整讲一遍。内容包括完整的实现方案、关键代码片段、SQL脚本和答辩经验适合正在做Java毕设的同学参考也适合想快速搭建一套农产品双模式交易系统的开发者。我尽量把每一步的“为什么这么做”也讲清楚毕竟毕设答辩时老师最爱问的就是“你为什么这样设计”。前几年我习惯一上来就教大家搭环境、写CRUD后来发现那样做出来的系统根本经不起答辩提问。现在带项目我都会让学生先把业务模型想清楚因为助农电商和普通电商最大的区别在于交易模式的复杂程度——一套系统里同时跑着B2B批发和B2C零售两套逻辑这是整个系统所有设计的源头。下面我把完整过程展开讲。1. 业务模型拆解批发与零售两条交易线如何共处一室1.1 从“批发零售”双模式说起助农电商平台的核心场景是农民/合作社在平台上发布农产品买家可以按斤/按件少量购买零售也可以一次性大批量采购批发。这两种模式看着都是“下单付款”但对系统的要求差别巨大。零售购物车是典型的电商逻辑用户选几个商品按固定单价结算包邮或按重量计运费。而批发订单有几个零售里根本没有的规则起批量比如大蒜低于50斤不卖阶梯价格买100~499斤是2.5元/斤买500斤以上是2元/斤按重量/件数走大宗物流运费单独协商不走快递模板定金/尾款部分批发场景下甚至会有先付定金、尾款待称重后结算的需求第一期我通常不让学生做但答辩可以说这是后续扩展点。所以从一开始就要想清楚不是做一个两边都能用的购物车而是要做一个“模式感知”的系统同一件商品在不同模式下表现不同。商品详情页要显示“零售价”和“批发价区间”购物车结算时要识别当前订单走哪一套价格引擎。这是整个业务建模的第一块基石。1.2 平台角色与权限边界我设计的角色是三种农户卖家、买家采购商/普通消费者、平台管理员。很多同学会把“买家”细分成“批发商”和“普通用户”两个角色其实没必要。因为一个采购蒜头的老板也可以顺手在平台给自己家里买两斤水果同一个账号既走批发订单也走零售订单才是正常状态。角色按“功能权限”划分而不是按“用户类型”划分。农户端店铺管理、商品发布/编辑/上下架、价格规则设置、订单发货、库存管理、销售统计买家端商品浏览、购物车、下单、支付演示阶段通常模拟、订单查看、收货确认管理后台用户管理、类目审核、商品审核助农平台建议保留审核环节、数据看板。权限控制层面我没有上Spring Security那一套重量级框架而是用JWT 拦截器 自定义注解实现。原因很简单毕设项目里Spring Security配置繁琐而且答辩时很难三言两语讲清楚它的过滤器链原理而JWT拦截器是学生自己能一行一行讲明白的。下面会给出具体代码。1.3 非功能性需求老师眼里“真实系统”的标准功能做完只是及格想拿高分要在答辩时体现出你考虑过“真实系统才会遇到的问题”。我自己带学生时固定检查这几个点数据一致性库存扣减是否防超卖订单金额计算是否有精度问题并发能力秒杀场景下助农平台有时会做限时特价Redis预扣库存是否扛得住安全性密码是否加密存储接口是否校验登录状态可用性图片传哪里404、异常统一返回吗可维护性目录结构是否分层清晰代码注释是否合格这些点看着不起眼但我在答辩现场见过太多学生被“你这个系统并发100个人买同一个商品库存会不会变负数”一句话问住。所以本文后面的章节会围绕这些“非功能点”逐个展开。2. 技术选型为什么锁定了Spring Boot MyBatis Plus Redis这套组合2.1 后端框架生态成熟是第一选型标准当前做Java毕设Spring Boot基本是唯一解——你自己写SSH或者Servlet既要处理大量模板配置又显得和主流技术栈脱节。我用的是Spring Boot 2.7.x不要用3.x3.x要求JDK17很多同学的机器环境还在JDK8折腾环境就得浪费一下午。持久层选择MyBatis Plus而不是原生MyBatis核心原因是它能省掉80%的单表CRUD代码。BaseMapperT直接提供了selectById、insert、updateById等常用方法复杂多表查询再手写XML。但有一点必须提醒用了MP也要会写SQL。答辩时老师一定会抽查某个查询的实现如果支支吾吾地说“MP自动生成的”印象分会很差。我通常要求学生至少能当场写出一条多表JOIN GROUP BY的SQL。2.2 缓存与高并发组件Redis承担了什么职责Redis在这个系统里承担三件事热点商品缓存、购物车临时数据可选、库存预扣计数。为什么要缓存农产品详情页访问量往往集中在几个爆款上每次都查MySQL会把数据库打满。我用Redis缓存商品详情key设计为product:detail:{id}过期时间30分钟后台修改商品时主动删除缓存。库存预扣的逻辑更关键后面专门开一节讲。有些同学会把用户的购物车也塞进Redis我建议第一次做不要这样。购物车老老实实建一张cart_item表存MySQL虽然多写几个接口但数据可解释性强答辩时画ER图也方便。Redis只承担“缓存”和“计数”这类强调性能的角色。2.3 文件存储不依赖云服务的本地方案农产品需要大量图片果实实拍、产地环境文件上传是必做功能。很多教程直接让配置阿里云OSS但学生自己没有云资源答辩环境也可能断网。我更推荐本地上传 静态资源映射的方案文件保存到服务器磁盘指定目录比如/upload/product/2025/xx.jpg后端配置虚拟路径映射把/files/**映射到磁盘目录数据库里只存相对路径字符串不存全URLNginx或者Spring Boot直接对外暴露。这样不花一分钱也能实现完整的上传预览功能。给OSS留好接口比如定义一个StorageService接口答辩时可以说“生产环境可以替换为OSS实现”。2.4 前端与接口对接形态这里要看你的侧重点。如果时间紧张用Thymeleaf做服务端渲染也能跑通全流程但现在的毕设普遍要求“前后端分离”我用的是Vue 3 Element Plus Axios通过接口文档Swagger/knife4j与后端对接。前后端分离有个坑跨域配置CORS。我在后端写了一个WebMvcConfigurer配置类放行本地前端的跨域请求。另外因为使用了JWT前端要在请求拦截器里带上Authorization头。这两个细节最容易让联调阶段卡壳。技术选型汇总表模块技术选型选型理由后端框架Spring Boot 2.7.x生态成熟、上手快、部署简单ORMMyBatis Plus 3.5.x单表CRUD零SQL复杂查询可手写XML数据库MySQL 8.x主流稳定事务、索引成熟缓存Redis 5.x / 6.x热点缓存 库存预扣认证JWT 拦截器无状态、前后端分离友好前端Vue 3 Element Plus组件丰富适合管理后台快速搭建文件存储本地磁盘映射不依赖云资源成本为零接口文档knife4j自动生成接口文档方便自测与答辩演示3. 数据库设计双模式电商的表结构怎么落地3.1 用户与商品域从ER图到建表语句我画ER图的时候习惯按“域”拆用户域、商品域、交易域、营销域助农活动。核心业务表我是这样设计的。用户表user - id BIGINT PK - username VARCHAR(50) UNIQUE - password VARCHAR(100) -- BCrypt加密 - phone VARCHAR(20) - role TINYINT -- 1农户 2买家 3管理员 - status TINYINT -- 启用/禁用 - create_time DATETIME商品表product - id BIGINT PK - category_id BIGINT - seller_id BIGINT - product_name VARCHAR(100) - main_image VARCHAR(255) - detail_html LONGTEXT - unit VARCHAR(10) -- 单位斤/件/箱 - status TINYINT -- 0下架 1上架 2待审核 - create_time DATETIME商品SKU表这是跟普通教学项目的最大区别。农产品大都有规格5斤装/10斤装、一级果/二级果所以价格和库存必须挂在SKU上而不是挂在商品上sku - id BIGINT PK - product_id BIGINT - sku_name VARCHAR(100) -- 规格名如“特级苹果 10斤装” - stock INT - retail_price DECIMAL(10,2) -- 零售单价 - sales_count INT -- 销量累计 - version INT -- 乐观锁版本号批发阶梯价格单独建表因为一个SKU可以配置多档批发价price_rule - id BIGINT PK - sku_id BIGINT - min_quantity INT -- 最低购买量 - max_quantity INT -- 最高购买量NULL表示不设上限 - wholesale_price DECIMAL(10,2) -- 该区间批发单价3.2 订单域订单拆分是双模式系统设计的核心难点订单我设计了主表和明细表。这里有个很多同学想不明白的问题一个购物车里有A农户的苹果和B农户的土豆怎么下单零售场景可以“一单到底”管他卖家是谁。但批发场景不行——不同农户的发货地、物流规则、供货能力都不同。我的方案是按卖家拆单。用户提交购物车结算请求时后端把购物车条目按sellerId分组每个卖家生成一个独立订单。这种设计既贴近真实电商参考京东的多店铺订单又能在答辩时当亮点讲“我通过订单拆分保证了每一笔订单的归属清晰方便后续按店铺统计和对账”。订单主表orders - id BIGINT PK - order_no VARCHAR(32) UNIQUE - user_id BIGINT - seller_id BIGINT - order_type TINYINT -- 1批发 2零售 - total_amount DECIMAL(10,2) -- 商品总额 - freight_amount DECIMAL(10,2) -- 运费/物流费 - pay_amount DECIMAL(10,2) -- 应付金额 - status TINYINT -- 订单状态见状态机 - pay_status TINYINT -- 0未支付 1已支付 2退款 - remark VARCHAR(255) - create_time DATETIME - pay_time DATETIME订单明细表order_item - id BIGINT PK - order_id BIGINT - sku_id BIGINT - product_name VARCHAR(100) -- 冗余快照 - sku_name VARCHAR(100) -- 下单时规格名称 - product_image VARCHAR(255) -- 冗余快照 - quantity INT - unit_price DECIMAL(10,2) -- 成交单价 - total_price DECIMAL(10,2)为什么明细表里要冗余商品名、SKU名、图片因为商品信息会变但订单属于历史数据必须保留下单时的快照。答辩时主动说出这个设计理由老师会认为你有真实业务经验。3.3 关键技术设计价格引擎与订单号生成有了price_rule表批发价格的计算逻辑就清晰了。比如某个SKU配置了三档价格数量区间单价10 ~ 993.00元/斤100 ~ 4992.60元/斤≥ 5002.20元/斤下单时拿到购买量第一步判断是否满足最低起批量第二步循环price_rule找到数量落在哪个区间然后按该区间单价计算金额。这里要特别注意不能用零售价总额乘折扣的思路因为每档的单价是独立配置的不是等比折扣。订单号生成也是容易被忽略的细节。直接用时间戳随机数做订单号虽然能跑但并发生成时可能重复。我用了“时间戳 用户ID后四位 随机数”的组合同时给order_no加了唯一索引万一重复直接报错重试。生产级做法是用雪花算法但在毕设阶段这个自研方案更容易解释。3.4 数据库索引从“能跑”到“跑得快”建表时顺手把索引加上属于答辩加分项。orders(user_id, create_time)—— 支持“我的订单”按时间倒序查询orders(seller_id, create_time)—— 支持农户端订单管理order_item(order_id)—— 订单详情连表查询sku(product_id)—— 商品详情页查SKU列表price_rule(sku_id)—— 批发价查询。索引不是越多越好过多个会拖慢写入。我把product_name这类字段做普通索引就够了不加全文索引。动量词检索在毕设里用LIKE %关键字%数据量不大的情况下完全够用。4. 核心代码实现商品价格阶梯、订单拆分与防超卖库存4.1 分层目录结构先搭好要能撑住答辩的工程骨架拿到一个需求第一步是建工程目录。我用的是经典三层架构 一个额外扩展包com.yangyang.agri ├── controller -- 接口层 ├── service -- 业务逻辑层 │ ├── impl ├── mapper -- 数据访问层 ├── entity -- 数据库实体 ├── dto -- 入参出参DTO ├── common -- 统一返回体、异常、常量 ├── config -- 配置类跨域、静态映射、JWT等 ├── utils -- 工具类 └── annotation -- 自定义注解如RequireLogin分层是为了让答辩老师一眼看出你懂“高内聚低耦合”。我见过不少学生把所有逻辑堆在Controller里虽然功能也实现了但答辩时被老师说“这个代码没有工程化思维”分扣得冤枉。4.2 批发价计算核心代码这是整个系统含金量最高的Service方法之一我直接给出可运行的简化版。/** * 根据SKU和购买数量计算批发单价 * param skuId SKU主键 * param quantity 购买数量 * return 区间单价 */ public BigDecimal calculateWholesalePrice(Long skuId, int quantity) { // 1. 校验最低起批量 PriceRule minRule priceRuleMapper.selectMinRule(skuId); if (minRule ! null quantity minRule.getMinQuantity()) { throw new BizException(未达到起批量最低购买数量为 minRule.getMinQuantity()); } // 2. 查询满足条件的价格区间按min_quantity倒序取最近的一条 LambdaQueryWrapperPriceRule wrapper new LambdaQueryWrapper(); wrapper.eq(PriceRule::getSkuId, skuId) .le(PriceRule::getMinQuantity, quantity) .orderByDesc(PriceRule::getMinQuantity) .last(LIMIT 1); PriceRule rule priceRuleMapper.selectOne(wrapper); if (rule null) { throw new BizException(未找到适用的批发价格规则); } return rule.getWholesalePrice(); }le(minQuantity, quantity)和orderByDesc LIMIT 1的组合作用是找到“购买数量不低于其起批量的最高一档规则”。这句话我在答辩前让学生反复练习说清楚。4.3 订单拆分与事务控制提交订单的逻辑我封装在OrderService.createOrders(ListCartItemDTO cartItems, Long userId)里。核心步骤查询购物车条目联表拿到每个SKU的卖家IDgroupingBy(sellerId)分组每一组构建一个Order主表 若干OrderItem明细批次插入订单明细扣减库存清空对应购物车条目用Transactional包裹整个方法保证一条失败全部回滚。Transactional(rollbackFor Exception.class) public ListLong createOrders(ListCartItemDTO cartItems, Long userId) { MapLong, ListCartItemDTO groupBySeller cartItems.stream() .collect(Collectors.groupingBy(CartItemDTO::getSellerId)); ListLong orderIdList new ArrayList(); for (Map.EntryLong, ListCartItemDTO entry : groupBySeller.entrySet()) { Long sellerId entry.getKey(); ListCartItemDTO items entry.getValue(); // 1. 构造主订单 Order order buildMainOrder(userId, sellerId, items); orderMapper.insert(order); // 2. 构造明细并计算金额 for (CartItemDTO item : items) { OrderItem orderItem buildOrderItem(order.getId(), item); orderItemMapper.insert(orderItem); // 3. 扣减库存乐观锁 deductStock(item.getSkuId(), item.getQuantity()); } // 4. 删除已加购条目 cartItemMapper.deleteBatchIds(items.stream().map(CartItemDTO::getId).collect(Collectors.toList())); orderIdList.add(order.getId()); } return orderIdList; }这里的一个细节是buildMainOrder时会判断订单类型。判断依据是购物车条目里是否包含“批发模式勾选”。前端在购物车结算页提供“按批发价结算”的开关后端把每个条目的orderType字段一并传上来。如果同一组商品既有批发条目又有零售条目做法是拆得更细同类目再按模式拆单但正常业务中很少会出现我会在接口层做拦截提示“请统一选择购买模式”。4.4 防超卖库存扣减乐观锁在MySQL里的正确写法库存扣减是我最不放心学生写错的地方。很多人的第一版代码是Sku sku skuMapper.selectById(skuId); if (sku.getStock() quantity) { throw new BizException(库存不足); } sku.setStock(sku.getStock() - quantity); skuMapper.updateById(sku);这段代码用单线程测试没问题但并发下必然超卖——两个请求同时读到剩余库存10都判断足够都扣成5实际超卖了5件。正确的实现是把判断和扣减合并成一条SQL利用行锁保证原子性int rows skuMapper.deductStock(skuId, quantity); if (rows 0) { throw new BizException(库存不足); }对应的Mapper方法Update(UPDATE sku SET stock stock - #{quantity}, version version 1, sales_count sales_count #{quantity} WHERE id #{skuId} AND stock #{quantity}) int deductStock(Param(skuId) Long skuId, Param(quantity) Integer quantity);stock #{quantity}这个条件天然实现了“剩余库存不足时更新行数为0程序抛出异常回滚整个事务”的效果。这是防超卖的第一道防线。如果想再上强度可以配合Redis预扣库存Long remain redis.opsForValue().decrement(stock:sku: skuId, quantity); if (remain 0) { // 回补抛异常 redis.opsForValue().increment(stock:sku: skuId, quantity); throw new BizException(库存不足); }Redis预扣解决的是“同一秒内大量请求打进来”的问题数据库乐观锁解决的是“最终一致性”的问题。两者配合使用是电商秒杀场景的通用方案也是答辩时最有含金量的技术展示点。4.5 统一返回体与全局异常接口必须统一返回格式。我定义了一个ResultT{ code: 200, message: success, data: { } }配合RestControllerAdvice做全局异常处理业务异常返回400未知异常返回500。这样前端只需在Axios响应拦截器里判断code即可。这个设计能让联调效率高很多也更符合“工程化”要求。5. 登录认证与接口安全JWT 拦截器的轻量实现5.1 为什么不用Spring Security直说结论Spring Security本身不复杂权限模型也合适但它的配置和过滤器链对毕设阶段的同学来说黑盒感太强。一旦答辩老师问“Spring Security的过滤器链有几层”答不上来反而扣分。相比之下JWT 拦截器的实现逻辑是透明的前端调登录接口获得token之后每次请求在Header里带上token后端拦截器解析token并校验用户身份。我理解毕设项目的核心目标是体现你对编程逻辑的掌握所以选择“自己能完全讲清楚的轻量方案”比“用大而全的框架”更聪明。5.2 自定义注解 拦截器的完整实现先定义一个注解Target({ElementType.METHOD, ElementType.TYPE}) Retention(RetentionPolicy.RUNTIME) public interface RequireLogin { String role() default ; // 可选指定需要的角色 }再写拦截器public class LoginInterceptor implements HandlerInterceptor { Autowired private StringRedisTemplate redisTemplate; Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (!(handler instanceof HandlerMethod)) { return true; } // 放行不需要登录的接口 RequireLogin requireLogin ((HandlerMethod) handler).getMethodAnnotation(RequireLogin.class); if (requireLogin null) { return true; } String token request.getHeader(Authorization); if (StringUtils.isBlank(token)) { throw new BizException(未登录); } // 解析token同时校验Redis中是否存在该token实现注销操作 Claims claims JwtUtil.parseToken(token); Long userId claims.get(userId, Long.class); // 将用户信息存入请求上下文 UserContext.set(userId); return true; } Override public void afterCompletion(...) { UserContext.clear(); } }这里有一个我在实际带项目时反复强调的点token里不要放敏感信息比如密码、手机号。token只放userId和用户昵称。需要用户其他信息时再从数据库查询。还有为了支持“用户注销”我在Redis里存储了token黑名单或者存“活跃token”白名单注销时删除Redis记录拦截器在解析token后再查一次Redis是否存在。这个设计讲给答辩老师听又是一个加分项。5.3 接口权限的三层校验完整的接口安全做了三层注册登录时给密码加盐BCrypt接口层通过RequireLogin(role seller)限定农户才能操作数据行级权限在Service层控制——比如农户只能查询seller_id 当前登录用户ID的订单。第三点很容易忽略。我曾经见过一个学生做的系统农户A登录后直接改URL里的订单ID竟然看到了农户B的订单。原因就是查询接口只做了“登录校验”没做“归属校验”。正确的写法示例public PageResultOrderVO querySellerOrders(Long page, Long size, Long currentUserId) { LambdaQueryWrapperOrder wrapper new LambdaQueryWrapper(); wrapper.eq(Order::getSellerId, currentUserId) // 强制带上归属条件 .orderByDesc(Order::getCreateTime); // ... }这条经验非常值钱希望所有做有“多角色数据隔离”需求毕设的同学都记住。6. 实测高频踩坑记录从环境配置到接口联调6.1 MyBatis Plus字段映射与LocalDateTime的微妙问题第一个坑Java实体类用驼峰命名createTime数据库字段用下划线create_timeMyBatis Plus默认开启驼峰映射理论上没问题。但如果你在XML里手写SQL容易忘记加as createTime返回结果里字段就为null。我建议复杂的查询统一用DTO接收并在XML中显式写AS createTime。第二个坑MySQL 8.x的datetime类型对应Java的LocalDateTime用MyBatis Plus没毛病。但如果你用了java.util.Date查询结果的时间会少8小时。解决方案就是用LocalDateTime同时数据库连接串加上serverTimezoneAsia/Shanghai。6.2 金额计算一口把double毙掉系统中所有涉及金额的字段Java侧一律用BigDecimal数据库一律用DECIMAL(10,2)。前端传金额时用分还是元要约定一致——我习惯前端传元字符串后端用new BigDecimal(value)禁止用valueOf(double)因为BigDecimal.valueOf(0.1)和new BigDecimal(0.1)的结果完全不同。这属于细节中的细节但金额错误在毕设演示时被老师看到基本会被质疑系统严谨性。6.3 图片上传后预览404静态资源映射路径的坑我用的是本地磁盘存储配置了/files/**映射到D:/upload/。有一段时间前端上传后预览总是404排查半天发现是路径拼接问题——数据库存的是/files/product/1.jpg而前端请求直接拼成了/api/files/product/1.jpg多了一个/api前缀被网关层拦了。解决办法是前后端约定上传接口返回的URL就是完整的可访问路径前端不回拼。另一个更常见的坑本地开发用的磁盘路径写死成D:/部署到Linux服务器后路径不存在。我改成了从配置文件读取file: upload-dir: ${UPLOAD_DIR:./upload}默认相对路径启动服务器上挂/data/upload时设置环境变量即可。6.4 跨域配置与Axios拦截器的联动为了避免联调时反复出跨域问题后端配置类里一次性处理好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); } }前端Axios拦截器挂载tokenservice.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization token } return config })这两个配置配合起来前后端联调基本不会出现“登录成功后调接口还是401”的情况。如果你用的是knife4j测试接口记得也要在Swagger配置里加上Authorization的全局Header定义不然在文档里没法带token调试。7. 毕设演示与答辩准备的实操经验7.1 演示数据准备让系统看起来“活”的细节很多同学做完系统数据库里全是“测试商品1”“测试商品2”演示效果大打折扣。我自己的想法是花一个下午把数据造得像真实场景。比如农户店铺名叫“高山有机蔬菜基地”“王家岭猕猴桃合作社”而不是“用户001”商品类目建好新鲜蔬菜、时令水果、粮油副食、禽蛋肉类每个商品配上3~5张真实的网络图片注意版权可以去免费图库批发阶梯价格配置2~3档覆盖不同起批量造几笔历史订单让“我的订单”、“店铺销量统计”页面有数据。答辩当天老师点开商品详情页看到完整的信息图片、视频、阶梯价感官分立刻不一样。7.2 答辩高频问题清单带过几届学生我总结出老师最可能问的六个问题每一个都要准备一个“可以讲30秒以上”的答案“你的系统并发量能支持多少”—— 不要吹“支持百万并发”。诚实说“本系统通过Redis预扣库存和乐观锁防止超卖在单机事务下能准确支持数百并发”然后讲清楚防超卖原理。“为什么订单表要冗余商品名称和图片”—— 快照设计保留下单时刻的商品信息防止商品改名后历史账单对不上。“批发价格和零售价格是怎么区分的”—— 讲price_rule阶梯表 calculateWholesalePrice方法的完整逻辑。“数据库为什么这样建立索引”—— 结合“我的订单”查询场景讲联合索引和覆盖索引的思路。“Token过期了怎么办分布式环境下JWT怎么处理”—— 讲双tokenaccess token refresh token机制并说明本次系统实现了access token Redis校验refresh token是后续扩展点。“系统上线之后最可能出现的问题是什么”—— 可以答“图片存储单机磁盘容量有限、订单量上涨后单库压力大”然后引出分库分表和对象存储的演进方案。7.3 最后一个小技巧准备一份“技术亮点说明书”我建议每个做毕设的同学在答辩前写一篇两千字左右的《系统技术亮点与设计决策说明》内容包括核心业务的难点双模式价格、订单拆分与你的解决方案你主动做的非功能设计防超卖、统一返回、全局异常、行级权限你在项目中踩过的最大的坑以及如何排查的。这份文档不是交给老师的而是你自己复盘的。写完之后你一定会发现很多代码写的时候稀里糊涂一旦用文字表达出来逻辑漏洞就暴露了。把漏洞堵上答辩的底气自然就有了。这几年我陆续带过的助农电商项目里有的是仓库管理系统有的是溯源系统有的是纯B2C商城但“批发零售”这套双模式方案始终是最有嚼头的一个。如果你正在做类似题目我的建议是不要急着写代码先拿一张纸把订单拆分、价格阶梯、库存扣减这三条线画清楚。这三条线顺了你的项目就成功了一大半。画完之后再回头看这篇文章遇到的每个坑应该都能找到对应的答案。 Java助农电商平台：批发零售双模式交易系统设计与实现
每年下半年的毕业设计咨询季我接到最多的题目之一就是“助农电商平台”。很多同学找我时手里只有一句话做一个Java的农产品批发与零售系统。但等真正开始动手才发现“批发”和“零售”根本不是在一个购物车里加两个价格那么轻松。这篇文章我就以“阳阳助农电商平台”为例把整个项目的设计思路、技术选型、数据库建模、核心代码实现和踩坑经历完整讲一遍。内容包括完整的实现方案、关键代码片段、SQL脚本和答辩经验适合正在做Java毕设的同学参考也适合想快速搭建一套农产品双模式交易系统的开发者。我尽量把每一步的“为什么这么做”也讲清楚毕竟毕设答辩时老师最爱问的就是“你为什么这样设计”。前几年我习惯一上来就教大家搭环境、写CRUD后来发现那样做出来的系统根本经不起答辩提问。现在带项目我都会让学生先把业务模型想清楚因为助农电商和普通电商最大的区别在于交易模式的复杂程度——一套系统里同时跑着B2B批发和B2C零售两套逻辑这是整个系统所有设计的源头。下面我把完整过程展开讲。1. 业务模型拆解批发与零售两条交易线如何共处一室1.1 从“批发零售”双模式说起助农电商平台的核心场景是农民/合作社在平台上发布农产品买家可以按斤/按件少量购买零售也可以一次性大批量采购批发。这两种模式看着都是“下单付款”但对系统的要求差别巨大。零售购物车是典型的电商逻辑用户选几个商品按固定单价结算包邮或按重量计运费。而批发订单有几个零售里根本没有的规则起批量比如大蒜低于50斤不卖阶梯价格买100~499斤是2.5元/斤买500斤以上是2元/斤按重量/件数走大宗物流运费单独协商不走快递模板定金/尾款部分批发场景下甚至会有先付定金、尾款待称重后结算的需求第一期我通常不让学生做但答辩可以说这是后续扩展点。所以从一开始就要想清楚不是做一个两边都能用的购物车而是要做一个“模式感知”的系统同一件商品在不同模式下表现不同。商品详情页要显示“零售价”和“批发价区间”购物车结算时要识别当前订单走哪一套价格引擎。这是整个业务建模的第一块基石。1.2 平台角色与权限边界我设计的角色是三种农户卖家、买家采购商/普通消费者、平台管理员。很多同学会把“买家”细分成“批发商”和“普通用户”两个角色其实没必要。因为一个采购蒜头的老板也可以顺手在平台给自己家里买两斤水果同一个账号既走批发订单也走零售订单才是正常状态。角色按“功能权限”划分而不是按“用户类型”划分。农户端店铺管理、商品发布/编辑/上下架、价格规则设置、订单发货、库存管理、销售统计买家端商品浏览、购物车、下单、支付演示阶段通常模拟、订单查看、收货确认管理后台用户管理、类目审核、商品审核助农平台建议保留审核环节、数据看板。权限控制层面我没有上Spring Security那一套重量级框架而是用JWT 拦截器 自定义注解实现。原因很简单毕设项目里Spring Security配置繁琐而且答辩时很难三言两语讲清楚它的过滤器链原理而JWT拦截器是学生自己能一行一行讲明白的。下面会给出具体代码。1.3 非功能性需求老师眼里“真实系统”的标准功能做完只是及格想拿高分要在答辩时体现出你考虑过“真实系统才会遇到的问题”。我自己带学生时固定检查这几个点数据一致性库存扣减是否防超卖订单金额计算是否有精度问题并发能力秒杀场景下助农平台有时会做限时特价Redis预扣库存是否扛得住安全性密码是否加密存储接口是否校验登录状态可用性图片传哪里404、异常统一返回吗可维护性目录结构是否分层清晰代码注释是否合格这些点看着不起眼但我在答辩现场见过太多学生被“你这个系统并发100个人买同一个商品库存会不会变负数”一句话问住。所以本文后面的章节会围绕这些“非功能点”逐个展开。2. 技术选型为什么锁定了Spring Boot MyBatis Plus Redis这套组合2.1 后端框架生态成熟是第一选型标准当前做Java毕设Spring Boot基本是唯一解——你自己写SSH或者Servlet既要处理大量模板配置又显得和主流技术栈脱节。我用的是Spring Boot 2.7.x不要用3.x3.x要求JDK17很多同学的机器环境还在JDK8折腾环境就得浪费一下午。持久层选择MyBatis Plus而不是原生MyBatis核心原因是它能省掉80%的单表CRUD代码。BaseMapperT直接提供了selectById、insert、updateById等常用方法复杂多表查询再手写XML。但有一点必须提醒用了MP也要会写SQL。答辩时老师一定会抽查某个查询的实现如果支支吾吾地说“MP自动生成的”印象分会很差。我通常要求学生至少能当场写出一条多表JOIN GROUP BY的SQL。2.2 缓存与高并发组件Redis承担了什么职责Redis在这个系统里承担三件事热点商品缓存、购物车临时数据可选、库存预扣计数。为什么要缓存农产品详情页访问量往往集中在几个爆款上每次都查MySQL会把数据库打满。我用Redis缓存商品详情key设计为product:detail:{id}过期时间30分钟后台修改商品时主动删除缓存。库存预扣的逻辑更关键后面专门开一节讲。有些同学会把用户的购物车也塞进Redis我建议第一次做不要这样。购物车老老实实建一张cart_item表存MySQL虽然多写几个接口但数据可解释性强答辩时画ER图也方便。Redis只承担“缓存”和“计数”这类强调性能的角色。2.3 文件存储不依赖云服务的本地方案农产品需要大量图片果实实拍、产地环境文件上传是必做功能。很多教程直接让配置阿里云OSS但学生自己没有云资源答辩环境也可能断网。我更推荐本地上传 静态资源映射的方案文件保存到服务器磁盘指定目录比如/upload/product/2025/xx.jpg后端配置虚拟路径映射把/files/**映射到磁盘目录数据库里只存相对路径字符串不存全URLNginx或者Spring Boot直接对外暴露。这样不花一分钱也能实现完整的上传预览功能。给OSS留好接口比如定义一个StorageService接口答辩时可以说“生产环境可以替换为OSS实现”。2.4 前端与接口对接形态这里要看你的侧重点。如果时间紧张用Thymeleaf做服务端渲染也能跑通全流程但现在的毕设普遍要求“前后端分离”我用的是Vue 3 Element Plus Axios通过接口文档Swagger/knife4j与后端对接。前后端分离有个坑跨域配置CORS。我在后端写了一个WebMvcConfigurer配置类放行本地前端的跨域请求。另外因为使用了JWT前端要在请求拦截器里带上Authorization头。这两个细节最容易让联调阶段卡壳。技术选型汇总表模块技术选型选型理由后端框架Spring Boot 2.7.x生态成熟、上手快、部署简单ORMMyBatis Plus 3.5.x单表CRUD零SQL复杂查询可手写XML数据库MySQL 8.x主流稳定事务、索引成熟缓存Redis 5.x / 6.x热点缓存 库存预扣认证JWT 拦截器无状态、前后端分离友好前端Vue 3 Element Plus组件丰富适合管理后台快速搭建文件存储本地磁盘映射不依赖云资源成本为零接口文档knife4j自动生成接口文档方便自测与答辩演示3. 数据库设计双模式电商的表结构怎么落地3.1 用户与商品域从ER图到建表语句我画ER图的时候习惯按“域”拆用户域、商品域、交易域、营销域助农活动。核心业务表我是这样设计的。用户表user - id BIGINT PK - username VARCHAR(50) UNIQUE - password VARCHAR(100) -- BCrypt加密 - phone VARCHAR(20) - role TINYINT -- 1农户 2买家 3管理员 - status TINYINT -- 启用/禁用 - create_time DATETIME商品表product - id BIGINT PK - category_id BIGINT - seller_id BIGINT - product_name VARCHAR(100) - main_image VARCHAR(255) - detail_html LONGTEXT - unit VARCHAR(10) -- 单位斤/件/箱 - status TINYINT -- 0下架 1上架 2待审核 - create_time DATETIME商品SKU表这是跟普通教学项目的最大区别。农产品大都有规格5斤装/10斤装、一级果/二级果所以价格和库存必须挂在SKU上而不是挂在商品上sku - id BIGINT PK - product_id BIGINT - sku_name VARCHAR(100) -- 规格名如“特级苹果 10斤装” - stock INT - retail_price DECIMAL(10,2) -- 零售单价 - sales_count INT -- 销量累计 - version INT -- 乐观锁版本号批发阶梯价格单独建表因为一个SKU可以配置多档批发价price_rule - id BIGINT PK - sku_id BIGINT - min_quantity INT -- 最低购买量 - max_quantity INT -- 最高购买量NULL表示不设上限 - wholesale_price DECIMAL(10,2) -- 该区间批发单价3.2 订单域订单拆分是双模式系统设计的核心难点订单我设计了主表和明细表。这里有个很多同学想不明白的问题一个购物车里有A农户的苹果和B农户的土豆怎么下单零售场景可以“一单到底”管他卖家是谁。但批发场景不行——不同农户的发货地、物流规则、供货能力都不同。我的方案是按卖家拆单。用户提交购物车结算请求时后端把购物车条目按sellerId分组每个卖家生成一个独立订单。这种设计既贴近真实电商参考京东的多店铺订单又能在答辩时当亮点讲“我通过订单拆分保证了每一笔订单的归属清晰方便后续按店铺统计和对账”。订单主表orders - id BIGINT PK - order_no VARCHAR(32) UNIQUE - user_id BIGINT - seller_id BIGINT - order_type TINYINT -- 1批发 2零售 - total_amount DECIMAL(10,2) -- 商品总额 - freight_amount DECIMAL(10,2) -- 运费/物流费 - pay_amount DECIMAL(10,2) -- 应付金额 - status TINYINT -- 订单状态见状态机 - pay_status TINYINT -- 0未支付 1已支付 2退款 - remark VARCHAR(255) - create_time DATETIME - pay_time DATETIME订单明细表order_item - id BIGINT PK - order_id BIGINT - sku_id BIGINT - product_name VARCHAR(100) -- 冗余快照 - sku_name VARCHAR(100) -- 下单时规格名称 - product_image VARCHAR(255) -- 冗余快照 - quantity INT - unit_price DECIMAL(10,2) -- 成交单价 - total_price DECIMAL(10,2)为什么明细表里要冗余商品名、SKU名、图片因为商品信息会变但订单属于历史数据必须保留下单时的快照。答辩时主动说出这个设计理由老师会认为你有真实业务经验。3.3 关键技术设计价格引擎与订单号生成有了price_rule表批发价格的计算逻辑就清晰了。比如某个SKU配置了三档价格数量区间单价10 ~ 993.00元/斤100 ~ 4992.60元/斤≥ 5002.20元/斤下单时拿到购买量第一步判断是否满足最低起批量第二步循环price_rule找到数量落在哪个区间然后按该区间单价计算金额。这里要特别注意不能用零售价总额乘折扣的思路因为每档的单价是独立配置的不是等比折扣。订单号生成也是容易被忽略的细节。直接用时间戳随机数做订单号虽然能跑但并发生成时可能重复。我用了“时间戳 用户ID后四位 随机数”的组合同时给order_no加了唯一索引万一重复直接报错重试。生产级做法是用雪花算法但在毕设阶段这个自研方案更容易解释。3.4 数据库索引从“能跑”到“跑得快”建表时顺手把索引加上属于答辩加分项。orders(user_id, create_time)—— 支持“我的订单”按时间倒序查询orders(seller_id, create_time)—— 支持农户端订单管理order_item(order_id)—— 订单详情连表查询sku(product_id)—— 商品详情页查SKU列表price_rule(sku_id)—— 批发价查询。索引不是越多越好过多个会拖慢写入。我把product_name这类字段做普通索引就够了不加全文索引。动量词检索在毕设里用LIKE %关键字%数据量不大的情况下完全够用。4. 核心代码实现商品价格阶梯、订单拆分与防超卖库存4.1 分层目录结构先搭好要能撑住答辩的工程骨架拿到一个需求第一步是建工程目录。我用的是经典三层架构 一个额外扩展包com.yangyang.agri ├── controller -- 接口层 ├── service -- 业务逻辑层 │ ├── impl ├── mapper -- 数据访问层 ├── entity -- 数据库实体 ├── dto -- 入参出参DTO ├── common -- 统一返回体、异常、常量 ├── config -- 配置类跨域、静态映射、JWT等 ├── utils -- 工具类 └── annotation -- 自定义注解如RequireLogin分层是为了让答辩老师一眼看出你懂“高内聚低耦合”。我见过不少学生把所有逻辑堆在Controller里虽然功能也实现了但答辩时被老师说“这个代码没有工程化思维”分扣得冤枉。4.2 批发价计算核心代码这是整个系统含金量最高的Service方法之一我直接给出可运行的简化版。/** * 根据SKU和购买数量计算批发单价 * param skuId SKU主键 * param quantity 购买数量 * return 区间单价 */ public BigDecimal calculateWholesalePrice(Long skuId, int quantity) { // 1. 校验最低起批量 PriceRule minRule priceRuleMapper.selectMinRule(skuId); if (minRule ! null quantity minRule.getMinQuantity()) { throw new BizException(未达到起批量最低购买数量为 minRule.getMinQuantity()); } // 2. 查询满足条件的价格区间按min_quantity倒序取最近的一条 LambdaQueryWrapperPriceRule wrapper new LambdaQueryWrapper(); wrapper.eq(PriceRule::getSkuId, skuId) .le(PriceRule::getMinQuantity, quantity) .orderByDesc(PriceRule::getMinQuantity) .last(LIMIT 1); PriceRule rule priceRuleMapper.selectOne(wrapper); if (rule null) { throw new BizException(未找到适用的批发价格规则); } return rule.getWholesalePrice(); }le(minQuantity, quantity)和orderByDesc LIMIT 1的组合作用是找到“购买数量不低于其起批量的最高一档规则”。这句话我在答辩前让学生反复练习说清楚。4.3 订单拆分与事务控制提交订单的逻辑我封装在OrderService.createOrders(ListCartItemDTO cartItems, Long userId)里。核心步骤查询购物车条目联表拿到每个SKU的卖家IDgroupingBy(sellerId)分组每一组构建一个Order主表 若干OrderItem明细批次插入订单明细扣减库存清空对应购物车条目用Transactional包裹整个方法保证一条失败全部回滚。Transactional(rollbackFor Exception.class) public ListLong createOrders(ListCartItemDTO cartItems, Long userId) { MapLong, ListCartItemDTO groupBySeller cartItems.stream() .collect(Collectors.groupingBy(CartItemDTO::getSellerId)); ListLong orderIdList new ArrayList(); for (Map.EntryLong, ListCartItemDTO entry : groupBySeller.entrySet()) { Long sellerId entry.getKey(); ListCartItemDTO items entry.getValue(); // 1. 构造主订单 Order order buildMainOrder(userId, sellerId, items); orderMapper.insert(order); // 2. 构造明细并计算金额 for (CartItemDTO item : items) { OrderItem orderItem buildOrderItem(order.getId(), item); orderItemMapper.insert(orderItem); // 3. 扣减库存乐观锁 deductStock(item.getSkuId(), item.getQuantity()); } // 4. 删除已加购条目 cartItemMapper.deleteBatchIds(items.stream().map(CartItemDTO::getId).collect(Collectors.toList())); orderIdList.add(order.getId()); } return orderIdList; }这里的一个细节是buildMainOrder时会判断订单类型。判断依据是购物车条目里是否包含“批发模式勾选”。前端在购物车结算页提供“按批发价结算”的开关后端把每个条目的orderType字段一并传上来。如果同一组商品既有批发条目又有零售条目做法是拆得更细同类目再按模式拆单但正常业务中很少会出现我会在接口层做拦截提示“请统一选择购买模式”。4.4 防超卖库存扣减乐观锁在MySQL里的正确写法库存扣减是我最不放心学生写错的地方。很多人的第一版代码是Sku sku skuMapper.selectById(skuId); if (sku.getStock() quantity) { throw new BizException(库存不足); } sku.setStock(sku.getStock() - quantity); skuMapper.updateById(sku);这段代码用单线程测试没问题但并发下必然超卖——两个请求同时读到剩余库存10都判断足够都扣成5实际超卖了5件。正确的实现是把判断和扣减合并成一条SQL利用行锁保证原子性int rows skuMapper.deductStock(skuId, quantity); if (rows 0) { throw new BizException(库存不足); }对应的Mapper方法Update(UPDATE sku SET stock stock - #{quantity}, version version 1, sales_count sales_count #{quantity} WHERE id #{skuId} AND stock #{quantity}) int deductStock(Param(skuId) Long skuId, Param(quantity) Integer quantity);stock #{quantity}这个条件天然实现了“剩余库存不足时更新行数为0程序抛出异常回滚整个事务”的效果。这是防超卖的第一道防线。如果想再上强度可以配合Redis预扣库存Long remain redis.opsForValue().decrement(stock:sku: skuId, quantity); if (remain 0) { // 回补抛异常 redis.opsForValue().increment(stock:sku: skuId, quantity); throw new BizException(库存不足); }Redis预扣解决的是“同一秒内大量请求打进来”的问题数据库乐观锁解决的是“最终一致性”的问题。两者配合使用是电商秒杀场景的通用方案也是答辩时最有含金量的技术展示点。4.5 统一返回体与全局异常接口必须统一返回格式。我定义了一个ResultT{ code: 200, message: success, data: { } }配合RestControllerAdvice做全局异常处理业务异常返回400未知异常返回500。这样前端只需在Axios响应拦截器里判断code即可。这个设计能让联调效率高很多也更符合“工程化”要求。5. 登录认证与接口安全JWT 拦截器的轻量实现5.1 为什么不用Spring Security直说结论Spring Security本身不复杂权限模型也合适但它的配置和过滤器链对毕设阶段的同学来说黑盒感太强。一旦答辩老师问“Spring Security的过滤器链有几层”答不上来反而扣分。相比之下JWT 拦截器的实现逻辑是透明的前端调登录接口获得token之后每次请求在Header里带上token后端拦截器解析token并校验用户身份。我理解毕设项目的核心目标是体现你对编程逻辑的掌握所以选择“自己能完全讲清楚的轻量方案”比“用大而全的框架”更聪明。5.2 自定义注解 拦截器的完整实现先定义一个注解Target({ElementType.METHOD, ElementType.TYPE}) Retention(RetentionPolicy.RUNTIME) public interface RequireLogin { String role() default ; // 可选指定需要的角色 }再写拦截器public class LoginInterceptor implements HandlerInterceptor { Autowired private StringRedisTemplate redisTemplate; Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (!(handler instanceof HandlerMethod)) { return true; } // 放行不需要登录的接口 RequireLogin requireLogin ((HandlerMethod) handler).getMethodAnnotation(RequireLogin.class); if (requireLogin null) { return true; } String token request.getHeader(Authorization); if (StringUtils.isBlank(token)) { throw new BizException(未登录); } // 解析token同时校验Redis中是否存在该token实现注销操作 Claims claims JwtUtil.parseToken(token); Long userId claims.get(userId, Long.class); // 将用户信息存入请求上下文 UserContext.set(userId); return true; } Override public void afterCompletion(...) { UserContext.clear(); } }这里有一个我在实际带项目时反复强调的点token里不要放敏感信息比如密码、手机号。token只放userId和用户昵称。需要用户其他信息时再从数据库查询。还有为了支持“用户注销”我在Redis里存储了token黑名单或者存“活跃token”白名单注销时删除Redis记录拦截器在解析token后再查一次Redis是否存在。这个设计讲给答辩老师听又是一个加分项。5.3 接口权限的三层校验完整的接口安全做了三层注册登录时给密码加盐BCrypt接口层通过RequireLogin(role seller)限定农户才能操作数据行级权限在Service层控制——比如农户只能查询seller_id 当前登录用户ID的订单。第三点很容易忽略。我曾经见过一个学生做的系统农户A登录后直接改URL里的订单ID竟然看到了农户B的订单。原因就是查询接口只做了“登录校验”没做“归属校验”。正确的写法示例public PageResultOrderVO querySellerOrders(Long page, Long size, Long currentUserId) { LambdaQueryWrapperOrder wrapper new LambdaQueryWrapper(); wrapper.eq(Order::getSellerId, currentUserId) // 强制带上归属条件 .orderByDesc(Order::getCreateTime); // ... }这条经验非常值钱希望所有做有“多角色数据隔离”需求毕设的同学都记住。6. 实测高频踩坑记录从环境配置到接口联调6.1 MyBatis Plus字段映射与LocalDateTime的微妙问题第一个坑Java实体类用驼峰命名createTime数据库字段用下划线create_timeMyBatis Plus默认开启驼峰映射理论上没问题。但如果你在XML里手写SQL容易忘记加as createTime返回结果里字段就为null。我建议复杂的查询统一用DTO接收并在XML中显式写AS createTime。第二个坑MySQL 8.x的datetime类型对应Java的LocalDateTime用MyBatis Plus没毛病。但如果你用了java.util.Date查询结果的时间会少8小时。解决方案就是用LocalDateTime同时数据库连接串加上serverTimezoneAsia/Shanghai。6.2 金额计算一口把double毙掉系统中所有涉及金额的字段Java侧一律用BigDecimal数据库一律用DECIMAL(10,2)。前端传金额时用分还是元要约定一致——我习惯前端传元字符串后端用new BigDecimal(value)禁止用valueOf(double)因为BigDecimal.valueOf(0.1)和new BigDecimal(0.1)的结果完全不同。这属于细节中的细节但金额错误在毕设演示时被老师看到基本会被质疑系统严谨性。6.3 图片上传后预览404静态资源映射路径的坑我用的是本地磁盘存储配置了/files/**映射到D:/upload/。有一段时间前端上传后预览总是404排查半天发现是路径拼接问题——数据库存的是/files/product/1.jpg而前端请求直接拼成了/api/files/product/1.jpg多了一个/api前缀被网关层拦了。解决办法是前后端约定上传接口返回的URL就是完整的可访问路径前端不回拼。另一个更常见的坑本地开发用的磁盘路径写死成D:/部署到Linux服务器后路径不存在。我改成了从配置文件读取file: upload-dir: ${UPLOAD_DIR:./upload}默认相对路径启动服务器上挂/data/upload时设置环境变量即可。6.4 跨域配置与Axios拦截器的联动为了避免联调时反复出跨域问题后端配置类里一次性处理好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); } }前端Axios拦截器挂载tokenservice.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization token } return config })这两个配置配合起来前后端联调基本不会出现“登录成功后调接口还是401”的情况。如果你用的是knife4j测试接口记得也要在Swagger配置里加上Authorization的全局Header定义不然在文档里没法带token调试。7. 毕设演示与答辩准备的实操经验7.1 演示数据准备让系统看起来“活”的细节很多同学做完系统数据库里全是“测试商品1”“测试商品2”演示效果大打折扣。我自己的想法是花一个下午把数据造得像真实场景。比如农户店铺名叫“高山有机蔬菜基地”“王家岭猕猴桃合作社”而不是“用户001”商品类目建好新鲜蔬菜、时令水果、粮油副食、禽蛋肉类每个商品配上3~5张真实的网络图片注意版权可以去免费图库批发阶梯价格配置2~3档覆盖不同起批量造几笔历史订单让“我的订单”、“店铺销量统计”页面有数据。答辩当天老师点开商品详情页看到完整的信息图片、视频、阶梯价感官分立刻不一样。7.2 答辩高频问题清单带过几届学生我总结出老师最可能问的六个问题每一个都要准备一个“可以讲30秒以上”的答案“你的系统并发量能支持多少”—— 不要吹“支持百万并发”。诚实说“本系统通过Redis预扣库存和乐观锁防止超卖在单机事务下能准确支持数百并发”然后讲清楚防超卖原理。“为什么订单表要冗余商品名称和图片”—— 快照设计保留下单时刻的商品信息防止商品改名后历史账单对不上。“批发价格和零售价格是怎么区分的”—— 讲price_rule阶梯表 calculateWholesalePrice方法的完整逻辑。“数据库为什么这样建立索引”—— 结合“我的订单”查询场景讲联合索引和覆盖索引的思路。“Token过期了怎么办分布式环境下JWT怎么处理”—— 讲双tokenaccess token refresh token机制并说明本次系统实现了access token Redis校验refresh token是后续扩展点。“系统上线之后最可能出现的问题是什么”—— 可以答“图片存储单机磁盘容量有限、订单量上涨后单库压力大”然后引出分库分表和对象存储的演进方案。7.3 最后一个小技巧准备一份“技术亮点说明书”我建议每个做毕设的同学在答辩前写一篇两千字左右的《系统技术亮点与设计决策说明》内容包括核心业务的难点双模式价格、订单拆分与你的解决方案你主动做的非功能设计防超卖、统一返回、全局异常、行级权限你在项目中踩过的最大的坑以及如何排查的。这份文档不是交给老师的而是你自己复盘的。写完之后你一定会发现很多代码写的时候稀里糊涂一旦用文字表达出来逻辑漏洞就暴露了。把漏洞堵上答辩的底气自然就有了。这几年我陆续带过的助农电商项目里有的是仓库管理系统有的是溯源系统有的是纯B2C商城但“批发零售”这套双模式方案始终是最有嚼头的一个。如果你正在做类似题目我的建议是不要急着写代码先拿一张纸把订单拆分、价格阶梯、库存扣减这三条线画清楚。这三条线顺了你的项目就成功了一大半。画完之后再回头看这篇文章遇到的每个坑应该都能找到对应的答案。