企业官网建设流程全解析

毕业设计选“电子商品销售系统”这个题目的人每年都不少，但能把整个过程做得明明白白、从选题到答辩都心里有数的，其实不多。我刚做完这套基于Spring Boot的电子商品销售系统，产品线覆盖电子产品、键盘鼠标耳机这类电子外设，从数据库设计到后端接口再到部署上线，全套走了一遍。这篇就把我的完整思路、技术选型理由、核心模块的实现细节、以及部署和答辩阶段容易踩的坑，一次性写清楚。

如果你正在准备Java毕设，或者打算用Spring Boot做一套电商类系统，这篇可以直接照着规划你的项目节奏。我尽量把每个决策背后的原因讲明白，不是只贴代码——毕竟毕设答辩时老师问得最多的就是“你为什么这么设计”。

1. 选这个题目的真实逻辑：难度适中、逻辑闭环、演示效果好

先说选题。很多同学在毕设选题时会陷入两个极端：要么选个太简单的学生管理系统，答辩时被老师说“工作量不够”；要么一开始就上微服务、分布式、消息队列，结果写到一半发现根本hold不住，代码越写越乱，最后连跑通都困难。

电子商品销售系统属于一个比较理想的中间档位。

1.1 为什么“电子商品+电子外设”这个细分方向有讲究

市面上很多毕设题目直接叫“网上商城系统”“电商系统”，范围太大，反而不好做。我选的是“电子产品、电子外设销售”，意味着商品类别天然是清晰的——手机、笔记本、键盘、鼠标、耳机、显示器等。这个细分带来的直接好处是：

• 数据模型好设计：商品分类很天然，不需要搞复杂的多级分类逻辑
• 业务规则清晰：外设类商品通常库存变化快、促销活动多，适合体现订单和库存模块的设计
• 演示效果直观：商品图片、价格、参数展示出来，视频演示和截图都很饱满，答辩加分

我当时还专门做了一份简单的市场调研，放在论文的开题部分，大意是“电子产品销售是电商中最活跃的品类，电子外设作为配套需求，用户购买频次高”。这句话本身不难写，但它在答辩时很能说明你选题是有依据的，不是随手挑一个。

1.2 这个题目的功能边界控制在哪个范围最稳妥

毕设最怕的是功能堆得太多，每个都做不深。我的建议是守好一条主线：围绕“商品—购物车—订单—支付—后台管理”这条完整闭环来做。

我实现的功能清单是这些：

• 前台用户模块：注册、登录、商品浏览、按分类筛选、商品详情、加入购物车、提交订单、模拟支付、查看个人订单
• 后台管理模块：管理员登录、商品管理、分类管理、订单管理（发货、取消）、用户管理、数据统计（简单柱状图，不是必须但很好加分）
• 公共模块：拦截器做登录校验、统一异常处理、文件上传（商品图片）、分页查询

这个边界的好处是：每一块都不难，但合在一起就是一套完整的电商交易流程。功能之间是强关联的，能讲出业务逻辑链条，而不是七个毫不相干的模块各做各的。

2. 技术栈选型和架构设计的取舍笔记

技术选型这块，我的核心原则是“主流、够用、能讲清楚”。Spring Boot作为主框架基本没悬念，围绕它的配套怎么搭，其实有几种不同路线。

2.1 视图层方案：为什么我选Thymeleaf而不是Vue前后端分离

现在很多教程都在推前后端分离：Spring Boot只做接口，前端用Vue或React。但毕设场景下，我必须说一句实在话：如果你的前端基础一般，又不想把时间耗在跨域、Token刷新、路由守卫这些非核心问题上，Thymeleaf服务端渲染反而是更稳的选择。

我的理由有这几点：

1. 开发效率高：后端写好Model传给模板，刷新浏览器就能看到效果，没有接口联调成本
2. 答辩好解释：老师看到的是一整套完整页面，而不是“前端调接口”的割裂结构
3. 部署简单：打成一个jar包扔服务器就跑，不用再单独部署Nginx和前端静态资源
4. 本质上还是主流技能：Spring Boot官方推荐模板引擎就是Thymeleaf，放在简历上不丢人

我见过一些同学选前后端分离，结果前端打包后的dist文件怎么配到Spring Boot里都搞不定，最后答辩前一天还在弄路由刷新404的问题。这个风险没必要在毕设阶段冒。

2.2 ORM框架：MyBatis-Plus带来的开发效率提升

持久层我选的是MyBatis-Plus——基于MyBatis做的增强工具，没有侵入性，最直观的优势是单表CRUD不用写SQL。

举个例子，用户表查询，如果用原生MyBatis要写SQL映射，但MyBatis-Plus直接：

User user = userMapper.selectById(userId); LambdaQueryWrapper<Order> wrapper = Wrappers.lambdaQuery(Order.class); wrapper.eq(Order::getUserId, userId).orderByDesc(Order::getCreateTime); List<Order> orderList = orderMapper.selectList(wrapper);

这种写法在写业务代码时省下大量时间。而且它分页插件做得很成熟，Page<Order> page = orderMapper.selectPage(...)一行搞定分页，不用自己拼LIMIT。

但注意，用MyBatis-Plus不等于不学SQL。订单统计、多表联查这类复杂查询我还是写的自定义SQL和@Select注解，答辩时老师让我手写一个多表关联查询我也能写出来。工具要会用，基本功也不能丢。

2.3 开发环境版本搭配建议

版本搭配这件事我踩过坑。一开始图省事用了最新版Spring Boot 3.x，结果发现它要求JDK 17，而且一些老版本的MyBatis-Plus适配有问题，网上搜到的很多解决方案都过时了。后来老老实实退回这一套组合，非常稳定：

这个搭配的好处是：JDK 8 + Spring Boot 2.x 这个组合文档极多、遇到问题搜一下就有答案，而且对电脑配置要求不高。毕设阶段稳定压倒一切。

3. 数据库设计：电商系统的表结构就是这么几张，但关系要对

数据库设计是答辩必问环节。我设计的时候参考了一些开源商城项目的做法，再针对电子产品外设的特点做了一点优化。整套系统一共8张核心表，不多不少，每张的存在都有明确用途。

3.1 核心表的字段设计和表关系梳理

我梳理一下这张表的设计逻辑：

• user（用户表）：主键、用户名、密码（MD5加密存储）、昵称、手机号、邮箱、注册时间。密码加密这个点答辩必问，不要明文存，我用的MD5加盐。虽然是老方案，但作为单机版毕设完全够用，讲清楚比存明文强一百倍。
• category（分类表）：分类ID、分类名、父级分类ID、排序字段。电子产品外设做二级分类：一级是“手机、电脑、外设”，外设下面挂“键盘、鼠标、耳机”。二级分类就够了，层级再深会增加树形查询的复杂度，没必要。
• product（商品表）：商品ID、商品名、副标题、分类ID（冗余分类名）、主图地址、原价、现价、库存、销量、上下架状态、商品详情描述。这里设计时的关键点是“分类名冗余”，查商品列表时少一次关联查询。商品详情用长文本（TEXT），存富文本内容。
• cart（购物车表）：ID、用户ID、商品ID、购买数量、加入时间。加了一个UNIQUE约束保证同一个用户同一款商品只有一条记录，如果重复加入就做数量累加。
• orders（订单表）：订单ID（用时间戳加随机数生成）、订单编号、用户ID、收货人、联系电话、收货地址、订单总金额、订单状态、下单时间、支付时间、发货时间。
• order_item（订单明细表）：ID、订单编号、商品ID、商品名快照、购买价格快照、购买数量、小计金额。为什么要有“快照”？因为商品价格和名称以后可能改，但订单生成时买的是什么、多少钱，必须永远不变，这才有对账依据。
• address（收货地址表）：ID、用户ID、收货人、电话、省市区、详细地址、是否默认地址。
• admin（管理员表）：管理员ID、账号、密码、姓名。后台登录用，功能很简单。

订单编号我设计的是yyyyMMddHHmmss + 5位随机数，在并发量不大的毕设项目里足够保证唯一性，而且看起来像真实订单号。答辩时我说了“订单号设计要满足唯一性和可读性要求”，老师点头。

3.2 两张关键的逻辑：订单表和订单明细表为什么要拆

很多同学不理解订单和订单明细为什么要拆成两张表。这里我重点解释一下。

如果一个订单包含三个商品，你往一张表里塞，会出现：订单的整体信息（收货人、总金额、状态）在三条记录里反复重复。这不仅浪费存储，更严重的是——如果用户修改了收货地址，你都得改三条；如果想查“订单总数”，还得先distinct订单号。

拆成两张表之后，orders表管订单头（一次交易），order_item表管订单行（这次交易买了哪些东西），这是标准的“头行结构”，在ERP、电商系统里是通用设计。答辩时如果老师不问你，你都可以主动提一句：这是借鉴了企业级订单系统的建模思路。

3.3 商品表设计里一个容易忽视的点：状态字段

商品表我设了status字段（0下架 1上架）和stock（库存）字段。这里的逻辑是：下架的商品在前台不能显示，但数据库中记录不能被删除——因为历史订单的明细快照需要指向它。同样的道理，用户删除订单也不是物理删除订单表记录，而是把订单状态改成“已取消”。

软删除（逻辑删除）这个概念在电商系统里是标配。MyBatis-Plus自带逻辑删除注解，在实体类字段上加@TableLogic就能实现响应式删除，这对答辩展示来说又是个加分项。

4. 核心业务逻辑拆解：下单、购物车、状态流转的实现思路

电商系统最核心的业务逻辑其实就是“加购—下单—支付”。这部分我逐个讲一下自己是怎么落地实现的，以及每种做法的取舍。

4.1 购物车的设计与实现：为什么选“保存商品ID+数量”而不是快照

购物车有两种设计思路：一种是存购物车快照，把商品名称、价格、图片都冗余存进去，好处是效率高，但坏处是如果用户加购了好几天没下单，商品价格变了，购物车显示的价格和商品页不一致，反而要写逻辑去更新。

我选的是存关联关系——cart表只保存用户ID、商品ID、数量。每次查询购物车时join商品表获取最新价格和库存：

// 核心查询逻辑：根据用户ID查购物车列表，同时关联商品信息 SELECT c.id AS cart_id, c.product_id, c.quantity, p.product_name, p.price, p.stock, p.image FROM cart c LEFT JOIN product p ON c.product_id = p.id WHERE c.user_id = #{userId}

购物车的数量上限我也做了限制，单品最大99件，防止用户误操作把数量加到几千导致下单时库存校验出问题。加购的接口同时做了商品存在性检查和上下架状态检查，商品下架之后不能加购。

这个小细节在答辩时可以讲：购物车不是简单的增删改查，而是要考虑商品状态和库存的有效性。

4.2 提交订单的核心流程：事务、库存校验、幂等

下单是整套系统技术含量最高的一部分。我梳理一下它的完整流程：

1. 获取购物车中的勾选商品（用户在前端选择要结算的条目）
2. 在Service层逐个校验商品状态和库存：商品必须上架、库存必须充足
3. 计算订单总金额（遍历商品，单价乘以数量累加，不直接信任前端传过来的金额）
4. 生成订单头记录和订单明细记录
5. 扣减库存
6. 清空对应的购物车条目
7. 返回订单编号

这些操作必须保证原子性——要么全部成功，要么全部回滚。我用的是Spring的声明式事务：

@Override @Transactional(rollbackFor = Exception.class) public String submitOrder(OrderSubmitDTO dto) { // 1. 校验库存 // 2. 保存订单头 // 3. 保存订单明细 // 4. 扣库存 // 5. 删购物车 return orderNo; }

这里有个典型的坑：库存扣减必须放在事务里，而且要拿出来单独校验。我在事务外面的第一行做了一次库存检查，但真正的扣减语句用SQL里的条件更新来保证安全：

UPDATE product SET stock = stock - #{quantity}, sales = sales + #{quantity} WHERE id = #{productId} AND stock >= #{quantity}

stock >= #{quantity}这个条件很关键，它保证不会出现超卖。如果更新影响行数为0，说明库存已经不够，直接抛异常回滚事务。这个写法是并发安全的，比“先查库存再更新”靠谱得多，也是一道经典的Java面试题相关知识点，答辩讲出来很有含金量。

关于防重复提交，我做了两层简单处理：前端按钮提交后置为不可用；后端生成订单编号时用“用户ID+时间戳”做唯一索引，如果同一用户同一秒内重复提交两次，第二次会被数据库唯一约束拦住。单机毕设做到这个程度足够应付，不需要上Redis分布式锁。

4.3 订单状态机的设计：状态流转清晰，避免随意跳转

订单状态我用一个Integer status字段表示：

状态机的核心思想是不允许任意跳转。比如待支付状态不可能直接跳到已发货，必须走完支付流程。我在每个状态变更的Service方法里都加了前置状态校验，如果状态不是预期值，直接抛异常提醒“订单状态异常”。

模拟支付的实现是：用户点了“去支付”，弹一个确认页，确认后走一个payOrder方法，把订单状态从0改成1，写入支付时间。不接真实支付宝微信支付接口（毕设没必要，涉及商户号申请很麻烦），但我会在论文里说明“生产环境可以在此处对接第三方支付接口”。

4.4 商品列表和搜索的缓存思考：简单项目也要有优化意识

这块我额外说一下。很多同学做商品列表也就是查数据库分页，但答辩老师可能会问“如果数据量大怎么办”。

我的实现里对商品分类列表加了一个本地缓存——用Spring Cache配合ConcurrentHashMap做了一层简单缓存，分类和商品热门榜单的缓存时间为5分钟。并且在代码里注释了“5分钟后过期，保证商品数据最终一致”。

这样做不是为了性能，主要是体现“我有性能思维”。答辩时被问到这个点，能顺势说出“生产环境会用Redis做分布式缓存”，显得有深度。毕设项目里有这个设计意识，比什么都是直接查库的“直球代码”品质感好很多。

5. 部署环节：从本地到服务器的完整流程和坑点记录

部署是毕设交付中最容易翻车的环节。很多同学开发时window下跑得好好的，一到部署各种幺蛾子。我自己部署时也踩了不少坑，这里整理一份能直接照做的流程。

5.1 Maven打包：跳过测试别忽略，打包配置要确认

打包之前一定要做几件事：

1. 检查application.properties或application.yml里的数据库连接改成了服务器地址
2. 确认Thymeleaf的缓存设置为开发模式关闭（本地调试），生产模式可开启或关闭影响不大
3. 用Maven打包命令，跳过测试加速：

mvn clean package -DskipTests

打包时会遇到一个经典问题：资源文件里的静态资源（图片、js、css）没打进去。排查方法很简单，打完包打开jar，看BOOT-INF/classes/static目录下是否有文件。没有的话去pom.xml看看resources配置，把静态资源目录加进去。

5.2 服务器部署：JDK环境、数据库导入、启动参数

我用的是阿里云一台2核4G的CentOS服务器。部署步骤如下：

# 1. 安装JDK 8（如果还没装） yum install -y java-1.8.0-openjdk # 2. 上传项目jar包到服务器，比如放到 /opt/app scp target/electronic-mall-0.0.1-SNAPSHOT.jar root@服务器IP:/opt/app/ # 3. 上传数据库脚本，导入MySQL mysql -u root -p electronic_mall < db/electronic_mall.sql # 4. 启动项目，用nohup防止关闭终端后进程被杀 cd /opt/app nohup java -jar electronic-mall-0.0.1-SNAPSHOT.jar --server.port=8080 > app.log 2>&1 & # 5. 查看启动日志 tail -f /opt/app/app.log

注意几个地方：

• JDK必须装1.8版本，装错版本或者装了OpenJDK 11，项目可能报版本错误，直接核对java -version
• MySQL导入脚本前先把数据库建出来：CREATE DATABASE electronic_mall CHARACTER SET utf8mb4;
• 如果服务器安装了宝塔面板，可以直接用它的可视化管理功能快速完成数据库导入和运行环境安装，对于不熟悉Linux命令的同学来说是个不错的选择

然后访问http://服务器IP:8080，如果页面打不开，先检查云安全组和防火墙是否放行8080端口。这个问题遇到概率很高，特别是阿里云默认安全组经常不放行非80端口。

5.3 静态资源路径和图片上传的坑

商品图片上传，开发时我存的是本地路径，比如上传图片后存到项目的static/upload目录。但jar包运行时有个坑：打包后这个目录在临时目录里，重启就没了。

后来我改成配置一个外部存储路径，在配置文件中设置：

app.upload-path=/opt/app/upload/

然后图片上传的保存路径指向这个外部目录，同时通过一个/images/**的映射拦截器，把外部目录映射为静态资源访问：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/images/**") .addResourceHandler("file:" + uploadPath + "/"); } }

这样服务器重启后图片还在，商品图不会一片红叉。这个问题论文里不用写太细，但实际部署时非常重要。

5.4 演示视频录制与材料包整理

最后是交付环节。因为我的原始标题里提到了“完整源码+LW+部署说明+演示视频，全bao一条龙”，这也是毕设市场最常见的交付物形态。我这里不评价产业链，只说一个学生自己如何准备交付材料：

1. 演示视频：用录屏软件（我用的是OBS），按顺序演示用户注册、登录、浏览商品、加购、下单、支付、收货；再切换管理员登录，演示商品上架、订单发货、数据统计——一次录完不要暂停，时长控制在5-8分钟，背景配乐不要超过视频声音。
2. 部署说明文档：包括环境要求、数据库初始化步骤、启动命令、默认账号密码。这份文档要自己先在干净的服务器上完整走一遍再写，逐条核对。很多同学写的部署文档最后一步启动不了，就是因为从没在干净环境里试过。
3. 论文（LW）：章节一般包括绪论、需求分析、系统设计、数据库设计、核心功能实现、系统测试、总结。注意每章要在功能展示时写出真实截图和结果，避免只有代码没有页面。
4. 项目原型和数据库脚本：数据库脚本要和代码里访问的表一致，字段名对不上启动就报错。交付前建议把本地数据库删掉重新导入一次脚本验证。

6. 答辩经验：项目展示的三个节奏和容易被追问的问题

答辩环节是我做完整个项目后觉得最需要单独整理经验的部分。很多同学项目做得不错，演示环节却一团糟，直接被老师扣了印象分。

6.1 演示怎么讲才清晰：按时长分层设计

我给三个时长版本的演示脚本：

• 3分钟精简版：注册登录 → 选商品加入购物车 → 下单支付 → 管理后台发货 → 收货完成。每步只操作不讲解，点了就过。
• 8分钟标准版：在精简版基础上加入：商品分类筛选、商品详情富文本展示、购物车数量修改、地址管理、订单取消流程。每步配一句业务说明。
• 15分钟完整版：再加后台商品管理（新增商品并上传图片）、订单状态的多流转路径（取消、发货、确认收货）、数据统计页展示。这个版本适合论文答辩前的预演。

演示时注意一个小细节：浏览器窗口先调整好合适分辨率，字体放大到150%以上，避免后排老师和屏幕前的同学看不清内容。有同学的字号小到我自己都要眯眼才看得到——这在答辩时是减分的。

6.2 答辩追问率最高的六个问题及应对

我把身边公认容易被追问的问题整理出来了，并且附上我的回答思路：

1. “订单超卖怎么解决？”— 讲库存扣减的SQL条件更新，说明影响行数为0即回滚。
2. “为什么用Thymeleaf不用Vue？”— 说明毕设项目追求开发效率和整体完整性，并补充说“如果项目需要前后端完全分离，我可以把Controller层拆成RestController，前端接API即可”。
3. “密码直接MD5存，安全性够吗？”— 承认单机项目用MD5加盐是校内的折中选择，生产环境要用BCrypt。
4. “数据库几张表之间的关联关系是什么？”— 把我在第3章讲的表关系图，在纸上画出来，一人一表。
5. “如果用户同时下单同一件商品，库存只有1件怎么办？”— 还是回到条件更新和事务回滚讲。
6. “这个系统有哪些可以继续优化？”— 回答方向是：引入Redis缓存高访问量商品、对接真实支付接口、增加秒杀限流，把高可用和高并发方案说上一两句，证明你有方向感。

6.3 论文和源码对应不上是最常见的事故

最后特别提醒一个很多人翻车的地方：论文与源码对不上。常见情况有两种，一种是论文写了“系统使用Redis缓存”，但源码里根本没有Redis依赖；一种是数据库设计里有一张“促销表”，但项目里完全没做促销模块。这类问题会显得学生论文有水分。

我的做法是：论文写完前通读一遍源码目录结构，确保论文中出现的每个功能模块在源码里都能找到对应包名和页面。页面截图用的是项目真实运行的界面，不用网上找的素材图。数据库脚本从项目实际使用的库导出，论文中表结构字段顺序与实际完全一致。这个工作看起来很麻烦，但答辩时的“可信感”就靠它撑起来。

写在最后的一点个人体会

整个项目做完，我最深的感受是：毕设项目不一定要很“新”，但一定要很“完整”。Spring Boot做电商系统，技术上没有不可替代的创新，但这恰恰是它的价值——你用一个主流框架把一套完整的业务闭环实现出来，过程中暴露的问题、做的取舍、踩过的坑，才是答辩时能滔滔不绝讲出来的底气。

我印象最深的调试经历是下单选完商品后订单金额多了0.01元，查了半天发现是浮点数累加精度丢失，后来把金额字段从double全换成BigDecimal，以分为单位存储，问题才解决。这种细节写不进论文，但它让我真正理解了为什么金融类系统绝不用浮点算钱。类似的经验，只有亲手做出来才会长在身上。

如果你也在做类似的系统，建议先把数据库表和订单核心流程画清楚，再开始写代码。数据库设计对了，后面全都会顺很多。祝你毕设顺利。