企业官网建设流程全解析

每年到这个节点，一大批计算机专业的学生就开始被同一个问题折磨：毕业设计到底做什么？选“图书管理系统”太土，选“电商平台”太大，选得太偏又怕自己实现不了毕不了业。其实我这两年帮学弟学妹们做项目评审时发现，一个适配度很高、又不至于烂大街的选题是——基于SpringBoot的有机农产品销售系统。

这个题目妙在几个地方：它是“销售系统”但是垂直在“有机农产品”这个细分领域，比通用商城更有辨识度；它有用户端、商家端、管理端三个视角，足够支撑一篇毕设论文的功能模块图和用例分析；再加上SpringBoot这个简历里最常写的技术栈，整套源码做完还能直接变成面试作品。这篇东西我就围绕这个项目标题，把我实操里的完整构建思路、表结构设计、核心代码逻辑、避坑记录、答辩要点，全拆开讲清楚。不管是正在选毕设题目，还是已经选了准备动工，这篇都能帮你少走不少弯路。

1. 这个系统到底在做什么：业务边界与角色拆解

先说结论：这个系统不是要复刻一个京东或者淘宝，它的定位是“面向特定人群的农产品垂直电商平台”。因为是有机农产品，天然带产地、认证、溯源这类属性，系统重心要从“怎么把商品卖出去”扩展到“怎么让消费者买得放心”，这决定了你的功能清单和数据模型都跟普通商城不太一样。

1.1 系统的三条核心业务线

我从实际项目里理出来，以下三条线是必须走的：

• 商品浏览与选购线：首页轮播图、商品分类、商品详情、加入购物车、提交订单、模拟支付。这是电商系统的基础骨架，少了它就不叫销售系统。
• 溯源与信任线：有机农产品的卖点在于安全，系统需要给每个商品挂上产地、种植/养殖记录、检测报告、认证证书。消费者的下单价里，很大一部分买的是“我能看到它从哪来”。
• 管理与配送线：后台管理商品分类、上下架、订单处理、发货录入、用户管理；商家端则是维护自己的商品和库存，处理来自用户的订单。

如果一个学生能把这三条线完整落地，并且用文字把每条线的前后关系讲清楚，答辩时老师很难问倒你。

1.2 三类角色与权限边界

系统我建议做成三种角色登录：

权限控制在SpringBoot里就是一顿拦截器或者Spring Security的事情，但核心思想要明确：用户只能碰自己的订单，供货商只能动自己的商品，管理员可以看全部。后面我会给出非常清爽的实现方式。

1.3 从浏览到收货的完整流程

动手写代码之前，先把这条链路走一遍：

1. 用户浏览分类/搜索商品，点进详情页看“生产记录”“检测证书”；
2. 加购多个商品，进入购物车，勾选、提交订单；
3. 选择收货地址（或者新增地址），生成订单，此时订单状态为“待支付”；
4. 调用支付宝沙箱或微信H5模拟支付（毕设阶段也可以做成“模拟支付”按钮）；
5. 支付成功后状态变为“待发货”，供货商在后台看到订单，发货并填写物流单号；
6. 状态变为“待收货”，用户确认收货后进入“已完成”，可进行商品评价。

这套流程清晰、闭环，也够撑起论文里的“业务流程图”“时序图”。

2. 技术选型的取舍逻辑：为什么是SpringBoot+MyBatis Plus+Vue

说实话，现在做Java毕设，技术栈几乎没有第二种主流组合。但选型这件事不只是“别人都用”，你得能说出为什么，答辩老师问一句“你怎么考虑技术选型的”，答得有理有据就是加分项。

2.1 后端：SpringBoot是效率与稳定的平衡点

SpringBoot省去了Spring MVC时代大量XML配置，内置Tomcat，打好jar包就能跑，非常适合学生的开发节奏。另外一个现实因素是：招聘JD上的Java岗位基本都写“熟悉SpringBoot”，这个项目做完以后，简历上“项目技术栈”一栏写SpringBoot是完全拿得出手的。

版本选择上，我用的是SpringBoot 2.7.x。为什么不推荐3.x？因为3.x基于Jakarta EE，很多网上旧教程的代码直接粘贴会编译报错，对毕设党来说没必要在这个节骨眼上折腾兼容性。JDK用8或者11，稳妥。

2.2 数据访问层：MyBatis Plus，专治CRUD

热词里有条很应景：springboot + mybatis 当表不存在自动建表。这个话题我后面专门讲，先说为什么选MyBatis Plus。

MyBatis Plus是MyBatis的增强包，单表CRUD不需要手写SQL，继承一个BaseMapper<T>接口就自带增删改查和分页。对于毕设这种需要快速落地功能、时间紧张的项目，效率提升极其明显。而且它提供了LambdaQueryWrapper这种链式条件构造器，写条件查询非常直观：

LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Product::getCategoryId, categoryId) .like(StringUtils.hasText(keyword), Product::getProductName, keyword) .orderByDesc(Product::getStock); List<Product> list = productMapper.selectList(wrapper);

这段代码比手写XML里的动态SQL容易理解太多，而且答辩的时候你可以直接说“基于MyBatis Plus的条件构造器实现了多条件检索”。

2.3 前端：Vue2/3 + Element UI，前后端分离还是非分离？

这里有个岔路口。如果你前后端能力均衡，建议用Vue3 + Vite + Pinia + Element Plus做一套前后端分离的页面；如果你更想把精力放在后端逻辑上，也可以用Thymeleaf模板引擎实现服务端渲染。

我的个人建议是：优先Vue前后端分离。原因有三：

• 毕设源码本身更完整，能体现“前后端联调”的能力；
• 热词里也有“springboot vue前后端分离”，说明这是当前主流预期；
• 以后写简历项目，前后端分离的项目描述比服务端渲染更贴近企业项目形态。

但要注意一点：前端用Vue的话，后端就必须把跨域配置好，然后接口文档（或者说接口命名规范）要提前定义清楚，不然前端开发一天，后端联调三天。

2.4 认证与权限：JWT还是Session？

老的SSM项目通常用Session，SpringBoot项目我建议直接用JWT。JWT把用户身份信息加密签发一个token，前端每次请求在请求头里带着Authorization: Bearer <token>，后端用一个拦截器解析验签，完美契合前后端分离场景。

JWT的好处不用多讲，无状态、便于横向扩展。答辩时老师如果追问“JWT和Session有什么区别”，你可以从存储位置、跨域表现、分布式友好度三个角度展开。

3. 数据库设计：从“卖菜”业务里拆出十张核心表

数据库是毕设评分中的一个重要维度。很多同学喜欢堆表，显得功能多，但其实更重要的是“表结构符合业务逻辑、字段命名规范、关联关系清晰”。下面是我在这个项目里实际用到的核心表设计，供你直接参考。

3.1 用户、角色与地址表

用户表不需要跟角色表做多对多，毕设阶段用字段区分角色即可：

CREATE TABLE `user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL COMMENT '登录名', `password` varchar(100) NOT NULL COMMENT 'BCrypt加密后的密码', `nickname` varchar(50) DEFAULT NULL, `phone` varchar(20) DEFAULT NULL, `avatar` varchar(255) DEFAULT NULL, `role` tinyint(4) NOT NULL DEFAULT '2' COMMENT '0-管理员 1-供货商 2-普通用户', `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '1-正常 0-禁用', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

密码存BCrypt加密后的串，这个在答辩时可以直接讲“项目采用了Spring Security自带的BCryptPasswordEncoder对用户密码做哈希存储，避免明文落库”。

收货地址表针对用户多次下单的需求，设置一个is_default字段，下单时优先取默认地址：

CREATE TABLE `address` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` bigint(20) NOT NULL, `receiver_name` varchar(30) NOT NULL, `receiver_phone` varchar(20) NOT NULL, `province` varchar(30) DEFAULT NULL, `city` varchar(30) DEFAULT NULL, `district` varchar(30) DEFAULT NULL, `detail` varchar(255) NOT NULL, `is_default` tinyint(1) DEFAULT '0', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

3.2 分类、商品与溯源信息表

商品分类表很简单，就不贴SQL了，重点看商品表怎么设计。农产品跟数码产品不一样，它是非标品，同一种蔬菜可能有不同产地、不同采摘时间、不同规格，所以库存和价格要落到“SKU”粒度的商品规格上，而不是简单的“商品表一个价格字段”。

CREATE TABLE `product` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `category_id` bigint(20) NOT NULL COMMENT '分类ID', `supplier_id` bigint(20) NOT NULL COMMENT '供货商用户ID', `product_name` varchar(100) NOT NULL, `subtitle` varchar(255) DEFAULT NULL COMMENT '卖点副标题', `cover_image` varchar(255) DEFAULT NULL COMMENT '主图URL', `detail_images` text COMMENT '详情图，逗号分隔', `origin_place` varchar(50) DEFAULT NULL COMMENT '产地', `certification` varchar(255) DEFAULT NULL COMMENT '认证信息，如有机证书编号', `price` decimal(10,2) NOT NULL COMMENT '默认展示价', `stock` int(11) DEFAULT '0' COMMENT '总库存', `sales_count` int(11) DEFAULT '0' COMMENT '销量', `status` tinyint(4) DEFAULT '1' COMMENT '0-下架 1-上架 2-待审核', `is_recommend` tinyint(1) DEFAULT '0' COMMENT '首页推荐', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

溯源信息表是这个项目的灵魂。一张产品对应多条溯源记录，按时间线给它做节点展示：

CREATE TABLE `trace_record` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `product_id` bigint(20) NOT NULL, `stage_name` varchar(50) NOT NULL COMMENT '阶段：种植/施肥/采摘/检测/运输', `record_desc` varchar(500) DEFAULT NULL, `record_time` datetime DEFAULT NULL, `operator` varchar(30) DEFAULT NULL, `image_url` varchar(255) DEFAULT NULL COMMENT '现场照片/单据照片', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

用户点开商品详情页，前端拉取trace_record列表，按record_time升序渲染成一条时间线，就是非常直观的“溯源可视化”。这个功能不需要任何高深技术，但展示效果好、论文里有图、答辩有的讲，性价比极高。

3.3 订单主表、订单明细表与购物车表

订单表的设计要考虑“一单多品”，所以拆成主表和明细表：

-- 订单主表 CREATE TABLE `orders` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '订单编号，用时间戳+随机数生成', `user_id` bigint(20) NOT NULL, `supplier_id` bigint(20) NOT NULL COMMENT '订单归属供货商（简化版，一单一个供货商）', `total_amount` decimal(10,2) NOT NULL COMMENT '商品总金额', `freight_amount` decimal(10,2) DEFAULT '0.00' COMMENT '运费', `pay_amount` decimal(10,2) NOT NULL COMMENT '实付金额', `pay_type` tinyint(4) DEFAULT '1' COMMENT '1-在线支付（模拟） 2-货到付款', `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0-待支付 1-待发货 2-待收货 3-已完成 4-已取消', `receiver_name` varchar(30) NOT NULL, `receiver_phone` varchar(20) NOT NULL, `receiver_detail` varchar(255) NOT NULL, `delivery_company` varchar(30) DEFAULT NULL, `delivery_no` varchar(50) DEFAULT NULL, `create_time` datetime DEFAULT CURRENT_TIMESTAMP, `pay_time` datetime DEFAULT NULL, `delivery_time` datetime DEFAULT NULL, `finish_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 订单明细表 CREATE TABLE `order_item` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `order_id` bigint(20) NOT NULL, `product_id` bigint(20) NOT NULL, `product_name` varchar(100) NOT NULL, `product_image` varchar(255) DEFAULT NULL, `price` decimal(10,2) NOT NULL COMMENT '下单时快照价格', `quantity` int(11) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

注意order_item里的product_name、product_image、price这三个字段，是典型的“冗余字段设计”。订单生成后商品如果再改名、改价，订单里保存的必须还是用户下单那一刻的信息，不能去关联外键实时取值。这个细节我专门在答辩加分点里再提一次，因为它是区分“课程设计思维”和“工程思维”的重要标志。

购物车表就比较简单，一个用户ID、一个商品ID、一个数量、一个勾选状态，就能满足绝大多数需求。

4. 核心功能代码是这样落地的：购物车、订单状态与溯源时间线

光有数据库设计不够，关键功能代码逻辑要能直接写出来。我在这个部分挑三个最有代表性的模块，把核心思路和关键代码都贴出来。

4.1 购物车的加购与数量校验

购物车最容易踩的坑是“并发超卖”——用户加购的时候库存够，提交订单的时候库存已经被买走了。我们在加购接口里就做一个查询校验：

@Override @Transactional(rollbackFor = Exception.class) public Result addCart(CartAddDTO dto, Long userId) { Product product = productMapper.selectById(dto.getProductId()); if (product == null || product.getStatus() != 1) { return Result.error("商品不存在或已下架"); } // 当前购物车已有数量 + 新增数量 不能大于库存 Integer existCount = cartMapper.selectCountByUserAndProduct(userId, dto.getProductId()); if (existCount + dto.getQuantity() > product.getStock()) { return Result.error("库存不足，当前剩余" + product.getStock() + "件"); } Cart cart = new Cart(); cart.setUserId(userId); cart.setProductId(dto.getProductId()); cart.setQuantity(dto.getQuantity()); cart.setChecked(1); cartMapper.insertOrUpdate(cart); return Result.success(); }

注意这里用了@Transactional，如果后续逻辑里还要锁定库存、写入日志等操作，可以扩展到同一个事务里。insertOrUpdate可以用数据库的ON DUPLICATE KEY UPDATE来实现，也可以先查再插。

4.2 订单状态的推进与状态机思想

订单状态字段我在表设计里定义了5个值：0-待支付、1-待发货、2-待收货、3-已完成、4-已取消。代码层面不建议到处散落if (status == 1) { xxx }，更优雅的做法是定义一个状态流转的校验工具：

public enum OrderStatus { PENDING_PAY(0, "待支付"), PENDING_DELIVERY(1, "待发货"), PENDING_RECEIVE(2, "待收货"), FINISHED(3, "已完成"), CANCELLED(4, "已取消"); public static boolean canTransit(Integer current, Integer target) { if (current == null || target == null) return false; if (current == 0 && (target == 1 || target == 4)) return true; // 待支付 -> 已支付/取消 if (current == 1 && target == 2) return true; // 待发货 -> 待收货 if (current == 2 && target == 3) return true; // 待收货 -> 已完成 return false; } }

这个设计答辩时非常加分。你可以直接说“项目对订单状态采用有限状态机模型，定义合法流转路径，避免订单状态被非法篡改”。简单、优雅、有效。

4.3 溯源信息的时间线组装

溯源信息后端代码不难，但前端展示方式决定体验。我的做法是后端直接返回按时间升序排列的记录，前端渲染成时间线：

public List<TraceVO> getTraceList(Long productId) { LambdaQueryWrapper<TraceRecord> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(TraceRecord::getProductId, productId) .orderByAsc(TraceRecord::getRecordTime); List<TraceRecord> list = traceMapper.selectList(wrapper); return list.stream().map(record -> { TraceVO vo = new TraceVO(); BeanUtils.copyProperties(record, vo); return vo; }).collect(Collectors.toList()); }

前端用Element UI的el-timeline组件，一行<el-timeline-item>就是一个溯源节点，放上时间、阶段、描述、图片，一个像模像样的溯源模块就完成了。这块的成本极低，但它是这个毕设区别于普通商城的最大差异化卖点。

4.4 模拟支付还是真实支付？我的建议

真实接入支付宝或微信支付需要企业资质，学生个人申请不下来。市面上常见的做法是使用支付宝沙箱环境，但这需要配置一堆密钥，对毕设来说偏复杂。

我更建议做一个“模拟支付收银台”：用户点击去支付，弹出一个支付确认弹窗，展示订单号和金额，点击“确认支付”后直接调接口把订单状态从0改为1。然后在论文里写清楚：“系统预留了支付接口，生产环境可替换为支付宝/微信SDK调用”。

这套做法对答辩来说是安全的，因为毕设重点在前后台交易流程的完整性，支付网关本身反而是最容易从简的部分。

5. 从零搭建到部署，我替你踩过的六个坑

这个部分全是我亲手踩过的坑，网上很多教程不会写。提前排掉它们，你的开发过程会顺很多。

5.1 IDEA和SpringBoot 3的兼容摩擦

如果你用的是新版IDEA，自带Spring Initializr默认生成的是SpringBoot 3.x版本。很多老教程里的javax.*包路径在SpringBoot 3里已经换成jakarta.*，数据库驱动配置也不一样。如果你还没开始写，我劝你创建项目时把SpringBoot版本切到2.7.x，否则网上搜到的资料一半都是无效的。

创建项目时如果IDEA一直卡在连接Spring Initializr，可以直接把连接地址改成阿里云镜像：https://start.aliyun.com，这个坑在热词里很多人都遇到过。

5.2 SpringBoot + MyBatis Plus 当表不存在自动建表

热词里有这条，展开说一下。MyBatis Plus官方没有“自动建表”功能，但它提供了一个叫p6spy的SQL打印插件，和SpringBoot自带的ddl-auto一点关系都没有。很多人在网上看到“表不存在自动建表”，实际是指MyBatis Plus的FieldFill字段自动填充，或者是指用一个SchemaInitializer工具类在启动时执行schema.sql。

如果你想在项目启动时自动建表，最靠谱的方式是SpringBoot的sql.init配置：

spring: sql: init: mode: always schema-locations: classpath:sql/schema.sql

注意把schema.sql里的建表语句写成CREATE TABLE IF NOT EXISTS，这样每次启动都是幂等操作。这个在设计文档里提一句，显得你对项目初始化过程有通盘考虑。

5.3 跨域配置：前端Vue调后端接口报CORS

前后端分离必然遇到跨域。我直接用WebMvcConfigurer统一配置：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

要在JWT拦截器之前就生效，否则带token的请求会被拦在CORS之外，前后端联调时诊断起来很头痛。

5.4 文件上传：商品图片存哪里最省心

本地磁盘存储图片是毕设的标准做法，但要注意路径映射。上传路径如果用绝对路径D:/upload/，部署到Linux服务器上就要改代码。我会把路径配置放到application.yml里，然后通过配置类暴露成静态资源映射：

upload: path: ./upload/

5.5 Docker部署前后端分离的注意点

热词里有“docker部署springboot项目”，现在很多学校要求部署到服务器上演示。前后端分离的部署我有两点经验：

• 后端镜像不要用java:8这种老镜像，用openjdk:8-jdk-alpine更省体积；
• 前端用Nginx托管打包后的dist目录，并且要在Nginx配置里把后端API反向代理到宿主机端口：

  location /api/ { proxy_pass http://backend-container:8080/api/; }

  这样前端代码里所有请求都走相对路径/api/xxx，不需要写死服务器IP，迁移环境时省事很多。

5.6 JWT拦截器放行路径列表

加了JWT拦截器之后最大的坑：登录接口、注册接口、商品列表接口、商品详情接口、图片访问路径全部被拦截，导致前端白屏。解决办法是准备一份放行配置：

registry.addInterceptor(jwtInterceptor) .addPathPatterns("/**") .excludePathPatterns( "/api/user/login", "/api/user/register", "/api/product/**", "/upload/**", "/error" );

我的经验是先把放行路径想全，再上线，不然调试阶段会被401折腾到怀疑人生。

6. 答辩怎么把“管理系统”讲成“交易系统”

很多学生做完项目很心虚，觉得这不就是一套CRUD嘛。其实换个讲法，整个格局就上去了。

6.1 用“业务闭环”代替“功能堆砌”

千万不要上来就说“我做了用户模块、商品模块、订单模块、购物车模块”，这样的介绍等于把菜单念了一遍。正确的思路是讲链条：

“我这个系统是面向有机农产品消费场景的垂直电商平台。用户端从商品筛选、加购下单、在线支付、物流跟踪到确认收货，形成完整的交易闭环。同时引入溯源模块，商品详情可查看产地记录和检测报告，让消费者从源头建立信任。管理端覆盖了用户管理、商品审核、订单调度和数据统计，保证平台运转的规范性。”

这段话里没有任何深奥的技术，但它传达的信息是“我理解业务”，这在毕设答辩里比“我会写代码”更能拿高分。

6.2 高频追问Top 5

提前准备下面五个问题的标准回答：

• Q1：为什么用MyBatis Plus而不用MyBatis？
  回答：MyBatis Plus在单表操作上大幅提高了开发效率，同时仍然支持手写XML处理复杂关联查询，是开发效率与可控性的折中。

• Q2：订单金额怎么保证不出现精度丢失？
  回答：所有金额字段使用DECIMAL(10,2)，Java侧用BigDecimal接收，避免double/float的浮点精度问题。

• Q3：搜索功能是SQL模糊查询还是全文检索？
  回答：毕设阶段采用MySQL的LIKE模糊查询，满足中小数据量场景；架构上预留了Elasticsearch替换的空间。

• Q4：库存超卖怎么处理？
  回答：下单时使用事务，在更新库存时使用乐观锁UPDATE product SET stock = stock - #{quantity} WHERE id = #{id} AND stock >= #{quantity}，通过受影响行数判断是否扣减成功。

• Q5：系统安全性做了哪些方面？
  回答：密码BCrypt加密存储、JWT身份校验、后台管理接口基于角色的访问控制、SQL使用预编译避免注入。

6.3 加分扩展方向

如果时间和精力允许，挑一个方向做个小亮点，答辩效果会更好：

• 用Quartz或Spring Task定时任务，每日凌晨自动关闭超过30分钟未支付的超时订单；
• 引入Redis缓存首页热门商品，降低数据库压力，并在论文里画一张缓存流程示意图；
• 用ECharts给管理员做一版销售走向折线图和各分类占比饼图，管理模块的档次瞬间提升。

这三个方向里，定时关单是性价比最高的，代码量不大，但能体现“你考虑到电商场景中的真实问题”。

最后再分享一个个人经验：毕设源码拿到手，哪怕你是直接下载的，也一定要自己亲手把核心模块（比如订单和溯源）的代码逐行读一遍，把表结构改了改，把类名换一换。不是说要你造假，而是答辩时老师一眼就能看出你有没有实际上手跑过。你把代码跑起来、把业务链路走通、把两三张核心表的关系讲明白，这个项目就是你自己的东西了。祝你这轮毕设顺利过关。