简介果蔬销售管理系统毕业设计是一套基于Java技术的完整项目源码面向计算机相关专业学生适用于毕业设计、课程设计及课设参考也可作为小型果蔬商店或批发市场信息管理场景的实践范例。系统覆盖果蔬入库、出库、库存管理、销售统计等核心功能采用MVC架构分离业务逻辑、数据处理与用户界面便于理解实际项目中的分层设计。压缩包共858个文件主要包含136个Java源码、51个Vue前端组件、167个JavaScript脚本、55个CSS样式及46个HTML页面同时附带SQL数据库脚本、配置文件和批量启动脚本整体大小为17.42MB目前已有95人学习下载。通过学习该项目可掌握Spring Boot后端开发、MyBatis或JPA数据库操作、前端模板渲染等关键技术并理解从数据库表设计到页面交互的完整链路文件分类清晰、代码结构完整适合需要快速完成毕业设计或系统提升Java Web开发能力的读者参考。1. 果蔬销售管理系统这个毕业设计题目到底在考什么打开那份“果蔬销售管理系统-毕业设计.zip”之前先想清楚一件事这不是一个让你练手 CRUD 的普通管理系统它把“生鲜电商”里最难的三件事——商品多规格、库存易损耗、价格随行就市——全塞进了一个本科毕设的体量里。果蔬销售管理系统的核心不是“卖菜”而是“库存和价格的一致性”上午土豆进价 1.2 元下午批发市场跌到 0.9 元系统里的售价改不改顾客下单 5 斤仓库实际只有 4.2 斤订单是拦下来还是部分发货这些业务细节才是答辩时能让老师眼前一亮的点。市面上这类系统大多长一个样Spring Boot 做后端Vue 做前端MySQL 存数据管理员维护商品和订单用户端做浏览和下单。这个技术栈不该是“随便选的”而是因为果蔬销售管理系统天然需要三块能力商品信息要频繁增删改进销存订单状态要流转下单→支付→发货→完成库存要实时扣减避免超卖。这套逻辑用 Java 生态做起来最稳妥资料多、报错好查、答辩时也讲得出设计理由。这套系统适合谁适合已经学过 SSM 或 Spring Boot 基础、想用一个完整项目把前后端串起来的人。也适合那种“老师给的题目大而空自己不知道从哪下手”的人——果蔬销售管理系统的好处在于业务链路足够长但每一条链路都符合直觉登录、看商品、加购、下单、支付模拟、管理员发货、库存变化。跟着本文走完你拿到的不是一个“能跑就行”的 demo而是一个能讲清楚“为什么这么设计”的毕设项目。2. 拆解果蔬销售管理系统的标配架构Spring Boot Vue MySQL 怎么分工2.1 为什么是前后端分离而不是 JSP 一把梭2018 年以前的毕设管理系统普遍是 JSPServletMySQL 的传统单体结构页面和服务端代码混在一起。放到果蔬销售管理系统这个题目里会出现一个很难受的问题商品列表页要实时刷新库存和价格如果用 JSP 的模板渲染每一次库存变动都要重新请求整个页面体验很差而且代码里 Java 和 HTML 混着写答辩时讲解逻辑非常费劲。前后端分离的常见做法是Vue或 VueElement UI负责页面渲染和用户交互Spring Boot 提供 RESTful API 返回 JSON 数据MySQL 负责持久化。库存扣减、订单状态流转、价格计算全发生在后端前端只做展示和提交动作。这样分工清晰答辩时你能把“前端组件 → 后端接口 → 数据库表”一一对应起来这是高分毕设的常见叙事线。我一般建议后端用 Spring Boot 2.7.xJDK 8 或 11前端用 Vue 2 Element UI。选 Vue 2 不是因为它新而是因为 Element UI 对 Vue 2 的支持最成熟、网上案例最多毕设阶段不需要去踩 Vue 3 Element Plus 的兼容性坑。数据库用 MySQL 5.7 或 8.0 都行字符集记得统一 utf8mb4不然后面存emoji或特殊符号会报错。2.2 模块划分六个功能域一张图看懂果蔬销售管理系统按职责划分核心模块可以拆成六个用户模块管理员后台和普通顾客前台用 Spring Security 或 JWT 做登录认证商品模块果蔬分类、商品信息、规格按斤/按件、图片上传、上下架库存模块入库、出库、库存预警低于阈值高亮提醒订单模块购物车 → 提交订单 → 模拟支付 → 发货 → 确认收货价格模块进价管理、售价管理、促销价特价菜、价格变更历史数据统计简单销售额统计、热销商品排名按订单明细聚合一句话记住模块之间的关系顾客在前台浏览商品商品模块加入购物车并提交订单订单模块系统扣减库存库存模块并锁定价格价格模块管理员在后台处理发货与补货。流程里任何一个环节断裂整个系统看起来就“假”——比如下单后库存没变或者订单里的价格跟下单时的商品价格对不上。2.3 数据库表设计的常见落法五张核心表起步果蔬销售管理系统最少需要五张表用户表user、商品分类表category、商品表product、订单表orders、订单明细表order_item。很多人会漏掉第六张表——库存流水表stock_log它的作用后面会说先记住没有这张表你讲不清“库存到底怎么扣的”。五张表的字段设计可以按这个思路来CREATE TABLE category ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL COMMENT 分类名如叶菜类/水果类, sort INT DEFAULT 0 COMMENT 排序权重值越小越靠前 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品分类表; CREATE TABLE product ( id INT PRIMARY KEY AUTO_INCREMENT, category_id INT NOT NULL COMMENT 分类ID关联category.id, name VARCHAR(100) NOT NULL COMMENT 商品名如本地土豆, unit VARCHAR(10) DEFAULT 斤 COMMENT 销售单位斤/件/个, price DECIMAL(10,2) NOT NULL COMMENT 当前售价单位元, original_price DECIMAL(10,2) COMMENT 原价用于展示划线价, stock INT NOT NULL DEFAULT 0 COMMENT 可售库存扣减的字段, image VARCHAR(255) COMMENT 图片URL, status TINYINT DEFAULT 1 COMMENT 1上架 0下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品表; CREATE TABLE orders ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT 订单号建议前端生成或后端生成, user_id INT NOT NULL COMMENT 下单用户ID, total_amount DECIMAL(10,2) NOT NULL COMMENT 订单总金额, status TINYINT DEFAULT 0 COMMENT 0待支付 1已支付 2已发货 3已完成 4已取消, address VARCHAR(255) COMMENT 收货地址, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单表; CREATE TABLE order_item ( id INT PRIMARY KEY AUTO_INCREMENT, order_id INT NOT NULL COMMENT 订单ID, product_id INT NOT NULL COMMENT 商品ID, product_name VARCHAR(100) COMMENT 冗余商品名防止商品改名后订单历史错乱, price DECIMAL(10,2) NOT NULL COMMENT 下单时的成交单价, quantity INT NOT NULL COMMENT 购买数量, subtotal DECIMAL(10,2) NOT NULL COMMENT 小计金额 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单明细表;注意订单明细表里的 product_name 和 price 是冗余字段——这是刻意设计的因为订单是“历史快照”下单之后商品可以改名、调价但订单里必须保留“当时成交的记录”不然售后和对账会翻车。这是生鲜电商和普通商品管理系统的一个关键差异普通商品可以改价格但已生成订单不能受影响。3. 用 Spring Boot 跑通一条完整链路商品上架 → 浏览 → 加购 → 下单3.1 商品列表接口为什么不用 SELECT * 直接查前端首页要展示商品列表接口上来就写SELECT * FROM product是最省事、但答辩时最容易被动的方式——性能问题不说图片字段、创建时间这些列根本不需要一次性全量返回。前后端分离的项目里接口返回的 JSON 结构应该和前端组件的数据需求对齐。RestController RequestMapping(/api/product) public class ProductController { Autowired private ProductService productService; GetMapping(/list) public Result list(RequestParam(defaultValue 1) Integer page, RequestParam(defaultValue 10) Integer size, RequestParam(required false) Integer categoryId, RequestParam(required false) String keyword) { PageInfoProductVO pageInfo productService.queryPage(page, size, categoryId, keyword); return Result.success(pageInfo); } }这段代码的逻辑要点是分页参数和筛选条件都通过RequestParam接收前端可以只传?page1size10categoryId3来筛选某个分类下的果蔬。默认值写在注解里前端不传参数也不会报错。关键的实现其实在 ProductService 里一般用 MyBatis-Plus 的 LambdaQueryWrapper 来拼接条件Override public PageInfoProductVO queryPage(Integer page, Integer size, Integer categoryId, String keyword) { PageProduct p new Page(page, size); LambdaQueryWrapperProduct wrapper new LambdaQueryWrapper(); wrapper.eq(categoryId ! null, Product::getCategoryId, categoryId) .like(StringUtils.hasText(keyword), Product::getName, keyword) .eq(Product::getStatus, 1) // 只查上架商品 .orderByDesc(Product::getCreateTime); PageProduct result productService.page(p, wrapper); // 转 VO只保留前端需要的字段 ListProductVO voList result.getRecords().stream().map(product - { ProductVO vo new ProductVO(); BeanUtils.copyProperties(product, vo); return vo; }).collect(Collectors.toList()); PageInfoProductVO pageInfo new PageInfo(voList); pageInfo.setTotal(result.getTotal()); return pageInfo; }这里值得讲的是eq(categoryId ! null, ...)这种写法第一个参数是 boolean 条件条件为 true 才拼接这个查询条件前端不传 categoryId 时自动忽略避免了空指针和无效 SQL。这是 MyBatis-Plus 的惯用法答辩时被问“筛选逻辑怎么写的”可以直接指这行。另一个容易被问到的是为什么查出来的实体要转 VOView Object。因为 Product 实体里有 create_time 这类字段前端不需要而且实体类里的字段如果直接暴露给前端等于把你数据库表结构全暴露了。转 VO 既是规范问题也是安全意识。3.2 下单接口事务、库存扣减、价格锁定的一个注解下单是整个系统里最核心的操作它必须保证三件事订单和明细同时写入要么都成功要么都失败、商品库存足量才扣减、订单里的价格以下单时的商品售价为准。三件事串起来就是一个数据库事务。Transactional(rollbackFor Exception.class) public OrderVO createOrder(Long userId, ListCartItemDTO cartItems, String address) { // 1. 计算总金额并校验库存 BigDecimal total BigDecimal.ZERO; ListOrderItem orderItemList new ArrayList(); for (CartItemDTO item : cartItems) { Product product productMapper.selectById(item.getProductId()); if (product null || product.getStatus() ! 1) { throw new BizException(商品不存在或已下架: item.getProductId()); } if (product.getStock() item.getQuantity()) { throw new BizException(库存不足: product.getName()); } // 2. 记录下单时的价格快照防止后续改价影响历史订单 OrderItem orderItem new OrderItem(); orderItem.setProductId(product.getId()); orderItem.setProductName(product.getName()); orderItem.setPrice(product.getPrice()); orderItem.setQuantity(item.getQuantity()); orderItem.setSubtotal(product.getPrice().multiply(BigDecimal.valueOf(item.getQuantity()))); orderItemList.add(orderItem); total total.add(orderItem.getSubtotal()); } // 3. 生成订单并写入明细 Orders order new Orders(); order.setOrderNo(generateOrderNo()); order.setUserId(userId); order.setTotalAmount(total); order.setStatus(0); order.setAddress(address); orderMapper.insert(order); for (OrderItem item : orderItemList) { item.setOrderId(order.getId()); orderItemMapper.insert(item); } // 4. 扣减库存——这一步一定要放在创建订单之后、事务提交之前 for (CartItemDTO item : cartItems) { productMapper.deductStock(item.getProductId(), item.getQuantity()); } return buildOrderVO(order, orderItemList); }这段代码的核心设计意图要分清第一步是“校验”不是“扣减”校验和扣减之间必须留一个缓冲——如果校验通过后立即扣库存结果订单写入失败比如明细插入报错事务回滚会顺便把扣减也回滚所以逻辑上没问题反过来如果先扣库存再写订单订单失败时虽然事务也会回滚但代码阅读性差、出错排查麻烦。常见做法是先校验、再写主表、再写明细、最后扣库存全部放在同一个事务里。Transactional(rollbackFor Exception.class)这个注解值得细讲。默认情况下 Spring 只对 RuntimeException 回滚而对受检异常比如 IOException不回滚。毕设里很多人写了 Transactional 但没写 rollbackFor结果方法抛了自定义异常时数据没回滚导致库存扣了订单没生成。rollbackFor Exception.class的意思很简单所有异常都回滚。扣库存的 SQL 也有一点讲究UPDATE product SET stock stock - #{quantity} WHERE id #{productId} AND stock #{quantity}这条 SQL 用stock stock - #{quantity}做原子扣减而不是先查出来减完再更新避免了并发下超卖。AND stock #{quantity}是第二道保险如果执行后受影响行数为 0说明库存被其他请求抢先扣光了需要在代码里抛异常。这是生鲜电商的一个典型防超卖方案原理是数据库行锁。3.3 前端页面怎么调接口axios 封装与购物车状态管理后端接口写好后前端用 axios 请求即可。Vue 项目里我一般会在 src/utils/request.js 里做一个统一的 axios 实例带上 baseURL 和 token 拦截器import axios from axios const request axios.create({ baseURL: /api, // 配合后端 context-path 或 nginx 转发 timeout: 10000, headers: { Content-Type: application/json } }) // 请求拦截器每次请求自动带上 token request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] token } return config }) // 响应拦截器统一处理错误码 request.interceptors.response.use( response { const res response.data if (res.code ! 200) { this.$message.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } return res.data }, error { this.$message.error(网络异常请稍后重试) return Promise.reject(error) } ) export default request购物车的状态管理用 Vuex 或 Pinia 都可以作用是跨页面保存“已选商品和数量”。但要注意购物车里的数量和价格只是“展示用的缓存”真正下单时后端会重新校验库存和价格——前端改价无效因为后端拿到的是 productId 和 quantity价格由后端实时查询计算。这个设计在答辩时是加分项说明你做的是“后端可信”而不是“前端可信”。4. 库存与价格联动果蔬生鲜的存量、扣减、时价三条规则4.1 库存预警果蔬不比其他商品损耗是正常事件普通商品管理系统的库存字段只管“还有多少个”。果蔬销售管理系统不一样库存里包含了两种状态可售库存和实际库存。实际库存 100 斤但今天要挑出 5 斤烂叶子可售库存可能只有 95 斤。更常见的情况是门店进货 100 斤前台显示可卖 100 斤但下午损耗了 3 斤库存要手动调整。所以在库存设计里要有两个机制一个是“盘点调整”管理员可以修改库存数量并填写调整原因另一个是“库存预警”当可售库存低于阈值时后台列表里高亮显示避免顾客下单后才发现没货。库存流水的 SQL 可以这么设计CREATE TABLE stock_log ( id INT PRIMARY KEY AUTO_INCREMENT, product_id INT NOT NULL COMMENT 商品ID, change_type TINYINT NOT NULL COMMENT 1入库 2出库 3盘点调整 4订单扣减 5退货回补, change_quantity INT NOT NULL COMMENT 变更数量正数增加负数减少, before_stock INT NOT NULL COMMENT 变更前库存, after_stock INT NOT NULL COMMENT 变更后库存, remark VARCHAR(255) COMMENT 备注如订单号/盘点原因, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT库存流水表;评价一个果蔬系统好不好就看有没有这张表。没有库存流水管理员发现库存少了根本查不出原因有流水每一笔变动都有 trackable 的记录答辩被问“库存对不上怎么办”就有了交代。4.2 订单扣减库存必须用乐观锁不能用“先查后减”前面下单代码里的扣库存 SQL 用了AND stock #{quantity}这个写法在并发不高时没问题。但如果毕设想做得更扎实可以把它升级为乐观锁版本UPDATE product SET stock stock - #{quantity}, version version 1 WHERE id #{productId} AND version #{version} AND stock #{quantity}版本号字段 version 在每次更新时递增更新时校验版本是否等于客户端带过来的版本。如果更新失败影响行数为 0说明这期间库存被改动过需要重新加载商品再试一次或者直接提示用户“手慢了库存已更新”。这块和悲观锁SELECT ... FOR UPDATE对比来看悲观锁在读库存时就锁住行其他事务只能阻塞等待适合并发量高但冲突也高的场景果蔬系统这种毕业设计秒杀场景基本没有乐观锁更轻量代码也好讲清。答辩被问到“并发情况下怎么防止超卖”把这条 SQL 和前面的事务逻辑结合起来讲就是完整的链路。4.3 价格模块为什么要有“促销价”这个单独字段果蔬的价格浮动频率远超想象。同一颗大白菜早上和傍晚价格可能差一倍。如果直接改 product.price 字段历史订单里的价格快照不受影响因为 order_item 里存了快照但前台页面会混乱——用户刚加入购物车时看的价格和结算时显示的价格不一致容易产生纠纷。常见做法是加一个 price_type 或单独建促销表来区分“日常价”和“促销价”ALTER TABLE product ADD COLUMN price_type TINYINT DEFAULT 0 COMMENT 0普通价 1促销价; ALTER TABLE product ADD COLUMN promo_price DECIMAL(10,2) COMMENT 促销价为空表示无促销;下单时后端计算价格需要判断如果今天有促销价且促销库存还够按促销价结算否则按普通价结算。这样“特价土豆 0.99 元/斤”和“正常价 1.5 元/斤”可以同时存在admin 切促销时不需要修改原价顾客看到的是“划线价促销价”体验更真实。要注意的是促销价字段不能只在商品列表页展示下单接口里必须走同一套计算逻辑——否则就会出现列表页显示促销价、结算却按原价算的“阴阳价格”现象这是果蔬系统最常见的翻车现场。5. 果蔬销售管理系统避坑权限、分页、数据初始化三个高频翻车点5.1 管理员接口裸奔没做登录校验被老师点一下就穿帮现象项目能跑前端页面能打开但后台管理的接口直接访问/admin/product/list也能返回数据没有任何登录校验。老师随便打开一个无痕窗口输入后台地址直接看到所有订单和用户信息。原因只做了前端路由守卫没做后端接口拦截。Vue Router 的beforeEach只是前端跳转拦截绕过前端直接请求后端接口完全没有防护。这相当于大楼门口站了保安但侧门全部敞开。解决后端加一个拦截器或 Spring Security 配置拦截/admin/**路径校验请求头里的 token 是否有效。用拦截器的常见写法Component public class AdminAuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || !JwtUtil.verify(token)) { response.setStatus(401); response.setContentType(application/json;charsetUTF-8); response.getWriter().write({\code\:401,\message\:\未登录或登录已过期\}); return false; } return true; } }注册拦截器时注意拦截路径要写/admin/**同时排除/admin/login。这一步做完才算真正做了权限控制。5.2 分页查询返回 total 是 0MyBatis-Plus 分页插件没配置现象列表页能显示第一页数据但底部分页组件的“共 X 条”永远是 0翻页后页面空白。原因MyBatis-Plus 的分页功能需要显式配置分页插件很多人只引入了依赖但没写MybatisPlusInterceptor配置类。此时page()方法只执行了分页 SQL但 count 查询没生效total 自然为 0。解决新建一个配置类Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); PaginationInnerInterceptor pagination new PaginationInnerInterceptor(DbType.MYSQL); pagination.setMaxLimit(100L); // 防止一次查太多最多 100 条 interceptor.addInnerInterceptor(pagination); return interceptor; } }DbType.MYSQL要按实际数据库类型写如果是 PostgreSQL 但写成 MySQL分页 SQL 生成会出问题。setMaxLimit(100L)是可选项目的是防止前端传size99999一次性拉全量数据属于“顺手加一层防御”。5.3 数据库初始化脚本缺外键约束删数据时直接报错或产生孤儿数据现象删除一个商品分类时发现商品表里还挂着这个分类的数据导致逻辑错乱或者删订单时订单明细没一起删明细成了没有所属订单的“孤儿”。原因表设计时没有定义外键或者虽然定义了但 ON DELETE 行为没指定删除主表数据时子表数据不知道该怎么办。解决如果已经在用可以在建表语句里补上外键并明确 ON DELETE 行为ALTER TABLE product ADD CONSTRAINT fk_product_category FOREIGN KEY (category_id) REFERENCES category(id) ON DELETE RESTRICT ON UPDATE CASCADE; ALTER TABLE order_item ADD CONSTRAINT fk_item_order FOREIGN KEY (order_id) REFERENCES orders(id) ON DELETE CASCADE ON UPDATE CASCADE;注意这两条外键的 ON DELETE 行为不一样商品和分类之间用RESTRICT——有商品挂在分类下时禁止删除分类防止误删导致商品失去分类订单和明细则用CASCADE——订单删除时明细一起删因为明细离开订单没有独立意义。这个差异在答辩时主动讲出来是很加分的细节。5.4 管理员改价格后前端列表和详情页价格不一致现象两个页面显示同一种商品两个价格一个列表页一个详情页价格对不上客户投诉。原因前端两个组件分别请求了不同接口或者请求时传了不同的缓存参数。排查后常见原因是详情页接口返回的是 product.price而列表页接口返回的是包含促销价计算后的“实际展示价”两个价格来源不统一。解决统一后端接口只输出一个“最终价”字段前端不管列表还是详情都取这个最终价。典型做法是在 ProductVO 里增加一个displayPrice字段后端计算促销价和原价的关系后只输出它public BigDecimal getDisplayPrice() { if (promoPrice ! null promoPrice.compareTo(BigDecimal.ZERO) 0) { return promoPrice; } return price; }前端只读displayPrice不再自己判断。这样改完列表、详情、下单三个页面的价格永远一致。5.5 模拟支付环节做成了“假按钮”只调接口没做状态流转现象点了“模拟支付”按钮后前端提示支付成功但刷新后订单状态还是“待支付”。原因前端只弹了提示框没有调用后端接口改变订单状态。更隐蔽的问题是后端支付接口只改了订单状态没有校验这个订单是否属于当前登录用户——理论上可以横向越权把别人的订单改成已支付。解决支付接口至少要做两步第一步校验 orderId 归属于当前登录用户第二步把状态从 0 改为 1同时用乐观锁防止重复支付UPDATE orders SET status 1, pay_time NOW() WHERE id #{orderId} AND user_id #{userId} AND status 0如果影响行数为 0可能是订单不存在、不属于该用户、或者已经支付过了。前两种情况直接抛异常最后一种提示“请勿重复支付”。这套校验逻辑完整做下来模拟支付就不是假按钮而是一个有真实业务语义的状态机。6. 答辩加分与压箱底技巧把果蔬系统从“能跑”变成“能讲”毕设答辩和工程验收有个本质区别老师不会花半小时点点点你的系统他大概率会挑一两个“设计问题”来问。果蔬销售管理系统最容易问的、也是最容易答出深度的方向有三个第一“库存并发控制怎么做的”把第 4.2 节的乐观锁 SQL 和事务边界讲清楚顺带提一句为什么不用悲观锁——果蔬超卖场景少、锁开销不值。第二“如果库存不够但用户下单了怎么处理”把第 3.2 节的校验逻辑和第 5.1 节的事务回滚串起来讲校验失败直接抛异常Transactional 会回滚之前所有的写操作不会出现“订单生成了但库存没扣”或“库存扣了但订单没有”的中间态。第三“这个系统相比普通商品管理系统的差异点”我自己的习惯是准备一张“业务时序图”放 PPT 里把用户下单那一刻后端做的四步操作画出来校验商品状态 → 锁定价格快照 → 写入订单和明细 → 原子扣库存。面试或答辩时照着这张图从头讲到尾逻辑链不断老师能感觉到这项目不是拼凑的。最后一个压箱底技巧是写单元测试。不用多给下单服务写三个用例就够正常下单成功、库存不足、商品已下架。写测试不是为了测出 bug而是为了在答辩时展示“我不仅会写 CRUD还知道怎么验证业务逻辑的正确性”。有这段话撑着哪怕测试代码写得朴素印象分也比“我全部手动测过”高一个档次。果蔬销售管理系统这套题说白了就是“用工程方法搞定生活里的一件小事”。库存、价格、订单这三条线只要有一条的闭环讲清楚了整个系统就立住了。剩下的复制粘贴式模块不过是围着核心业务打转的配角。我当年做同类系统时最大的教训就是花了八成的力气打磨前端样式结果被老师一句“你这个库存是假的吧”噎住了。早把重心放在业务闭环和数据一致性上比什么都强。希望这篇笔记能帮你少走这一步弯路把重心放到真正值得的地方去。本文还有配套的精品资源点击获取