企业官网建设流程全解析

简介：一套基于Java的绿色农产品销售与配送系统毕业设计源码包，面向计算机相关专业的学生与教师，尤其适合作为本科毕业设计、课程设计或课程大作业的选题参考，可帮助理解农产品从线上销售到线下配送的完整业务流程与实现方式。压缩包总共包含一百九十九个文件，大小约五点七四兆字节，内容覆盖前端页面、后端逻辑与数据库脚本，其中前端涉及Vue、JavaScript、Sass等样式与交互文件，后端提供Java源码与SQL数据库脚本，并整理有十八份项目开发文档，包括需求说明书、框架说明和质量评估材料，便于对照学习与二次开发。目前已有约一百八十人浏览学习，资源经过测试运行成功，可直接导入开发工具部署演示，也能在此架构上扩展模块，适合初学者进阶或作为项目初期演示版本。

1. 绿色农产品销售与配送毕设源码：这套 Java 系统包里到底有什么

拿到这套绿色农产品销售与配送源码包的时候，大多数人第一反应是找 README、导入数据库、点启动。但把它当成一个完整项目来拆，你会看到一条非常标准的 Java Web 课设主线：Servlet + JSP + MySQL，没有 Spring Boot 那层自动装配挡在面前，请求怎么走、权限怎么拦、订单和配送怎么衔接，每一行都能在答辩时讲出原理。这套源码包适合两类人：一类是正在做 Java 课设、实训或毕业设计的学生，不想只交一个“能登录的商品列表”；另一类是想快速搭一个农产品电商骨架、再往里面填自己业务的开发者。它能给你的是一整条从注册登录、浏览绿色农产品、加购物车、下单生成配送单的闭环，外加 sql 数据库脚本和项目开发文档，跑起来不是终点，能讲清楚才是本事。

2. 技术选型与项目骨架：Servlet/JSP 还是 Spring Boot，决定你的毕设好不好讲

拿到源码先别急着导依赖，先想明白一个事：为什么这套系统用经典 Java EE 三层架构，而不是 Spring Boot + MyBatis-Plus 一把梭。这个判断直接影响你后面怎么改、怎么答、怎么跟导师解释。

2.1 为什么毕设用经典三层架构更划算

绿色农产品的销售与配送听起来业务不复杂，但落到代码上，它需要同时覆盖用户登录态、商品库存、订单状态、配送单生成几条链路。如果用 Spring Boot + MyBatis-Plus，开发确实快，Mapper 接口一写、ServiceImpl 一补，CRUD 半小时做完。但问题也出在这里：答辩时导师问“你这个配送单生成的事务是怎么控制的”，你不能只回答“加了 @Transactional 注解”。

这套源码用 Servlet + JSP + DAO 的写法，反而是更适合学习和答辩的选择。每一层都看得到——JSP 负责页面渲染，Servlet 接收请求和做参数校验，Service 层写业务判断，DAO 层用原生 JDBC 操作 MySQL。数据怎么从浏览器落到数据表、再被查出来回显，没有任何黑匣子。

我一般会建议拿到源码后先画一张分层图，把三层架构和请求流向标清楚。这张图比代码本身更能帮你在答辩时稳住场面。如果导师硬要求用 Spring Boot 重写，也不要慌，DAO 层换成 MyBatis 的 Mapper，Service 层逻辑基本不用动，那又是一篇“基于 Spring Boot 的改造”素材。

对比一下两种方案的成本：

2.2 从请求到响应：一次下单操作在源码包里如何串起来

这套系统的请求流转很典型，我拆一个“用户提交订单”的链路给你看。用户在购物车页面点“提交订单”，浏览器向 CartServlet 发一个 POST 请求；CartServlet 拿到 session 里的用户 id 和购物车商品列表，先校验库存；校验通过后调 CartService 里的 createOrder 方法；CartService 里再分别调 OrderDao 和 ProductDao，往订单表插一条记录、扣掉商品库存；最后把订单 id 返回给 JSP 页面，跳转到配送信息填写页。

这个链路里，项目开发文档一般会把每一步的表单参数、Servlet 映射路径、跳转页面都列在需求说明书里。拿到源码后我建议你做一件事：把 web.xml 或者 @WebServlet 注解里的 URL 映射抄到一张纸上，然后用箭头把页面之间怎么跳的连起来。

下面是一个典型的 Servlet 处理骨架，注意看方法分工和参数获取方式：

@WebServlet("/order/submit") public class OrderServlet extends HttpServlet { private OrderService orderService = new OrderService(); @Override protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // 1. 从 session 里拿当前登录用户，拿不到说明会话过期 HttpSession session = request.getSession(false); if (session == null || session.getAttribute("user") == null) { response.sendRedirect(request.getContextPath() + "/login.jsp"); return; } // 2. 手动接收表单参数并做基础校验 String receiverName = request.getParameter("receiverName"); String receiverPhone = request.getParameter("receiverPhone"); String receiverAddress = request.getParameter("receiverAddress"); if (receiverName == null || receiverName.trim().isEmpty()) { request.setAttribute("errorMsg", "收货人姓名不能为空"); request.getRequestDispatcher("/order/confirm.jsp").forward(request, response); return; } // 3. 获取购物车数据，交给 Service 层处理 User user = (User) session.getAttribute("user"); Map<Integer, CartItem> cart = (Map<Integer, CartItem>) session.getAttribute("cart"); boolean success = orderService.createOrder(user.getId(), cart, receiverName, receiverPhone, receiverAddress); // ... 后续跳转 } }

这里有两个参数细节要记住。第一，request.getSession(false)里的false表示“如果没有会话就返回 null”，而不是帮你新建一个——很多翻车现场就是用了getSession(true)导致未登录用户也被创建了 session。第二，前端传上来的收货信息一定要在 Servlet 层做一次非空校验，JSP 里的前端校验是可以被绕过验证的，这是必答的安全一问。

2.3 项目目录拆解：源码包里的 src、WebContent、sql 脚本与开发文档怎么配合

一套典型的毕设源码包，解压之后通常是“源码 + 数据库脚本 + 文档”三大块。源码部分看两个目录。src 目录下按包名组织：com.xxx.entity放实体类，com.xxx.dao放数据库访问层，com.xxx.service放业务逻辑层，com.xxx.servlet放控制器。WebContent 目录下是页面资源，WEB-INF/web.xml是部署描述符，css/js/images放静态资源，jsp页面按功能拆成前台页面和后台管理页面。

green-agricultural-system/ ├── src/ │ ├── com/edu/entity/ # User, Product, Order, OrderItem, Delivery │ ├── com/edu/dao/ # 各实体对应的 DAO 接口与实现 │ ├── com/edu/service/ # 业务逻辑：登录、购物车、订单、配送 │ └── com/edu/servlet/ # 控制层：UserServlet, ProductServlet, OrderServlet... ├── WebContent/ │ ├── index.jsp # 首页：绿色农产品列表 │ ├── product_detail.jsp # 商品详情 │ ├── cart.jsp # 购物车 │ ├── order_confirm.jsp # 订单确认 + 配送信息填写 │ ├── admin/ # 后台管理页面 │ └── WEB-INF/web.xml ├── sql/ │ └── green_food.sql # 建库建表 + 基础数据 └── 项目开发文档/ ├── 需求说明书.md └── 数据库设计说明书.md

这里我要多说一句：拿到源码第一步不是改代码，而是先读数据库设计说明书。它决定了你后面改业务要动哪些表。比如这套系统核心表是用户表、商品表、订单表、订单明细表和配送单表，配送单独成表，这意味着“销售”和“配送”是两个被独立设计的业务模块，后面加物流状态、配送员分配都有位置可放。

3. 数据库设计与 SQL 脚本：五张核心表把“绿色”和“配送”两个卖点落进数据结构

这个项目的名字里带了“绿色”和“配送”两个关键词。绿色体现在商品的品类字段和产地溯源信息上，配送体现在订单下单后生成独立配送单的流程上。搞懂表结构，你就搞懂了这套系统一半的架构。

3.1 E-R 关系：用户、商品、订单、配送单之间怎么连线

先画清楚实体关系，再动手改代码。这套系统至少有五个核心实体。用户和订单是一对多，一个用户能下多张订单；商品和订单是多对多，但通过订单明细表把多对多拆成两个一对多，一个订单含多个明细，一个明细对应一个商品；订单和配送单是一对一，下单成功后立刻生成一条配送记录，配送单里存收货人、地址、配送状态和预计送达时间。

为什么配送单独建表而不是直接塞在订单表里？因为配送环节需要记录物流状态流转：待接单、配送中、已签收，还可能要记录配送员或车辆信息。这些字段如果全放在订单表里，订单表会越来越膨胀，而且“销售”和“配送”两个模块的业务节奏不同，分表更利于后面扩展。如果导师问表设计亮点，这就是一个现成的回答角度。

3.2 核心建表 SQL：从商品表到配送单表

数据库脚本导入这件事，翻车率其实很高。最常见的问题就是字符集不对，页面显示问号。这套系统的 sql 脚本通常会把建库、建表和初始数据写在同一个文件里，导入时注意用 utf8mb4，而不是老的 utf8。MySQL 8.0 默认字符集是 utf8mb4，但如果脚本里写的是 latin1，导入照样乱码。

-- 建库，字符集必须用 utf8mb4，兼容表情符号和生僻农产品名 CREATE DATABASE IF NOT EXISTS green_food_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE green_food_db; -- 用户表：前台顾客和管理员共用，用 role 字段区分 CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT '用户ID', username VARCHAR(50) NOT NULL UNIQUE COMMENT '登录名', password VARCHAR(64) NOT NULL COMMENT '密码，建议存 MD5 或加盐哈希', role TINYINT NOT NULL DEFAULT 1 COMMENT '角色：1-顾客，2-管理员', phone VARCHAR(20), address VARCHAR(200), create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB COMMENT='用户表'; -- 商品表：绿色农产品的核心信息 CREATE TABLE t_product ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT '商品ID', product_name VARCHAR(100) NOT NULL COMMENT '商品名称，如"高山有机绿茶"', category VARCHAR(50) COMMENT '商品分类：蔬菜、水果、粮油、茶叶', origin_address VARCHAR(100) COMMENT '产地，体现"绿色"卖点', price DECIMAL(10,2) NOT NULL COMMENT '销售单价', stock INT NOT NULL DEFAULT 0 COMMENT '库存数量', description TEXT COMMENT '绿色认证与产品描述', image_path VARCHAR(255) COMMENT '商品图片路径', status TINYINT DEFAULT 1 COMMENT '上下架状态：1-上架，0-下架' ) ENGINE=InnoDB COMMENT='绿色农产品商品表'; -- 订单表：记录一次购买的总体信息 CREATE TABLE t_order ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT '订单ID', user_id INT NOT NULL COMMENT '下单用户ID', order_no VARCHAR(32) NOT NULL UNIQUE COMMENT '订单编号，可带日期前缀', total_price DECIMAL(10,2) NOT NULL COMMENT '订单总金额', status TINYINT NOT NULL DEFAULT 0 COMMENT '订单状态：0-待支付，1-已支付，2-已取消', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, pay_time DATETIME NULL, CONSTRAINT fk_order_user FOREIGN KEY (user_id) REFERENCES t_user(id) ) ENGINE=InnoDB COMMENT='订单表'; -- 订单明细表：把订单和商品的多对多拆开 CREATE TABLE t_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 '购买数量', CONSTRAINT fk_item_order FOREIGN KEY (order_id) REFERENCES t_order(id), CONSTRAINT fk_item_product FOREIGN KEY (product_id) REFERENCES t_product(id) ) ENGINE=InnoDB COMMENT='订单明细表'; -- 配送单表：销售与配送两个模块的衔接点 CREATE TABLE t_delivery ( id INT PRIMARY KEY AUTO_INCREMENT, order_id INT NOT NULL UNIQUE COMMENT '与订单一对一', receiver_name VARCHAR(50) NOT NULL COMMENT '收货人', receiver_phone VARCHAR(20) NOT NULL, receiver_address VARCHAR(200) NOT NULL, delivery_status TINYINT NOT NULL DEFAULT 0 COMMENT '配送状态：0-待接单，1-配送中，2-已签收', delivery_time DATETIME NULL COMMENT '实际送达时间', CONSTRAINT fk_delivery_order FOREIGN KEY (order_id) REFERENCES t_order(id) ) ENGINE=InnoDB COMMENT='配送单表';

上述建表逻辑里有三个细节值得说道。第一，t_order_item里冗余了product_name和price两个字段，这是个刻意设计——用户下单后商品改价或下架，订单明细不能跟着变，所以做了“快照”。第二，订单表和配送单表都挂着状态字段，后面代码里就是用数字去判断流程走向的。第三，表名统一加t_前缀，这是一些数据库设计文档里的规范，让表名和关键字（如 order）区分开，避免ORDER在 SQL 里的语义冲突。

3.3 状态字段设计：为什么订单状态和配送状态用 int 不用 char

看表结构你会发现，凡是状态字段都是 TINYINT 数字类型，注释里写明了每个数字代表什么。这是 Java Web 课设里一个容易被忽视但值得展开讲的设计决策。用int存状态，代码里就是一个switch或if判断；用char存状态（比如'PAID'、'CANCELED'），代码得先转换成枚举再判断，多一道工序，而且拼 SQL 时还要注意引号。

这个系统的订单状态流转一般是这样：用户确认订单后先置为“待支付”；支付成功后改成“已支付”；未支付前用户可以取消，取消后订单状态为“已取消”。配送单的状态独立流转：订单支付成功时插入一条“待接单”的配送记录，配送员操作后改为“配送中”，最后变成“已签收”。注意，订单里没有“待配送”之类的字段，配送的事情由配送单表单独管，业务边界清楚。

那么问题来了：如果用户下单后不支付，配送单会不会生成？看代码逻辑，正常设计是“已支付”才生成配送单，下单只生成订单记录。如果源码里下单同时生成配送单，说明作者没有区分支付和配货两个时间点，你可以把这个当作一个改进点写进论文里，属于真实的产品逻辑缺陷，不算鸡蛋里挑骨头。

4. 核心功能代码链路：从注册登录到配送单生成，每一步在 Java 层怎么实现

表结构定了，再看 Java 层怎么把这些表用起来。这一章我按业务主链路拆解：登录拦截、购物车、订单与配送单生成。这三块覆盖了这套系统八成以上的核心代码逻辑。

4.1 登录与 Session 拦截：Filter 过滤器的两种写法坑

几乎所有 Java Web 课设都需要一个“未登录用户不能访问购物车和订单页面”的过滤器。常见做法是写一个AuthFilter实现javax.servlet.Filter接口，在doFilter里判断 session 是否包含用户对象。如果没登录，重定向到登录页；如果已登录，放行继续走后续链路。

import javax.servlet.*; import javax.servlet.annotation.WebFilter; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.servlet.http.HttpSession; import java.io.IOException; @WebFilter("/*") public class AuthFilter implements Filter { @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req = (HttpServletRequest) request; HttpServletResponse resp = (HttpServletResponse) response; HttpSession session = req.getSession(false); // 白名单集合：登录页、注册页、首页和静态资源直接放行 String uri = req.getRequestURI(); String contextPath = req.getContextPath(); String path = uri.substring(contextPath.length()); boolean isPublicPage = path.equals("/login.jsp") || path.equals("/register.jsp") || path.equals("/index.jsp") || path.startsWith("/css/") || path.startsWith("/js/") || path.startsWith("/images/") || path.equals("/user/login") || path.equals("/user/register"); if (isPublicPage) { chain.doFilter(request, response); return; } // 私密资源：session 里没有 user 就拦住 if (session == null || session.getAttribute("user") == null) { resp.sendRedirect(contextPath + "/login.jsp"); return; } chain.doFilter(request, response); } }

这段代码的思路是维护一个白名单，把所有不需要登录就能访问的 URL 都列出来，然后对剩余路径做校验。两个容易踩的坑：一是@WebFilter("/*")会把静态资源一起拦截，所以白名单里必须包含/css/、/js/、/images/这些前缀，否则页面样式全丢；二是在被人直接传/WEB-INF/路径时，容器本身会拒绝访问，但如果你的 JSP 放在了WEB-INF外面，过滤器还得防止用户绕过登录直接访问原始 JSP 文件。另一种写法是给私密 JSP 加登录检查片段，但那太分散，不如一个 Filter 管全局，答辩时也更有“系统设计”的味道。

4.2 购物车实现：用 Session 装 Map 还是用数据库购物车表

购物车是该系统一个典型业务点，也是两种实现的岔路口。第一种常见做法：用 Session 里的Map<Integer, CartItem>当临时购物车，加购、删购物项、改数量都在内存里操作，点“提交订单”时一次性把数据落到订单表。第二种做法：建一张购物车表，用户每次加购都写库，提交订单时从库里读出来。

毕设源码里用 Session 存购物车更常见，因为它实现简单、演示效果好，而且不用考虑“用户关闭浏览器后购物车残留”的清理问题。但它在并发场景下会有丢数据风险，刷新页面丢购物车、长时间停留后 session 过期清空，这些都可以写成系统改进点。我给的判断标准是：如果项目文档强调“性能优化”，就用数据库购物车；如果强调“业务流程闭环”，Session 版本完全够用。

public class CartService { // 加购：把商品放进 Session 的 cartMap 里 public void addToCart(Product product, int quantity, HttpSession session) { // 从 Session 取出购物车，第一次访问时创建 Map<Integer, CartItem> cartMap = (Map<Integer, CartItem>) session.getAttribute("cart"); if (cartMap == null) { cartMap = new HashMap<>(); session.setAttribute("cart", cartMap); } // 如果购物车已有该商品，累加数量；否则新建一个条目 CartItem item = cartMap.get(product.getId()); if (item != null) { item.setQuantity(item.getQuantity() + quantity); } else { cartMap.put(product.getId(), new CartItem(product, quantity)); } } // 计算购物车总价 public double calculateTotal(Map<Integer, CartItem> cartMap) { double total = 0.0; if (cartMap == null) { return total; } for (CartItem item : cartMap.values()) { total += item.getProduct().getPrice() * item.getQuantity(); } return total; } }

这里有个 Java 集合层面的细节需要讲给答辩老师听：Map的 key 用商品 id，value 里同时存商品对象和数量。为什么不直接存数量？因为结算页面要展示商品名称、单价、图片，这些信息都来自Product对象。如果只存数量，每次渲染购物车都要重新查库，不划算。把整个Product对象放进CartItem，页面直接取属性即可，这是一个典型的以空间换时间的处理。

4.3 订单与配送单生成：库存扣减与状态机

生成订单是整套系统中事务性最强的一段逻辑。一次createOrder至少要完成：校验库存、插入订单表、批量插入订单明细、扣减库存、生成配送单。这五步必须“要么全成功，要么全失败”，这就是 ACID 里的原子性。经典三层架构里没有 Spring 帮忙管理事务，常用的方法是Connection手动控制：关闭自动提交，在 catch 块里rollback()，全部完成后commit()。

public class OrderService { private OrderDao orderDao = new OrderDao(); private ProductDao productDao = new ProductDao(); private DeliveryDao deliveryDao = new DeliveryDao(); private CartItemDao cartItemDao = new CartItemDao(); /** * core method * @param userId 当前登录用户ID * @param cartMap 购物车，key 为商品ID */ public boolean createOrder(int userId, Map<Integer, CartItem> cartMap, String receiverName, String receiverPhone, String receiverAddress) { // 获取数据库连接后手动管理事务，核心是 conn.setAutoCommit(false) Connection conn = null; try { conn = DBUtil.getConnection(); conn.setAutoCommit(false); // 1. 生成总订单，拿到新增订单ID double totalPrice = calculateTotal(cartMap); Order order = new Order(); order.setUserId(userId); order.setTotalPrice(totalPrice); order.setStatus(0); // 待支付 order.setOrderNo(generateOrderNo()); int orderId = orderDao.insert(conn, order); // 2. 遍历购物车，逐条插入明细并扣库存 for (CartItem item : cartMap.values()) { Product product = item.getProduct(); int quantity = item.getQuantity(); // 2.1 扣库存前再查一次库存，防止超卖 int stock = productDao.getStockById(conn, product.getId()); if (stock < quantity) { throw new RuntimeException("商品[" + product.getProductName() + "]库存不足"); } // 2.2 插入订单明细 cartItemDao.insert(conn, orderId, product, quantity); // 2.3 扣减库存，SQL里带 WHERE stock >= ? 更安全 int updated = productDao.deductStock(conn, product.getId(), quantity); if (updated == 0) { throw new RuntimeException("商品[" + product.getProductName() + "]库存扣减失败"); } } // 3. 生成配送单，状态为待接单(0) Delivery delivery = new Delivery(); delivery.setOrderId(orderId); delivery.setReceiverName(receiverName); delivery.setReceiverPhone(receiverPhone); delivery.setReceiverAddress(receiverAddress); delivery.setDeliveryStatus(0); deliveryDao.insert(conn, delivery); // 全流程结束，提交事务 conn.commit(); return true; } catch (Exception e) { // 出了问题整体回滚，库存和订单都不会留下半截数据 if (conn != null) { try { conn.rollback(); } catch (Exception ex) { ex.printStackTrace(); } } throw new RuntimeException("订单创建失败，已回滚：" + e.getMessage(), e); } finally { DBUtil.closeConnection(conn);; } } }

这里有几个关键手法值得截图保存。第一，扣库存的 SQL 写成UPDATE t_product SET stock = stock - ? WHERE id = ? AND stock >= ?，这会同时完成“校验 + 扣减”，省掉一次查询请求；第二，每次操作都传同一个Connection进去，保证所有 DAO 方法在同一个事务里；第三，订单编号建议拼接时间戳和随机数，比如20240601103000001，不能直接用自增 id 当订单号发给客户。这三个点任何一个能在答辩时主动讲出来，导师都会觉得你真正理解了业务落库的细节。

5. 部署与排查：把系统跑起来的全流程和四个高频翻车点

环境问题占毕设项目“跑不起来”原因的七成以上。这一章把从零到能访问首页的完整步骤理一遍，并提供一套排查办法。注意，很多教程会引导你装 SQL Server 2025 或者 Visual Studio Installer，那套工具链是 .NET 方向用的，这套绿色农产品系统连的是 MySQL，别装错方向。

5.1 环境准备：JDK、Tomcat、MySQL 的版本搭配与 Java 环境变量配置

这套源码的部署对版本有隐性要求，核心是 jakarta 命名空间的问题。JDK 8 配套 Tomcat 8.5 或 Tomcat 9，代码里的javax.servlet包能正常编译；如果你装的是新版 Tomcat 10+，Servlet 包名变成了jakarta.servlet，旧源码基本会报“找不到类”的编译错误。所以环境版本不是越新越好，而是要和源码匹配。

Java 环境变量配置是高频卡点，很多人的java -version能出结果，但 Tomcat 启动后报ClassNotFoundException，原因是JAVA_HOME没配对。标准做法是三个变量：新建JAVA_HOME指向 JDK 安装目录（注意别指到bin目录）；PATH里新增%JAVA_HOME%\bin；CLASSPATH配.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar。配置完最好在命令行里确认一次：

echo %JAVA_HOME% java -version javac -version

如果你装了多个 JDK，java -version显示的版本和JAVA_HOME不一致，多半是 PATH 里有一个更靠前的 Java 路径把你拉偏了。这时检查系统变量和用户变量里有没有残留的 JDK 路径，把多余的删掉。

5.2 SQL 导入与数据库连接配置：避免 2003、1045 和中文乱码

数据库脚本导入失败是另一个重灾区。打开sql/green_food.sql文件看第一行，通常会有CREATE DATABASE，那就没必要手动新建库，直接一行命令导入进去。如果源码包只给了建表语句没有建库语句，那就先手动建库再指定库名导入。

mysql -uroot -p --default-character-set=utf8mb4 < sql/green_food.sql

导入成功后，去改源码里的数据库连接配置。Java Web 项目里常见的写法是src/db.properties或src/jdbc.properties，内容大致如下：

jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/green_food_db?useUnicode=true&characterEncoding=utf8mb4&useSSL=false&serverTimezone=Asia/Shanghai jdbc.username=root jdbc.password=123456

三个参数说明：useUnicode=true&characterEncoding=utf8mb4保证写入库的中文不出乱码；serverTimezone=Asia/Shanghai是 MySQL 8.0 连接必须加的，否则时间字段会差 8 小时；useSSL=false是为了省掉本地连接的 SSL 握手报警告。密码不要写错，本地 MySQL 的 root 密码不是默认的。

如果你用 DBeaver 这类图形工具连数据库，连上之后发现看不到表，先检查左侧树里选中的 schema 是不是green_food_db，DBeaver 连 MySQL 有时会默认挂在别的库下，表和表都找错位置。

5.3 四个高频排查项：现象、原因、解决

500 错误 + ClassNotFoundException：驱动 jar 包没进 WEB-INF/lib。现象是 Tomcat 启动后访问任意带数据库操作的页面直接 500。原因多半是 MySQL 驱动 jar 放在了项目的构建路径里但没复制到WebContent/WEB-INF/lib目录。解决方法是把mysql-connector-java-x.x.x.jar拷贝进该目录并重新发布项目。

Could not open JDBC Connection for transaction 或 1045 Access denied。现象是服务能启动，但一操作数据库就报连接失败。原因基本是db.properties的密码或者账号不对。解决方法是先单独用命令行mysql -uroot -p123456验证凭据，再核对 properties 里是否多了空格，jdbc.password=123456等号后面多了空格是最隐蔽的翻车点。

HTTP 404：请求路径对不上。现象是点页面的按钮跳转 404。原因通常是 Servlet 上的 @WebServlet 注解路径和 JSP 里表单的 action 路径不一致，或者 web.xml 版本不匹配。解决办法是把@WebServlet("/product/list")的路径和页面里action="${pageContext.request.contextPath}/product/list"对齐，特别是不要漏掉request.getContextPath()。

中文乱码：页面显示问号或火星文。现象是数据库里的中文正常，但 JSP 页面显示乱码。原因有两条线：JSP 页面头部缺了<%@ page contentType="text/html;charset=UTF-8" %>，或者数据库连接串没带characterEncoding=utf8mb4。解决时还要检查 MySQL 端表结构和连接工具两边的字符集设置，运行SHOW VARIABLES LIKE 'character%';确认。

还有一个很现实的坑：启动 Tomcat 时提示端口被占用。遇到这种情况先在命令行查占用端口的进程，然后决定是换端口还是杀进程。

# Windows下查8080端口占用，并杀掉占用进程 netstat -ano | findstr :8080 taskkill /PID <进程号> /F

如果是你自己之前启动的 Tomcat 没关干净，直接去任务管理器把 java 进程结束掉比改端口更省事。端口问题的处理就一条原则：尽早解决，别硬等。

6. 把毕设源码变成自己的：二次开发切入点与答辩验收清单

源码跑通不是终点，重点是让它变成你能讲清楚、能展示亮点的作品。这里给出三个二次开发切入点和一份验收清单，照着做一遍就知道项目是不是真的没毛病。

切入点一：把支付环节做成闭环。这套源码多半是模拟支付——点一下“已支付”按钮就直接改订单状态。你可以接支付宝沙箱环境，在order_confirm.jsp页面生成支付二维码，支付回调里再更新订单状态为“已支付”。这个改动涉及支付接口对接、回调验签、状态幂等问题，是答辩时最能镇场的一块。切入点二：给商品补搜索和分页。农产品系统数据量不大，但你可以用 SQL 的LIMIT做分页，用LIKE做模糊搜索，再在页面上加一个按分类筛选的下拉框。切入点三：给配送管理加一个后台页面。管理员能看到所有配送单，按状态筛选，点击“配送完成”按钮更新delivery_status为已签收。这个功能直接用到你前面对配送单表的理解，比在用户端加功能更贴合系统名里的“配送系统”。

做完改动，验收别只点一遍流程，要按角色走完整链路：注册新用户（如果源码有注册功能）→ 苗木登录 → 加购两个商品 → 提交订单 → 模拟支付 → 去后台看到订单和配送单 → 修改配送状态 → 用户端看到订单状态变化。中间刻意制造异常场景：库存不足时下两倍数量的订单，看会不会报错；不登录直接访问购物车页面，看会不会被过滤器拦住。

这套系统真正的价值不在“能跑”，在于它的业务闭环恰好覆盖了 Java Web 的核心考点：Servlet 生命周期、Session 管理、Filter 过滤器、JDBC 事务、SQL 多表查询。把这些点一个一个吃透，这个项目放进简历，面试里被问 Java 八股时，你反而比那些只做过玩具 CRUD 的人更有话讲。

我做毕设时最亏的一件事，就是拿到源码后先改功能，后读文档，结果压着截稿日才发现自己加的需求和数据表设计对不上。希望你拿到这套绿色农产品销售与配送源码时，先花两小时把表结构和 Servlet 映射理清楚，再动手改第一个功能，后面会顺手很多。希望帮到你。

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