企业官网建设流程全解析

简介：这是一套面向高校计算机专业毕业设计的农产品商城与农资电商Java Web项目，适合正在准备毕设、需要完整可运行案例的学生及Java初学者参考。项目基于Struts、Spring、JSP与JDBC开发，运行环境为Java 1.8、MySQL 5.7以上及Tomcat 8.5，支持IDEA或Eclipse导入。前台会员端涵盖注册登录、商品浏览、购物车、收藏、下单支付、公告查看、留言及个人信息管理；后台管理端包含类别、商品、会员、订单、退货、库存记录与盘点、销售统计、财务统计、系统公告、留言板及密码修改等模块，业务闭环较为完整。资源包共2004个文件，以js脚本、gif与png图片、html页面、jar依赖、jsp页面、class字节码及css样式为主，另含xml配置、java源码与sql脚本，压缩包约97.29MB，目录结构清晰。目前已有118人学习，可作为毕设选题、代码研读与二次开发的参考素材。

1. 农产品商城系统到底在做什么：从一份毕业设计选题说起

很多同学拿到「农产品商城系统农资电商商城系统java项目」这个题目时，第一反应是去搜现成的源码包，下载下来改个名字就交差。但真正做过答辩的人都知道，老师问的第一个问题往往不是「你用了什么框架」，而是「你的农产品和普通商品有什么不一样」。这个问题答不上来，后面讲再多 Spring Boot、MyBatis 都是空的。

农产品商城和农资电商商城，本质上是两个业务侧重点不同的系统。前者面向消费者卖生鲜、干货、粮油，核心痛点是季节性、产地溯源、按斤计价、冷链时效；后者面向农户卖种子、化肥、农药、农机，核心痛点是规格参数复杂、复购周期长、赊销记账、区域授权。把这两个揉在一个 Java 项目里做毕业设计，其实是个很聪明的选题——它逼着你去处理「同一套商品模型怎么兼容两种完全不同的交易逻辑」。

这篇笔记面向的是正在做计算机毕业设计、软件工程毕业设计的同学，也适合想拿一个完整 Java 项目练手的初级后端。我会按「业务建模 → 技术选型 → 核心模块落地 → 踩坑排查 → 进阶技巧」的顺序，把这类系统从零到能跑、能演示、能写进报告设计的完整路径讲清楚。不堆八股文，只讲能复现的东西。

2. 业务建模与技术选型：为什么不能照搬普通商城

2.1 农产品与农资的商品模型差异

普通电商的商品表通常是「SPU + SKU」两层，SKU 挂价格和库存。但农产品有个绕不开的问题：同一批次的价格会随行情浮动，且库存单位不统一。比如土豆按斤卖，但入库时按吨记录；农资里的化肥按袋卖，但一袋有 40kg、50kg 两种规格，还涉及生产批号和保质期。

我一般会这样设计商品域：

这张表不是让你照抄，而是提醒你：毕业设计里只要把「批次」和「双单位」这两个点讲透，就已经比 80% 的普通商城项目有深度了。答辩时老师听到「库存单位与销售单位分离」这种设计，基本会认可你确实思考过业务。

2.2 Java 技术栈怎么选才不翻车

网上关于 java 学习路线、java 后端完整成长路线的内容很多，但毕业设计不需要微服务全家桶。我的建议是单体 + 分层，理由很实际：你只有几个月时间，微服务带来的注册中心、网关、链路追踪只会让你在答辩前一周还在调 Nacos。

一套稳妥的选型：

• 后端：Spring Boot 2.7.x + MyBatis-Plus + MySQL 8.0 + Redis
• 权限：Spring Security + JWT，或者直接用 Sa-Token（更简单）
• 前端：Vue 3 + Element Plus，或者 Thymeleaf 做服务端渲染省事
• 部署：一台 2C4G 的云服务器，Nginx + Jar 包直接跑

# 创建项目骨架，用 Spring Initializr 的命令行方式 curl https://start.spring.io/starter.zip \ -d dependencies=web,mysql,redis,lombok,validation \ -d type=maven-project \ -d language=java \ -d bootVersion=2.7.18 \ -d groupId=com.example \ -d artifactId=agri-mall \ -o agri-mall.zip unzip agri-mall.zip -d agri-mall

这段命令的作用是生成一个带 Web、MySQL、Redis、Lombok、参数校验依赖的 Maven 项目。bootVersion选 2.7.18 是因为它和 JDK 8/11 兼容性最好，很多学校的机房环境还停留在 JDK 8，用 Spring Boot 3.x 会直接因为 JDK 17 要求而跑不起来。artifactId我写成 agri-mall，你可以改成自己的题目缩写。

提示：如果你的学校要求必须用 SSM（Spring + SpringMVC + MyBatis）而不是 Spring Boot，把依赖换成对应的 starter 即可，业务代码几乎不用改，只是多写几个 XML 配置文件。

2.3 数据库表设计的三个关键决策

第一，用户表要分角色。农产品商城有消费者、农户/合作社、平台运营；农资商城还有经销商、区域代理。用一张sys_user加role字段，再配user_role关联表，比建三张用户表好维护得多。

第二，订单表要能拆单。一个订单里既有农产品又有农资，发货仓库不同，必须支持子订单。我一般会建order_main和order_item，再加一个order_delivery记录物流。

第三，库存表要带批次。stock_batch表里存product_id、batch_no、production_date、expire_date、quantity、unit。扣减库存时按先进先出（FIFO）选批次，这个逻辑在答辩时是加分项。

-- 批次库存表核心结构 CREATE TABLE stock_batch ( id BIGINT PRIMARY KEY AUTO_INCREMENT, product_id BIGINT NOT NULL COMMENT '商品ID', batch_no VARCHAR(64) NOT NULL COMMENT '批次号/生产批号', production_date DATE COMMENT '生产日期', expire_date DATE COMMENT '过期日期', quantity DECIMAL(12,2) NOT NULL DEFAULT 0 COMMENT '库存数量', unit VARCHAR(16) NOT NULL COMMENT '库存单位', warehouse_id BIGINT COMMENT '仓库ID', status TINYINT DEFAULT 1 COMMENT '1正常 0冻结', INDEX idx_product_expire (product_id, expire_date) );

quantity用DECIMAL而不是INT，是因为农产品经常出现 0.5 斤、1.25 公斤这种小数。idx_product_expire这个联合索引是为了让「查某商品最近要过期的批次」这个查询走索引，临期预警定时任务会频繁用到它。

3. 核心模块落地：从商品上架到下单扣库存

3.1 商品发布接口与双单位换算

农产品上架时，运营填的是「销售单位」和「库存单位」的换算关系。比如 1 箱 = 10 斤，1 吨 = 2000 斤。这个换算系数必须存下来，否则下单扣库存时会对不上。

// 商品发布请求体，只保留关键字段 public class ProductPublishDTO { private String name; private Long categoryId; private String saleUnit; // 销售单位：斤 private String stockUnit; // 库存单位：吨 private BigDecimal conversionRate; // 1库存单位 = N销售单位 private BigDecimal salePrice; // 按销售单位计价 private List<BatchDTO> batches; } // 换算工具方法 public BigDecimal toStockQuantity(BigDecimal saleQty, BigDecimal rate) { if (rate == null || rate.compareTo(BigDecimal.ZERO) <= 0) { throw new BizException("换算系数不合法"); } // 销售数量 ÷ 换算系数 = 库存数量，保留3位小数 return saleQty.divide(rate, 3, RoundingMode.HALF_UP); }

conversionRate表示 1 个库存单位等于多少个销售单位。用户买 5 斤，换算系数是 2000（1吨=2000斤），那库存扣减就是 5/2000 = 0.0025 吨。divide的第三个参数指定保留 3 位小数，RoundingMode.HALF_UP是四舍五入。这里如果不指定精度，遇到除不尽的情况会直接抛ArithmeticException，这是很多人第一次写会翻车的地方。

3.2 下单流程与库存扣减的时序

下单不是简单 insert 一条订单就完事。正确的顺序是：校验库存 → 锁定库存 → 生成订单 → 支付后扣减 → 超时释放。锁定和扣减要分开，否则用户下单不付款，库存就被白白占死。

@Transactional(rollbackFor = Exception.class) public OrderVO createOrder(OrderCreateDTO dto) { // 1. 按FIFO选出可用批次并锁定 List<StockBatch> batches = stockBatchMapper.selectAvailableForUpdate(dto.getProductId()); BigDecimal need = toStockQuantity(dto.getSaleQty(), dto.getConversionRate()); for (StockBatch batch : batches) { if (need.compareTo(BigDecimal.ZERO) <= 0) break; BigDecimal lock = need.min(batch.getQuantity()); batch.setLockedQuantity(batch.getLockedQuantity().add(lock)); stockBatchMapper.updateById(batch); need = need.subtract(lock); } if (need.compareTo(BigDecimal.ZERO) > 0) { throw new BizException("库存不足"); } // 2. 生成订单主表和明细 OrderMain order = buildOrder(dto); orderMainMapper.insert(order); // 3. 写入锁定记录，设置30分钟过期 redisTemplate.opsForValue().set("order:lock:" + order.getId(), "1", 30, TimeUnit.MINUTES); return convert(order); }

selectAvailableForUpdate这个方法名里的ForUpdate表示 SQL 里带了FOR UPDATE行锁，防止并发下单超卖。lockedQuantity是锁定数量，和quantity分开存，支付成功后才真正扣quantity并释放锁。Redis 那个 key 是给定时任务扫的，30 分钟没支付就回滚锁定数量。这套逻辑在答辩时如果能画出时序图讲清楚，比背十道 java 面试题都有用。

3.3 农资赊销记账模块怎么做

农资电商和普通商城最大的区别就是赊销。农户春耕时拿货，秋收后结账，中间要记流水。这个模块不需要太复杂，一张credit_account记授信额度，一张credit_record记每笔赊账和还款。

CREATE TABLE credit_account ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, total_limit DECIMAL(12,2) COMMENT '授信总额', used_amount DECIMAL(12,2) DEFAULT 0 COMMENT '已用额度', status TINYINT DEFAULT 1, UNIQUE KEY uk_user (user_id) ); CREATE TABLE credit_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, order_id BIGINT, amount DECIMAL(12,2) COMMENT '正数赊账，负数还款', balance_after DECIMAL(12,2) COMMENT '变动后余额', create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

credit_record里的balance_after是冗余字段，但非常值得存。农户来对账时，你直接按时间列出每笔的余额，比每次去 sum 一遍所有记录快得多，也更直观。这是我在实际项目里被财务逼出来的习惯——流水表一定要存变动后余额。

4. 避坑与排查：那些答辩前夜才发现的坑

4.1 现象：本地跑得好好的，部署到服务器就 404

原因通常是打包方式或上下文路径不一致。Spring Boot 打成 Jar 包时，如果你在application.yml里配了server.servlet.context-path: /api，那所有接口都要带/api前缀，前端请求却没加。

解决：要么统一加前缀，要么干脆不配 context-path，用 Nginx 做反向代理转发。检查pom.xml里的<packaging>是不是 jar，启动命令用java -jar xxx.jar --spring.profiles.active=prod。

4.2 现象：下单时库存扣成负数

原因是没有加行锁或事务隔离级别不够。两个请求同时读到库存 10，各自扣 6，结果变成 -2。

解决：查询库存的 SQL 必须带FOR UPDATE，并且整个下单方法加@Transactional。更稳妥的做法是在UPDATE语句里加条件：UPDATE stock_batch SET quantity = quantity - ? WHERE id = ? AND quantity >= ?，用数据库的原子性兜底。

4.3 现象：中文商品名存进数据库变成问号

原因是数据库连接串没指定字符集，或者建表时用了latin1。

解决：JDBC URL 加useUnicode=true&characterEncoding=utf8，建库建表统一用utf8mb4。MySQL 8.0 默认是 utf8mb4，但如果你从旧项目导出的 SQL 脚本，很可能还是 utf8，需要手动改。

4.4 现象：定时任务释放超时订单，把已支付的也释放了

原因是状态判断没加锁，或者查询和更新之间有间隙。

解决：释放前先SELECT ... FOR UPDATE查订单状态，确认是「待支付」才释放。更新时用UPDATE order_main SET status = 'CANCELLED' WHERE id = ? AND status = 'PENDING'，靠status条件保证幂等。

4.5 现象：图片上传后前端显示裂图

原因是上传路径和静态资源映射路径不一致。Spring Boot 默认只映射classpath:/static/，你存到服务器/data/upload/目录，当然访问不到。

解决：写一个WebMvcConfigurer把本地目录映射成虚拟路径，或者干脆用对象存储。毕业设计里用本地映射就够了，但记得在报告里写清楚路径配置。

5. 进阶技巧：让毕业设计从「能跑」到「能拿优」

5.1 用策略模式处理多种促销规则

农产品有满减、第二件半价、产地直供折扣；农资有阶梯价、赊销价、老客户返利。如果全用 if-else 堆在订单计算里，代码会臭到你自己都不想看。用策略模式，每种促销一个实现类，通过@Component注册到 Map 里，下单时按类型取。

public interface PromotionStrategy { BigDecimal calculate(BigDecimal original, OrderContext ctx); String getType(); } @Component public class FullReduceStrategy implements PromotionStrategy { @Override public BigDecimal calculate(BigDecimal original, OrderContext ctx) { // 满100减10，可叠加 int times = original.divide(new BigDecimal("100"), 0, RoundingMode.DOWN).intValue(); return original.subtract(new BigDecimal(times * 10)); } @Override public String getType() { return "FULL_REDUCE"; } } // 工厂：启动时把所有策略收集到Map @Component public class PromotionFactory { private final Map<String, PromotionStrategy> map = new HashMap<>(); public PromotionFactory(List<PromotionStrategy> strategies) { strategies.forEach(s -> map.put(s.getType(), s)); } public PromotionStrategy get(String type) { return map.get(type); } }

PromotionFactory的构造函数注入List<PromotionStrategy>，Spring 会自动把所有实现类塞进来。这样新增一种促销只要加一个类，不用改任何已有代码。答辩时老师问「你怎么保证开闭原则」，这就是现成的答案。

5.2 溯源信息的轻量实现

农产品溯源不需要区块链，那是杀鸡用牛刀。用一张trace_record表，记录批次号、操作类型（播种/施肥/采收/质检）、操作时间、操作人、备注，前端按批次号查出来按时间线展示就够了。

这个表结构简单到十分钟能建完，但演示效果很好。你可以在报告里写「基于批次号的轻量级溯源方案」，比硬吹区块链可信得多。

5.3 答辩前一定要做的三件事

第一，准备一份数据初始化脚本。答辩现场不可能让你慢慢录商品，提前用 SQL 插 20 条农产品、10 条农资、几个测试账号，演示时直接登录下单。

第二，把核心接口用 Postman 或 Apifox 存成集合。万一前端现场崩了，你还能用接口工具演示后端逻辑，不至于全军覆没。

第三，想清楚三个「为什么」：为什么用这个技术栈、为什么这样设计表、为什么这个模块要这么实现。这三个问题答顺了，优秀率基本稳了。

我自己做第一个商城项目时，因为没准备初始化数据，答辩时现场录商品录了五分钟，老师脸都黑了。后来每次做演示项目，第一件事就是写data.sql。这个习惯帮我省了无数次尴尬，希望也能帮到你。

本文还有配套的精品资源，点击获取