企业官网建设流程全解析

1. 后疫情时代的农产品供应链，到底在解决什么业务问题

先说个真实的场景。2022年某地临时管控期间，我帮家里老人抢菜，社区团购群里每天早上六点接龙，菜价翻了快三倍还不一定抢得到。另一边，郊区有个做蔬菜合作社的朋友跟我吐槽，地里几万斤生菜卖不出去，因为采购商进不来，信息根本传不到有需求的人手里。生产和需求两头都急，中间隔着好几道信息断层——这种情况在疫情反复的几年里反复上演，不是个例，而是农产品流通体系长期存在的结构性问题被极端环境放大后的结果。

这个项目的出发点，就是把“后疫情时代”这四个字从新闻标题变成系统的需求文档。常规的农产品电商系统，核心逻辑是“把农产品挂到网上卖”，跟卖衣服卖数码产品没有本质区别。但供应链系统不一样，它要回答的问题不是“怎么把商品陈列得好看”，而是“在需求剧烈波动、运力时断时续、产地信息不透明的情况下，怎么让农产品以合理的成本、在可接受的时间内，从田间地头到达消费者手里”。

所以这个基于Spring Boot的农产品供应链系统，设计目标非常明确：围绕“产、供、运、销”四条主线，把原来散落在Excel表格、微信群里、电话沟通中的订单、库存、批次、流向、车辆、价格信息，统一收口到一个平台上。系统服务三类角色：产地端的农户和合作社、中间环节的仓储物流管理人员、终端的分销商和社区团购团长。每一类角色看到的数据和能执行的操作都不一样，但所有数据最终都汇聚到同一套逻辑里，互相咬合，形成一个闭环。

顺带说一句，这类选题在毕业设计里非常讨巧，因为它的业务复杂度足够撑起一个有分量的系统，但又不要求你懂高深的算法。真正的难点在于业务逻辑的梳理——需求分析做得越细，后面的编码就越顺。很多同学毕设做到一半推翻重来，八成是前期没把“这个系统到底干什么事”想清楚，一上来就建表写代码，越写越乱。这篇博文就是把我做这个系统的完整思路、技术选型、核心实现和踩坑记录摊开来讲，希望能帮到正在为毕设头秃的各位。

2. 需求分析比写代码更重要：从主链路推导出来的功能清单

2.1 先理清主链路，再谈功能模块

我不建议一上来就照着网上流传的“XX管理系统”模板抄模块，什么用户管理、角色管理、菜单管理、日志管理——那些是系统骨架，不是业务本身。骨架当然要，但先想清楚业务主链路，再回头补骨架，顺序才对。

农产品的供应链主链路是这样的：产地（农户/合作社）→ 加工/集配中心（仓储）→ 干线运输 → 城市分拨 → 终端销售（商超/社区团购/线上商城）。每个环节都有信息产生：农户要上报什么菜熟了、有多少量、什么价格；集配中心要知道货什么时候到、质检结果如何、库存剩多少；运输环节要记录车辆在哪、温度是否达标；终端要下单、要查询到货时间、要处理损耗和退换。

把这些环节逐一拆开，就能推导出系统的核心模块，而不是拍脑袋凑功能。我最终确定的模块边界是这样：

• 基础信息管理：供应商（农户/合作社）档案、商品目录、仓库信息、车辆信息、客户（分销商/团长）档案。
• 批次与库存管理：每一批农产品从产地入库开始就有独立的批次号，记录产地、采收日期、质检结果、当前所在仓库、库存余量、保质状态。这是供应链系统和普通电商系统最本质的区别——电商管SKU，供应链管批次。
• 订单管理：下游客户下单，系统自动匹配可用的库存批次，生成出库单和配送单。订单状态跟踪到签收。
• 仓储物流管理：入库、出库、盘点、调拨，以及运输任务的指派、在途状态更新、签收确认。
• 质量溯源：通过批次号反查某批货的产地信息、检测报告、运输路径，形成一个可追溯的链条。后面我会详细讲实现思路。
• 供需预警与数据看板：根据历史销量、当前库存、在途订单，预测未来一段时间的需求，缺货或者积压时自动预警。这是整个系统里最有技术含量、也最适合在答辩时展开讲的部分。

2.2 双轨订单设计：为什么不能只做一套下单流程

常规电商系统的订单流程只有一条线：用户下单→付款→发货→收货。但农产品供应链系统在后疫情时代必须支持两种完全不同的订单模式，这就是我反复强调的“双轨设计”。

第一条轨是常规预售订单。分销商或者消费者在平台上浏览商品，看到的是“未来某个时间段可发货”的期货逻辑。比如社区团购团长今天下单100斤西红柿，系统反馈的是后天上午送达，价格基于当前产地报价。因为生鲜产品不能像工业品那样有大量现货库存，多数订单是“以销定采”，先收集订单，再向产地要货。

第二条轨是应急保供订单。这是后疫情时代的特殊产物。当局部地区出现突发情况，运力受限、线下渠道关闭时，系统要能快速切换为保供模式：由政府或社区组织发起定向采购，系统自动锁定指定产地或仓库的储备库存，优先匹配运力，全程跟踪配送进度，甚至要支持“按户分装”这种颗粒度更细的订单拆分。

这两条轨的数据模型必须从一开始就设计成一张订单主表加多个扩展字段，而不是建两张表。比如订单类型字段区分“常规”和“保供”，保供订单额外记录发起方、关联社区、配送时限要求；常规订单则走标准的价格计算和支付流程。后面我会把表结构详细展开，这里先记住一个原则：业务模式的分叉不要用表结构的分叉来解决，用字段和状态机来解决，否则后续统计和扩展会非常痛苦。

2.3 从功能列表反推角色权限

模块清单确定之后，再回过来设计角色和权限就顺理成章了。系统里我划分了四个角色：

权限设计上我没有用过于复杂的RBAC（基于角色的访问控制）模型。Spring Security是必须上的，但权限粒度到角色级别就够用了，不需要细到按钮级别。四个角色对应四套菜单，外加一个管理员拥有全部权限，做毕设的体量完全足够。非要把权限粒度搞得比公司OA还细，反而给自己挖坑。

3. 核心数据模型设计：批次、双轨订单和预警计算

3.1 商品批次表的设计思路

这一步是整个项目的地基，我当初在这上面花的思考时间最多。农产品供应链的库存管理，核心实体不是“商品”，而是“批次”。同一款西红柿，今天从A合作社收的和三天后从B合作社收的，虽然商品ID相同，但产地不同、采收时间不同、质检结果不同、存放库位不同，必须当作两个独立记录来管理。

批次表的核心字段我设计成这些：

CREATE TABLE product_batch ( id BIGINT PRIMARY KEY AUTO_INCREMENT, batch_code VARCHAR(32) NOT NULL COMMENT '批次编号，规则：产地编码+日期+流水', product_id BIGINT NOT NULL COMMENT '商品ID', supplier_id BIGINT NOT NULL COMMENT '供应商（农户/合作社）ID', origin_place VARCHAR(100) COMMENT '产地', harvest_date DATE COMMENT '采收日期', quantity DECIMAL(10,2) NOT NULL COMMENT '初始数量（公斤/件）', remain_quantity DECIMAL(10,2) NOT NULL COMMENT '剩余数量', unit_price DECIMAL(10,2) COMMENT '批次采购单价', quality_status INT DEFAULT 0 COMMENT '质检状态：0待检 1合格 2不合格', quality_report_url VARCHAR(255) COMMENT '质检报告附件地址', warehouse_id BIGINT COMMENT '当前所在仓库', storage_location VARCHAR(50) COMMENT '库位编码', status INT DEFAULT 0 COMMENT '批次状态：0在库 1锁定 2出库完 3报损', expire_date DATE COMMENT '建议保质期/最佳销售日期', created_time DATETIME, updated_time DATETIME ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品批次表';

这个表有个很容易被忽略的设计点：remain_quantity是加减操作的核心字段，每次出库、报损、退货都必须在这个字段上做扣减，同时通过一张流水表记录每一次变动。扣减操作一定要放在事务里，配合行级锁，否则多订单并发出库时会超卖。我开发时先用了简单的“查询剩余数→判断够不够→更新剩余数”三段式，压测时发现高并发下会出现同一批次被两个订单同时扣减的情况，后来改成在更新语句里直接做条件扣减：

UPDATE product_batch SET remain_quantity = remain_quantity - #{quantity} WHERE id = #{batchId} AND remain_quantity >= #{quantity}

一行SQL搞定原子操作，受影响行数为0说明库存不足。这个写法在生鲜分秒必争的场景下很实用，建议记下来。

3.2 双轨订单的数据建模与状态机

订单主表我设计成可同时容纳常规订单和保供订单的“大一统”结构：

CREATE TABLE supply_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, order_type INT NOT NULL COMMENT '1-常规订单 2-保供订单', customer_id BIGINT NOT NULL COMMENT '客户ID（分销商或社区）', customer_type INT COMMENT '客户类型：1-分销商 2-社区团长', total_amount DECIMAL(10,2) COMMENT '订单总金额', order_status INT NOT NULL COMMENT '状态机：0待支付 1已支付/待确认 2已确认 3配货中 4运输中 5已签收 6已取消 7售后处理中', source_order_id BIGINT COMMENT '保供订单可关联上游指令单', community_id BIGINT COMMENT '保供模式：关联社区ID', delivery_deadline DATETIME COMMENT '保供模式：要求送达时间', delivery_address VARCHAR(255), contact_phone VARCHAR(20), create_time DATETIME, update_time DATETIME, create_by BIGINT, INDEX idx_customer_time(customer_id, create_time), INDEX idx_status_priority(order_status, delivery_deadline) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单主表';

订单状态机是整个系统的业务中枢。我用了整数状态而非字符串状态，一是省存储，二是排序和判断都方便。状态流转规则集中在Service层校验——比如只有“已确认”状态才能生成出库单，“保供订单”可以跨过“待支付”直接进入“已确认”，状态跳转规则写在枚举里统一管理，避免各层代码到处写魔法数判断。

订单表和批次表之间的关联通过订单明细表完成，这样一份订单可以同时匹配多个批次的货源——应急保供时，从三个不同仓库调货凑齐一单是很常见的事。这种“多批拼单”的灵活性，恰恰是供应链系统必须支持的业务场景。

3.3 供需预警的计算逻辑

预警模块是答辩时最能拉开分数差距的部分，也是实际项目里最有使用价值的模块。核心思路是基于时间窗口的滚动预测：根据过去N天的平均日销量，结合当前库存余量和在途订单量，计算出“预计可供天数”，再跟安全阈值对比。

我用的计算模型是：

预计可供天数 = （当前库存余量 + 在途补货量） / 预测日销量 缺货风险阈值：预计可供天数 < 补货前置周期 + 2天 积压风险阈值：预计可供天数 > 15天 且 商品保质期较短

预测日销量不用搞花哨的机器学习，移动平均法加趋势修正就够了。我取过去7天的数据做加权平均，越靠近当天的权重越高：

public BigDecimal predictDailySales(Long productId) { // 取近7天的每日销量，按日期从近到远赋权 7,6,5,4,3,2,1 List<DailySalesVO> list = orderDetailMapper.selectDailySales(productId, 7); BigDecimal totalWeight = BigDecimal.ZERO; BigDecimal totalSales = BigDecimal.ZERO; for (int i = 0; i < list.size(); i++) { BigDecimal weight = BigDecimal.valueOf(7 - i); totalSales = totalSales.add(list.get(i).getSales().multiply(weight)); totalWeight = totalWeight.add(weight); } return totalSales.divide(totalWeight, 2, RoundingMode.HALF_UP); }

预警任务用定时任务触发，每天凌晨和中午各跑一次，扫描所有活跃商品批次，命中阈值就生成预警记录，同时消息推送给平台管理员和相关的仓储人员。底层用Spring Boot自带的@Scheduled单机跑就够，没必要上分布式任务调度平台。

这个模块的价值在于，它把“供应链管理水平”从一个抽象概念变成了可量化的指标。答辩时你可以用一组真实数据演示：某商品库存还能撑3天，而采购前置周期是5天，系统自动预警，管理员一键把预警转成采购单——这种业务闭环的演示效果，比单纯展示CRUD强太多了。

4. Spring Boot技术选型的取舍逻辑与关键配置

4.1 Spring Boot在这个场景里解决了什么问题

说句不算夸张的话，这类管理系统选Spring Boot几乎是当前Java技术栈下的最优解。原因不是Spring Boot本身多高级，而是它把过去Java Web开发里最繁琐的“配置地狱”给终结了。

传统的SSH（Spring + Struts + Hibernate）或者早期的Spring MVC项目，光配置文件就要写好几百行，XML里密密麻麻的bean定义、数据源配置、事务代理，新手光是把环境跑起来就得折腾一周。Spring Boot最核心的贡献是自动装配机制——它通过@EnableAutoConfiguration注解触发spring.factories中声明的各种AutoConfiguration类，根据classpath下的依赖自动创建和配置Bean。什么意思呢？你在pom.xml里引入spring-boot-starter-data-redis，Spring Boot检测到classpath里有Redis的客户端类，就自动帮你创建RedisTemplate等一系列Bean，你只需要在application.yml里填连接地址和密码就行。

自动装配机制在毕设答辩里也是高频考点。面试官通常会追问：“讲一下Spring Boot自动装配的原理。”回答的要点就三步：Spring Boot启动时，@SpringBootApplication组合了@EnableAutoConfiguration，后者通过AutoConfigurationImportSelector加载META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件中列出的所有自动配置类；每个自动配置类上用@ConditionalOnClass、@ConditionalOnMissingBean等条件注解判断是否需要真的装配；最后执行配置类里的@Bean方法创建对象。能把这个链路讲清楚，这一题就稳了大半。

4.2 关键依赖选型与版本避坑

我用的组合是：Spring Boot 2.7.x + MyBatis-Plus + MySQL 8.0 + Redis + MinIO + WebSocket + Spring Security + JWT。这套组合在国内Java毕设里属于主流中的主流，网上资料多、遇到问题搜得到、老师也认可。

版本上有一个重要建议：如果你不是对Java 17有强烈需求，Spring Boot用2.7.x而非3.x。Boot 3.x基于Jakarta EE规范，包名从javax换成了jakarta，很多老版本的依赖不兼容，网上搜到的解决方案大部分还是针对2.x的。2024年做毕设时用3.0.6踩了Activemq整合的坑，花了两天才解决。学术项目求稳不求新，选择稳定的2.7.18就好。我在本地实际开发时用的全套版本参考：

一个很常见的坑是MySQL连接时区问题。在application.yml里必须加上serverTimezone=Asia/Shanghai，否则数据库时间和你本地时间差八个小时，排查起来让人崩溃。

4.3 前后端分离和部署方案

前端我用Vue 2 + Element UI。这个选择有点“过时”但非常务实：Vue 2的教程和组件库资料比Vue 3多一个数量级，本科生做毕设完全没必要用Vue 3的组合式API死磕。前端工程跑在8080端口，后端Spring Boot跑在8081，通过nginx做反向代理解决跨域，开发环境下用Vue CLI的proxy代理。

部署时，我用Docker Compose把MySQL、Redis、MinIO、后端jar包、前端Nginx五个容器编排起来，一键启动。Nginx里把/api前缀的请求转发到后端服务，同时托管前端静态文件。这样一个命令就能在任意Linux服务器上复现整个环境，写进部署文档里也很加分。

有一点必须提醒：系统里的文件上传功能一定要接对象存储（MinIO或OSS），不要往项目本地目录写文件。因为Docker容器一旦重建本地文件就丢了，而且Tomcat运行目录下的临时文件是不可控的。MinIO的接口兼容S3协议，SDK封装得很好，几行代码就能完成上传。我在做项目时把质检报告、商品图片、溯源凭证都交给了MinIO，存储和业务分离，省了很多事。

5. 核心业务场景的实现思路：预警、溯源、运力调度

5.1 供需预警模块的完整实现链路

前面讲了预警的计算模型，这节把完整实现链路串一遍。预警任务由@Scheduled定时触发，核心流程分四步：扫描商品→计算指标→判断阈值→生成预警。

用Java写一个定时任务，注意这里的逻辑要测试。第一步扫描所有在售商品列表，分页拉取避免一次撑爆内存。第二步对每个商品调用predictDailySales方法得到预测日销量。第三步用当前库存和在途补货量计算可供天数。第四步命中阈值则插入预警表，并通过WebSocket推送实时消息给前端。

完整代码示例：

@Component public class SupplyWarnTask { @Autowired private ProductService productService; @Autowired private WarnService warnService; @Autowired private WarnWebSocket webSocket; @Scheduled(cron = "0 0 2 * * ?") public void checkSupplyWarning() { List<Product> products = productService.listAllEffective(); for (Product product : products) { BigDecimal dailySales = warnService.predictDailySales(product.getId()); if (dailySales.compareTo(BigDecimal.ZERO) <= 0) { continue; // 无销量数据的产品跳过 } BigDecimal stock = warnService.getCurrentStock(product.getId()); BigDecimal transit = warnService.getTransitStock(product.getId()); BigDecimal availableDays = stock.add(transit).divide(dailySales, 2, RoundingMode.HALF_UP); WarnRule rule = warnService.getRule(product.getCategoryId()); if (availableDays.compareTo(rule.getShortageThreshold()) < 0) { WarnRecord warn = warnService.createWarn(product.getId(), product.getName(), "缺货风险", "预计可供天数只剩 " + availableDays + " 天"); webSocket.pushToAdmin(warn); } if (availableDays.compareTo(rule.getOverStockThreshold()) > 0 && product.getShelfLifeDays() <= rule.getPerishableDays()) { WarnRecord warn = warnService.createWarn(product.getId(), product.getName(), "积压风险", "预计可供天数达 " + availableDays + " 天，注意临期报损"); webSocket.pushToAdmin(warn); } } } }

给一个真实的模拟数据验证一下逻辑：某超市西红柿近7天加权日均销量约200公斤，当前库存400公斤，在途订单120公斤，则预计可供天数=(400+120)/200=2.6天。如果补货前置周期是4天，系统必然触发缺货预警。每天凌晨2点跑完任务后，管理员早上打开系统就能看到预警，点击预警一键生成采购申请单，采购审核后定向发布给产地端。这条链路非常贴合疫情期间的实际操作——先预测缺口，再定向组织货源，避免盲目抢菜和产地滞销同时发生。

5.2 溯源模块的低成本落地方式

说到农产品溯源，很多人第一反应是区块链、物联网设备、二维码标签，高级但不好落地。我的做法更务实：不做硬件，聚焦信息链闭合。

每一批农产品从产地上报开始就有了唯一批次号，入库时录入质检结果，出库时绑定运单，运输全程由司机在APP（Web端化）上签到更新位置状态，消费者端用订单号反查批次信息即可看到产地、检测报告、采收日期、运输时长。

实现上不复杂：批次表存闭环所需的信息，溯源只需要按“订单→订单明细→批次→供应商/质检报告”的路径做联表查询。用一个专门的溯源页展示，每个环节配时间线样式，展示效果就不错。

@GetMapping("/trace/{orderNo}") public Result<TraceVO> trace(@PathVariable String orderNo) { // 1. 查订单 SupplyOrder order = orderService.getByOrderNo(orderNo); // 2. 查订单明细中的批次集合 List<Long> batchIds = orderItemService.getBatchIdsByOrderId(order.getId()); // 3. 按批次查产地、质检、物流节点信息 List<TraceNode> nodes = traceService.buildTraceChain(batchIds); return Result.success(new TraceVO(order.getOrderNo(), nodes)); }

建议在溯源页加上“报告下载”功能，把质检报告PDF从MinIO取出来返回给前端，方便社区团购团长在群里转发，增加消费者的信任感。这个功能在答辩演示时特别出彩——你点开一个订单，产地信息、检测报告、物流路径一一呈现，评委一眼就能看懂系统价值。

5.3 运力调度的简化但可用方案

完整意义上的智能调度需要路径规划算法，但对毕设来说，把分配逻辑做成“规则引擎”形式就足够有说服力了。

车辆表维护运力档案（车型、载重、当前状态、空闲时间段）。生成运输任务时，调用分配规则：先按时间窗口过滤可用车辆，再按载重量匹配订单，若多笔订单路线相近可以拼车，状态不满足就标记为“待人工调度”。规则写在Service层，每一条用条件判断清晰列出，方便答辩时逐条解释。

```java public Vehicle dispatchOrder(SupplyOrder order) { List<Vehicle> availableVehicles = vehicleService.listAvailableByTime( order.getDeliveryDeadline()); // 按载重筛选 Vehicle matched = availableVehicles.stream() .filter(v -> v.getLoadCapacity().compareTo(order.getTotalQuantity()) >= 0) .min(Comparator.comparing(Vehicle::getLoadCapacity)) .orElse(null); if (matched == null) { // 没有单车可承运时尝试拆分配送 return dispatchBySplit(order, availableVehicles); } vehicleService.lockVehicle(matched.getId()); return matched; }

这个模块不复杂，但必须有。因为“有调度功能”和“没有调度功能”在系统完整度上是质的差距，哪怕只做最朴素的按载重优先匹配，也比让用户手动选车要专业得多。

6. 实打实的坑位记录：从开发到答辩的高频问题排查

6.1 第一个坑：Spring Boot版本选择导致的依赖爆炸

刚开始建项目时图新鲜，用了Spring Boot 3.0.5 + JDK 17，结果引入MyBatis-Plus时发现它当时最新版对Boot 3适配还不稳定，运行时一直报ClassNotFoundException: javax.persistence.*，排查半天才发现是包名从javax改成jakarta导致的。因为网上大多数解决方案还是针对Boot 2.x，整个过程非常消耗时间。

后来老老实实换回Spring Boot 2.7.18 + JDK 1.8，所有依赖一次通过。经验总结就是：毕设项目求稳不求新，生产上还没大规模验证的新版本会让你的开发过程变成填坑循环。

6.2 第二个坑：HandlerInterceptor拦截器对文件上传请求失效

我在做全局XSS防护时写了一个拦截器处理所有请求参数，结果死活过滤不到PDF文件上传接口。查了一天日志发现，文件上传的Content-Type是multipart/form-data，参数不在request的parameterMap里，而在输入流中。拦截器只能处理常规参数，文件流必须单独处理。

方案是在上传接口的Controller里手动校验文件内容。原本还研究过写一个全局过滤器把流读出来再传给拦截器链，但要多写不少代码。毕设项目里最稳妥的做法是：文件类型和大小在网关或Controller入口做校验就好，不要试图用拦截器统一处理，这是很多同学忽略的细节，面试官如果真的懂行，追问起来容易掉坑。

6.3 第三个坑：JAR包反编译学习

某天我想参考其他项目的一个用Spring Boot写的功能模块，找不到源码只拿到一个编译好的JAR包。当时想到将Spring Boot JAR反编译成项目来看。这个过程本身非常值得记录。

先解压JAR，里面的BOOT-INF/classes目录就是编译后的.class文件。反编译工具我用的是IDEA自带的反编译器，直接打开class文件就能看代码；也可以用命令行工具如CFR。

反编译出来的代码里函数名、注释全部丢失，变量名变成str1、str2，但至少能看清逻辑调用关系，对理解第三方项目的设计思路还是有帮助的。要注意反编译只能用于你拥有合法授权的项目，毕设场景下引用别人的代码要谨慎，涉嫌抄袭的代码不能直接抄进自己的论文查重系统——这是诚信红线。

6.4 小知识：JAR包里提取完整可重建的工程

想恢复成一个相对完整的可运行工程，操作也有讲究：

# 1. 解压JAR jar xf demo.jar # 2. 反编译核心class文件 # 用IDEA打开解压目录中的BOOT-INF/classes，IDEA会自动反编译 # 3. 从BOOT-INF/lib拷出第三方依赖 # 获取pom依赖坐标：用 mvn dependency:copy-dependencies 配合手动整理

如果是Gradle早期项目构建的Boot项目，可能在MODULE结构上略有差异，但思路一样。从JAR还原不是目的，目的是学习别人的分层设计。我在研究一个开源项目的代码时报错，找不到原始配置，最后靠反编译才知道是@ConfigurationProperties的字段命名问题——这类手段在调试阶段对排查问题确实很有帮助。

6.5 MyBatis-Plus的多租户字段连接问题

MySQL 8.0 连接参数里不加nullCatalogMeansCurrent=true，MyBatis-Plus在3.5.x版本下执行某些与information_schema相关的逻辑会拿到错误的结果。这个坑很难查，因为是底层框架内部的行为差异。加一行配置就能解决：

spring: datasource: url: jdbc:mysql://localhost:3306/agri_supply?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true&nullCatalogMeansCurrent=true

6.6 WebSocket鉴权这件事没有那么简单

预警推送用到了WebSocket，但WebSocket握手时的JWT校验是独立于HTTP请求的，Session里的用户信息不会自动注入。需要在握手拦截器里手动解析token：

public class WebSocketAuthInterceptor implements HandshakeInterceptor { @Override public boolean beforeHandshake(ServerHttpRequest request, ServerHttpResponse response, WebSocketHandler wsHandler, Map<String, Object> attributes) { String token = request.getURI().getQuery().split("token=")[1]; if (JwtUtil.verify(token)) { attributes.put("userId", JwtUtil.getUserId(token)); return true; } return false; } }

我最初没做这个校验，前端拿着无效token也能连上推送通道，还好在安全测试阶段发现了。毕设答辩时主动说出这个问题和解决方案，会让评委觉得你的安全意识是过关的。

7. 开发流程复盘：如何把毕设节奏控制得从容

最后复盘一下整个项目的开发节奏和心态问题。很多同学做毕设最大的问题不是技术不行，而是节奏失控——前期改需求改到天荒地老，后期熬夜补功能，写到一半推翻重来。

我的建议是：控制需求范围是毕设成功的第一要素。同样的题目，你可以做十个模块，也可以把四个模块做深做透。评委评估的标准不是模块数量，而是你有没有把一个核心业务逻辑讲明白、做扎实。所以我最终保底的核心闭环是“预测需求→生成采购→入出库管理→物流配送→最终追溯”，其余会员积分、优惠券、活动促销这些锦上添花的功能一概不做（做了也不会给你加多少分，但出了问题会让你多熬几个通宵）。

进度安排上，我给个参考：

• 前2周：需求分析、数据库设计、接口文档定义
• 第3~4周：搭建前后端骨架，跑通登录认证和主页面布局
• 第5~7周：核心模块——批次库存、订单双轨、出入库
• 第8~9周：预警模块、溯源模块、WebSocket推送
• 第10周：联调收尾，补Excel导入导出、部署上线

最想单独拿出来说的一点是：写代码之前先把数据库表设计定稿。我亲眼见过太多同学因为表结构改来改去，导致Mapper层代码推倒重写。表结构一旦定下来，业务字段明确，后续所有编码都是往既定管道里填内容，速度快且不会迷茫。

后端项目里我顺手还加了一些提升体验的小功能：Excel文件导入导出（导出每日订单报表给合作社对账）、用Spring Task定时清理超时未支付订单、统一异常处理返回标准Result结构体、操作日志记录关键业务变更。这些功能代码量不大，但让系统的完成度显得高出一个档次，写进毕业论文的工作量描述里也非常好看。

希望这篇复盘能让你少踩几个坑。如果你正准备做Spring Boot相关的毕设，别急着敲代码，先花一周时间把业务主链路画清楚，把所有表结构设计成你闭着眼都能默写出来的程度，后面的开发就是水到渠成的事。