企业官网建设流程全解析

先说我为什么对这个题目感兴趣。果蔬仓储和普通商品仓储最大的区别在于：它背后是生鲜损耗问题。普通仓库放三个月不变质，果蔬可能在三天内就开始烂。做这个系统不是简单写一个增删改查，核心是管理“生命周期”——从入库那一刻开始，要知道它在哪个库位、哪个批次、还剩多少保质期、什么时候该预警、什么状态是待出库还是已损耗。

很多同学做SpringBoot毕设选题时会觉得“仓储管理系统太老套了”，但我实际做完这个果蔬版本后，发现它在业务深度和技术落地上都有值得打磨的空间。这篇文章我把完整的设计思路、表结构、核心代码逻辑、前后端打包部署的坑、答辩准备经验全部整理出来，已经做了毕设的同学可以拿来对照补充，还没开题的朋友可以把它当做一个完整参考。先明确一个前提：这个项目用到的核心栈是SpringBoot + MyBatis-Plus + MySQL + Vue + Element UI，已验证可跑通，下面所有内容都基于这个组合展开。

1. 果蔬仓储为什么不能照搬通用进销存逻辑

1.1 果蔬的生命周期成本：损耗比货值更要命

做仓储系统之前，我花了两天去菜市场旁边的小型配送站蹲点观察他们的工作方式，这是我这篇项目里最值钱的一步。他们不是按“货”管，而是按“批”管：今天进的这批西红柿是哪家农户送的、几点到货、预计能放几天、上周那批还剩多少没卖完，全在一张手写记货本上。

这个细节直接决定了整个系统的设计重心：普通仓储系统关注的是“数量准确”，果蔬仓储关注的是“在变质之前出库”。所以表结构里必须有生产日期、保质期天数、预警提前天数、当前状态（在库、待出库、已报损、已出库），而不是只有库存余量。

另外果蔬仓储有一个普通仓库没有的难题——单位不统一。同一种商品，批发进来可能是按箱，零售出库是按斤，内部统计时又需要折算到公斤。如果表结构里只有一个quantity字段，后期报表和盘点必然乱账。我最终采用的是“主单位+辅单位+换算率”的方案，入库时记录数量、单位和换算率，出库时自动换算，保证流水统一。

1.2 功能边界的确定：先定义"不做哪些功能"

这个项目特别容易失控的地方在于——做着做着就想塞进订单系统、会员系统、财务报表、物流跟踪。我一个朋友毕设做“图书管理系统”就是贪多，最后答辩时每个模块都是浅尝辄止，被老师连续追问三个“这个功能具体怎么实现的”就答不上来了。

我的做法是先划定边界，把果蔬仓储管理系统限定在四个核心模块：

• 库存管理：入库、出库、库存查询、库位管理、库存预警。
• 批次管理：入库时按批次记录生产日期和保质期，出库时按先进先出原则扣减。
• 损耗管理：定期盘点，生成盘盈盘亏单，记录损耗原因和责任人。
• 基础数据：果蔬分类、供应商、库位、计量单位。

不做订单、不做物流、不做财务结算，只做“货在仓库内发生的所有事情”。这样系统虽然看起来没那么宏大，但每一个模块都能讲清楚设计逻辑和实现细节，这正是答辩时最看重的深度。

1.3 系统核心角色与业务流程梳理

角色设定直接沿用了仓储场景中最典型的三类：

这里我没有设计太复杂的RBAC权限树。原因很简单：实际仓库管理中，角色就三四种，太多角色反而让演示成本升高。权限控制层面用Sa-Token做登录认证和简单权限拦截，比Spring Security轻量不少，适合这类单系统项目，代码量也少，答辩时解释起来也清楚。

业务流程最核心的一条线是：入库登记 → 生成批次 → 库存增加 → 保质期预警扫描 → 出库扣减（先进先出） → 盘点 → 损耗处理。后面几节我会把这条线上的每一步拆开讲。

2. 技术选型与工程搭建的核心考量

2.1 为什么是SpringBoot而不是其他框架

这个问题看似基础，但属于答辩必问。我当时答的思路是：SpringBoot解决了传统Spring配置繁琐、启动慢、依赖管理困难的问题。对内嵌Tomcat的支持让打包变成java -jar一键启动，不需要单独部署容器。对于果蔬仓储这种需要快速交付、迭代频繁的管理系统来说，开发效率是第一位的。

更实际的一点：SpringBoot的生态非常成熟，MyBatis-Plus、Sa-Token、MinIO、消息队列等中间件都有成熟的starter或集成方案。哪怕你只在毕设里用了其中两三个，后续想扩展功能时也有很清晰的路径。社区的博客、文档覆盖率高，遇到问题搜得到答案。对新手来说，这比“高深但遍地是坑”的技术栈要友好太多。

2.2 SpringBoot版本选择与依赖坑

这里我先踩过一个真实的坑：一开始图新鲜选了 SpringBoot 3.x，结果一些老教程里的依赖和写法全部失效。比如javax.servlet换成了jakarta.servlet，部分 MyBatis-Plus 版本还不兼容 SpringBoot 3 的自动装配，Sa-Token也要求特定版本才支持，一个项目卡了我两天。

核心经验：做这类管理系统，不要追新版本，选稳定版本。我最确认的方案是：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> <relativePath/> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <dependency> <groupId>cn.dev33</groupId> <artifactId>sa-token-spring-boot-starter</artifactId> <version>1.34.0</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>

这个组合改动最少、资料最全。强调一下，2026年了也不要轻易尝试SpringBoot 3.x配合MyBatis-Plus做毕设，除非你只想折腾环境不想写业务。2.7.18是真稳定，该有的功能一个不少，我的项目从开发到答辩没有因为这个版本出过任何问题。

2.3 前后端分离还是单体：我为什么选了“半分离”

市面上的主流教程都是前后端分离，Vue单独一个工程、后端一个工程，用Nginx或代理转发。但我实际做下来发现，对于毕设场景，更稳的方案是：开发时前后端分离，交付时把Vue打成静态包放进SpringBoot的static目录，最后只跑一个jar。

这样做有三个直接好处：

• 答辩演示时不用同时启动前端工程和后端工程，一台电脑一个jar就搞定，不会出现“环境突然起不来”的社死现场。
• 部署到云服务器时，只要一条java -jar命令，不需要配置Nginx反向代理，服务器资源占用也更小。
• 后期查错少一个环节：页面加载不出来时，不用先判断是代理问题还是接口问题。

具体操作上，开发时后端跑localhost:8080，前端通过vite.config.js里的代理转发请求：

server: { port: 3000, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

交付时在Vue工程里执行打包命令：

npm run build

把生成的dist目录下的所有文件复制到SpringBoot的src/main/resources/static目录下，重新打包即可。需要注意一个坑：如果vue-router用了history模式，刷新页面会出现404，最简单的解决办法是改用hash模式，或者写一个路由转发控制器。为了省时间，我直接用的hash模式，效果完全够用。

3. 面向果蔬特性的数据库设计

3.1 核心表结构一览

数据库我设计了8张核心表。每一张表我都能说出“为什么必须要有”或“为什么这样设计”的理由，这个在本子设计阶段特别重要，因为毕设论文里必须有一整章讲数据库设计。

这里有两个容易忽略的细节：

一是inventory_record和inventory_batch的关系。我记录的不仅是“这次出库了多少”，还记录“从哪个批次出库”，这是实现先进先出的数据基础。如果只有流水没有批次关联，出库顺序就没有办法校验。

二是category表为什么不用枚举字段。刚开始我想用Java枚举写死果蔬分类，写到第8个分类时发现根本列不全——叶菜类、根茎类、瓜果类、菌菇类、水果类下面还要再分，而且不同季节还会调整。动态表的设计让管理员可以在界面上直接维护分类，不用改代码。

3.2 批次字段设计：保质期和预警怎么计算

果蔬管理系统最重要的字段设计都在inventory_batch表里。我先说核心字段的含义：

• production_date：生产日期/采摘日期。入库时填写。
• expiry_date：过期日期。这个字段我建议入库时直接算好存进去，而不是在查询时实时计算。
• warn_days：预警天数。比如绿叶菜保质期5天，预警提前1天；苹果保质期30天，预警提前3天。这个值可以在分类或商品上配置默认值。
• status：批次状态。0-在库，1-部分出库，2-已出库，3-已报损。

为什么expiry_date要入库时就算好？因为不同果蔬的保质期在产品层面是统一配置，但同一商品在不同批次的供货质量可能有差异。今天进的这批西红柿可能因为农户采摘时下了雨，保质期只有3天；上一批是晴天采摘，能放5天。如果系统强制按商品配置计算，就失去了“按批管理”的意义。所以入库时允许仓管员根据到货实际情况调整保质期，系统自动算expiry_date = production_date + shelf_life_days。

这个逻辑在入库接口里其实就是一行计算：

LocalDate expiryDate = productionDate.plusDays(shelfLifeDays); batch.setExpiryDate(expiryDate);

预警模块则是每天定时扫描expiry_date在warn_days范围内的在库批次，插入或更新预警记录。注意不要只扫status = 0的批次，部分出库的批次（status=1）也要扫，因为剩下那些货也可能会烂在库里。

3.3 金额类型和单位换算这两个坑必须躲开

这里单独说两个我在开发过程中交过学费的细节。

第一个是金额字段。数据库里所有涉及金额的字段必须用decimal，Java实体里必须用BigDecimal。我第一次做的时候图省事用了double，结果入库出库的单价和金额在小数计算上出现0.0000001元的误差，盘点对账时差一分钱，查了半下午才发现是浮点精度问题。真的不要在这个事情上省事，直接用BigDecimal就没这些烦恼。

第二个是果蔬的单位换算。前面提过同一种商品存在按箱进、按斤出的情况。我用的是两张表配合：product表里存main_unit（主单位，如“斤”）和sub_unit（辅助单位，如“箱”）以及convert_rate（换算率，如1箱=20斤）。入库时如果选择“箱”，后台自动把quantity = 输入数量 * convert_rate折算到主单位“斤”存储，出库时同理。

这个设计在溯源时有点绕，但报表统计时非常方便：所有库存数量在数据库里都是统一的主单位数值，不需要在写SQL时做case when换算。如果某个果蔬只有一种单位，convert_rate = 1即可，逻辑统一。

3.4 库存流水表为什么必须单独建

我见过不少同学把库存量直接update在批次表上，出入库时不记流水。短期看代码写起来简单，但有两个致命问题：

第一，没法回答“这批货去哪了”。当库存数据对不上时，你没有任何操作日志可以用来排查是哪一笔出入库造成的。库存系统最怕的就是“账对不上但不知道错在哪一步”。

第二，报表完全没有数据支撑。损耗率、周转率、供应商供货质量分析、热门品种销售趋势，全部依赖历史流水。没有流水表，这类分析就是空中楼阁。

所以我的inventory_record表设计得比较宽，但每多一个字段都有他的用途：

CREATE TABLE `inventory_record` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `product_id` bigint(20) NOT NULL COMMENT '商品ID', `batch_id` bigint(20) NOT NULL COMMENT '批次ID', `type` tinyint(4) NOT NULL COMMENT '1-入库 2-出库 3-盘盈 4-盘亏 5-报损', `quantity` decimal(10,2) NOT NULL COMMENT '变动数量(主单位)', `unit` varchar(20) DEFAULT NULL COMMENT '实际操作单位', `related_no` varchar(64) DEFAULT NULL COMMENT '关联单号(入库单/出库单/盘点单)', `operator` varchar(50) NOT NULL COMMENT '操作人', `remark` varchar(255) DEFAULT NULL COMMENT '备注', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_batch` (`batch_id`), KEY `idx_product_time` (`product_id`, `create_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='出入库流水表';

注意我加了create_time索引，因为后续的损耗趋势分析、日出入库报表都要按时间范围查询，没有索引的话数据量稍大表就会被慢查询拖住。

4. 核心业务模块的实现细节

4.1 入库登记：批次信息和预警日期怎么联动

入库接口是整个系统的入口，业务逻辑也是最多的。我的入库单是前端一次提交多行商品，后端一次性生成多个批次。

核心流程是：

1. 校验商品是否存在、库位是否有效、供应商信息是否完整。
2. 为每个入库明细生成唯一batch_no，规则是YYYYMMDD + 商品ID + 三位流水号，比如20260509_3_001。
3. 根据商品配置的保质期天数，结合当天日期计算expiry_date。
4. 调用库存批次新增逻辑，默认状态为0-在库。
5. 写一条type=1(入库)的流水记录。

这里有一个隐藏的业务规则：同一商品同一天入库多次，也必须生成不同批次。原因很简单，不同批次的果蔬成熟度不同，先进先出时后面的批次不应该被合并。我当时抱着“一个商品一个批次，省事”的想法做了一版简化，结果很快发现批次一旦合并，出库时看到的是合并后的总量，无法区分哪些快过期、哪些还能放，直接违背了做果蔬仓储的核心目的。后来硬着头皮重构，把批次拆到了入库明细级别，才终于对了。

Service层代码核心逻辑大致如下：

@Transactional(rollbackFor = Exception.class) public void inbound(List<InboundItemDTO> items, String operator) { for (InboundItemDTO item : items) { Product product = productService.getById(item.getProductId()); // 单位换算：统一折算到主单位 BigDecimal quantity = convertToMainUnit(item.getQuantity(), item.getUnit(), product); // 批次号生成 String batchNo = generateBatchNo(product.getId()); // 保质期计算 LocalDate expiryDate = LocalDate.now().plusDays(item.getShelfLifeDays()); // 创建批次 InventoryBatch batch = new InventoryBatch(); batch.setBatchNo(batchNo); batch.setProductId(product.getId()); batch.setQuantity(quantity); batch.setProductionDate(LocalDate.now()); batch.setExpiryDate(expiryDate); batch.setWarnDays(item.getWarnDays()); batch.setStatus(0); inventoryBatchMapper.insert(batch); // 写流水 InventoryRecord record = new InventoryRecord(); record.setProductId(product.getId()); record.setBatchId(batch.getId()); record.setType(1); record.setQuantity(quantity); record.setUnit(item.getUnit()); record.setRelatedNo(batchNo); record.setOperator(operator); inventoryRecordMapper.insert(record); } }

注意两个加了@Transactional，因为一次入库可能涉及多张表多个批次，任何一步失败都应该整体回滚，否则会出现“流水写了但批次没建”这种脏数据，后面对账时非常痛苦。

4.2 出库扣减：先进先出FIFO的SQL怎么写

这是整个项目中技术含量最高的地方。果蔬仓储必须先进先出，不然先入库的货一直堆在库里烂掉，后入库的反而先出，损耗率报表会惨不忍睹。

先进先出的逻辑简单说就是：查询该商品所有status IN (0, 1)的在库批次，按expiry_date升序排列，然后从最早的批次开始扣减库存。

我最初用Java代码逐批次更新，发现两个问题：一是循环调用Mapper多次update，代码丑、性能差；二是高并发下库存可能被超扣。后来换成了MySQL的SELECT ... FOR UPDATE悲观锁方案，保证同一批次同一时间只能被一个出库事务修改。

核心代码如下：

@Transactional(rollbackFor = Exception.class) public void outbound(OutboundDTO dto, String operator) { BigDecimal planQty = dto.getQuantity(); // 计划出库量，主单位 // 查询最早过期、且在库的批次，加悲观锁 List<InventoryBatch> batches = inventoryBatchMapper.selectLockedBatches( dto.getProductId(), LocalDate.now()); BigDecimal remaining = planQty; for (InventoryBatch batch : batches) { if (remaining.compareTo(BigDecimal.ZERO) <= 0) { break; } BigDecimal batchQty = batch.getQuantity(); if (batchQty.compareTo(remaining) >= 0) { // 当前批次足够扣减 batch.setQuantity(batchQty.subtract(remaining)); batch.setStatus(batch.getQuantity().compareTo(BigDecimal.ZERO) == 0 ? 2 : 1); // 0则变为已出库 remaining = BigDecimal.ZERO; } else { // 当前批次不够，继续扣下一个批次 batch.setQuantity(BigDecimal.ZERO); batch.setStatus(2); remaining = remaining.subtract(batchQty); } inventoryBatchMapper.updateById(batch); // 每个批次扣减都写一条流水 writeOutRecord(batch, dto, operator); } if (remaining.compareTo(BigDecimal.ZERO) > 0) { throw new BusinessException("库存不足，无法完成出库"); } }

对应的SQL：

<select id="selectLockedBatches" resultType="..."> SELECT * FROM inventory_batch WHERE product_id = #{productId} AND quantity > 0 AND status IN (0, 1) AND expiry_date >= #{today} ORDER BY expiry_date ASC, id ASC FOR UPDATE </select>

这里有一个为什么用悲观锁而不是乐观锁的解释：果蔬仓储的业务并发不会特别高，出库失败重试的代价也不低，悲观锁在这个场景下简单可靠，不容易出现并发超卖。如果将来要应对大并发，可以再精化分离读写、用Redis做分布式锁，但那是另外一个复杂度等级了，目前这个实现已经足够稳妥。

4.3 盘点与损耗：盘盈盘亏怎么自动生成调整单

果蔬仓储的盘点是个高频操作，而且是损耗率数据的直接来源。理论上盘点只在“账面数量”和“实际数量”不同时才产生调整单。但现实中，仓库里的损耗每天都在发生，果蔬从保鲜库拿出来、摆到发货区、挑拣掉磕碰的个体，这个过程中的损耗算谁的、怎么记录，都需要业务规则来约束。

我设计的盘点流程是：创建一个盘点任务 → 仓管员选择库位/商品 → 逐项填写实盘数量 → 系统自动对比账面数量 → 生成盘盈或盘亏调整 → 写入流水。

核心逻辑在对比阶段：

BigDecimal diff = realQty.subtract(bookQty); // 正数为盘盈，负数为盘亏 if (diff.compareTo(BigDecimal.ZERO) == 0) { // 账实一致，跳过 continue; } if (diff.compareTo(BigDecimal.ZERO) > 0) { // 盘盈：生成盘盈记录，type=3 // 这里要有一个审批动作，防止有人故意虚增库存 } else { // 盘亏：生成盘亏记录，type=4，同时记录损耗原因 // 损耗原因：腐烂/磕碰/虫害/失窃/其他 }

盘亏单里的loss_reason字段非常关键。答辩时老师如果问“系统怎么帮助企业降低损耗”，你直接展示损耗原因统计报表，告诉他“我们按原因维度汇总，发现发货区周转太慢导致的磕碰损耗占了大头，于是企业把发货区的货架间距调整了，第二个月损耗率降了2个百分点”，这个回答就非常落地。

另外我设置了一个小规则：报损操作必须关联明细原因和现场备注，不能只填写数量。这样做一方面防止仓管员把正常损耗当成“核销库存”的口子，另一方面也为以后做损耗趋势分析留了数据基础。果蔬仓储里损耗数据本身要比“多卖了几块钱”更有分析价值。

4.4 保质期预警的两种实现方式

保质期预警是这个系统的灵瑰功能，讲解一下两种方案的取舍。

方案一：定时任务方案。

SpringBoot自带@Scheduled注解，每天凌晨扫描一次在库批次，把未来三天内到期或者已经过期的批次查出来，生成预警记录，同时推送到前端预警面板。实现简单、可靠，够用。

@Component public class ExpiryWarnTask { @Scheduled(cron = "0 10 0 * * ?") // 每天0点10分执行 public void scanWarnBatch() { LocalDate today = LocalDate.now(); LocalDate warnDate = today.plusDays(3); // 扫描未来3天到期批次 List<InventoryBatch> warnBatches = inventoryBatchMapper.selectWarnBatches(today, warnDate); // 处理预警逻辑：更新预警状态、写入预警通知 } }

方案二：事件驱动方案。

入库时把批次按到期日注册到延迟队列，或者用Redis的过期key回调机制，到期自动触发提醒。优点是实时性更好，但复杂度高，依赖额外组件，不好跟老师解释清楚，并不是必须的。

最终我用了方案一，因为果蔬仓储的预警需求并不需要“秒级实时”，只要每天扫描一次就不会漏掉。系统里还有一个“预警看板”，把预警批次按紧急程度排序，最前面的就是今天必须处理的，仓管员上班看一眼就知道今天要打折处理哪些货。这个交互设计很朴素，但老板看到真实的“今天再不出库就要烂掉45斤菜”，比任何图表都有说服力。

5. 前后端对接、部署上线与答辩准备

5.1 vue打包放进SpringBoot：单Jar一键启动

前面前后端半分离方案提到了最终要把dist放进static目录。这一步看起来简单，但有一个细节需要特别注意：打包前检查后端所有请求的前缀。我的后端接口统一以/api开头，前端请求全走这个前缀，打包后静态资源和接口可以共用一个端口，不需要额外处理跨域。

验证一下是否正常只需要两步：启动jar后访问http://localhost:8080，能出页面；然后随便点一个菜单确认接口正常响应。如果出现404，多半是路由模式问题。Vue的history模式下刷新子页面会404，最简单改成hash模式，没有其他成本。

顺便提一个交互细节：菜单权限要和后端保持一致。前端菜单按照角色动态渲染，后端接口也做角色拦截，不要只靠前端隐藏按钮。我遇到过同学的前后端接口没加拦截，直接通过URL调用管理员接口就能越权的低级问题，答辩时被老师抓个正着。

5.2 服务器部署时的上传与存储问题

果蔬入库和出库时都应该允许拍照留证，比如入库时拍一张供货商送货的实物照片，出库时拍一张装车照片。照片上传直接决定了一个隐藏的坑：SpringBoot打成jar包后，项目内部目录是只读的，重启jar包会清空所有写入到jar包内部路径的文件。如果你把图片存在src/main/resources/static/upload这种位置，本来想着省事，结果图片会随着每次重新部署丢失，等于数据白存了。

正确的做法是：上传的文件存储在外部路径，比如/home/ubuntu/fruit-warehouse/upload，同时把该路径配置为静态资源映射。这样jar包升级替换时，上传的文件不受影响。

# application.yml upload: path: /home/ubuntu/fruit-warehouse/upload spring: web: resources: static-locations: classpath:/static/,file:${upload.path}

本地开发时也可以配置成D:/workspace/upload，只要配置文件里分开处理就行。

对于上传文件较大或者想单独管理文件的问题，可以集成MinIO对象存储。这个不是必须的，但老师如果问你“文件怎么管理的”，你说“本地外部存储方案，后期可以无缝切换MinIO”，就能表明你对这个问题有认知。

5.3 答辩时怎么讲这个项目

答辩的核心不是复读代码，而是讲清楚“你发现了什么问题，你用什么方案解决，为什么是这个方案”。拿这个果蔬仓储管理系统举例，最大的亮点逻辑是这样表述的：

“系统设计初期我发现果蔬仓储和普通仓储的最大不同在于生鲜的保质期管理，所以我把系统重心从单纯的数量管理调整到‘以批次为单位、以时间为约束的库存管理’。具体来说，入库时记录生产日期并按保质期计算过期日和预警日，出库时强制按到期日升序扣减（先进先出），每天定时扫描预警批次生成待处理任务。同时，通过盘点生成损耗单并记录损耗原因，用于后续损耗分析。这样整个系统就围绕‘减少果蔬变质损耗’这个核心目标，而不是一个泛泛的进销存管理系统。”

这一段说下来，老师对项目的印象会从“一个CRUD管理系统”变成“有针对性的业务系统”，分数的差距就在这里拉开。

最后再分享几个我实测下来的小建议：

1. 做毕设的时候别一头扎进代码，先花时间把业务流程图和数据表设计图画清楚。画图的过程就是理清思路的过程，后面编码和写论文能省一半时间。
2. 前端页面不要过度设计。果蔬仓储这种场景，操作界面重点是“列表清晰”、“表单顺手”、“数据看得明白”。我当时原型用的是Element UI默认风格，整体观感就已经比同组大多数同学好了。
3. 答辩时准备好一张“技术架构图”，把SpringBoot、MyBatis-Plus、Vue、MySQL、Sa-Token分别放在什么层级标记出来。老师问技术栈时直接对着图讲，清晰又有条理。这个习惯我一直保留到了工作后的项目中。

说实话，果蔬仓储这个题目看上去不大，但真正做完你会发现，它是一个“麻雀虽小、五脏俱全”的典型管理系统，从表结构设计到业务规则，从前后端联调到答辩讲解，每一步都能学到真实项目需要的东西。希望这篇完整的设计实现记录能帮正在做毕设的你少走几个我走过的弯路。