企业官网建设流程全解析

一年一度的毕设季又快到了。很多同学在选题阶段纠结得不行：既要工作量适中、能独立完成，又要技术栈拿得出手、答辩能讲清楚。我见过太多选了高大上题目、最后在验收前疯狂赶工的例子。今天说一个看起来“烂大街”，但实际上性价比极高的选题——电脑商城购物系统。它采用SpringBoot+Vue前后端分离架构，覆盖了商品展示、购物车、订单、支付模拟、后台管理等完整电商闭环，配齐全套源码、数据库脚本、毕业论文和答辩PPT，用来做计算机毕业设计或者课程设计都合适。这篇博文不灌水，我直接把项目从选型到落地的完整思路、核心代码逻辑、数据库设计细节、论文和答辩准备经验全部拆开讲，给准备做类似系统的同学一个可以照抄的作业。

这类系统最难的不是功能做不出来，而是功能做出来了却讲不出设计理由。答辩时老师问你“为什么这个表要这样设计”“库存扣减怎么保证不超卖”“JWT鉴权失效怎么办”，答不上来才是真翻车。所以我下面每讲一个模块，都会把背后的取舍逻辑一起说清楚。

1. 商城选题为什么年年被选：项目定位与工作量换算

1.1 它不是大工程，却覆盖了Web开发的全部关键链路

很多人一听“商城系统”，第一反应是“太普通了，网上烂大街”。但站在毕设选题的角度，“普通”恰恰是优点。一个合格的商城系统，业务链路是闭环的：用户注册登录、商品浏览搜索、加入购物车、订单结算、模拟支付、后台商品管理、订单发货。你把这个链条完整走一遍，就等于把Web开发里最核心的几块都摸了一遍——前端交互、后端接口、数据库建模、权限控制、事务处理。

从工作量来说，一个基础版商城系统，数据库十来张表，前端页面二三十个，后端接口五六十个，对一个人来说一个半月到两个月可以做得比较扎实。这个工作量放在毕设里是很合适的：既不是三五天糊弄完的级别，也不至于做到一半发现做不完。

答辩评分的时候，老师不太会指望你做出什么颠覆性创新，更多看的是：系统能不能跑、功能全不全、逻辑有没有硬伤、能不能讲清楚设计思路。商城系统恰好每一项都容易达成，而且可展示性强。演示的时候从注册登录到下单支付一路点下来，评审老师看得明白，问题也问得出来，你答得上来，分就不会低。

1.2 工作量分布与答辩评分点预判

我按自己的经验把商城系统的工作量大致划了个比例，可以给准备动手的同学做个参考：

答辩老师最常追问的几个点，基本集中在订单状态机、并发扣库存、Token鉴权失效这三处。这些不是单纯“写代码”能解决的，需要真正理解业务逻辑才能回答好。后面我会逐一展开。

2. SpringBoot + Vue 的组合选择：不追求最炫，只求最稳

2.1 后端框架：SpringBoot + MyBatis-Plus的基本盘

现在的毕业设计如果后端还在用传统的SSM（Spring+SpringMVC+MyBatis）一步步写XML配置，确实有点落后于时代了。SpringBoot最大的价值是“约定大于配置”，内嵌Tomcat，打一个jar包就能跑，省去了大量环境配置环节。对于单人开发毕业设计的场景来说，把精力留给业务逻辑远比折腾配置文件更划算。

持久层框架我推荐MyBatis-Plus而不是原生MyBatis，也不要纠缠于该不该用Spring Data JPA。原因很简单：MyBatis-Plus在MyBatis基础上提供了通用CRUD接口，单表操作几乎不用写SQL，遇到多表关联或复杂统计时又能手写SQL兜底。它还有个很实用的分页插件，商城的前台商品列表做了分页，用它只需几行配置。最关键的是，网上关于MyBatis-Plus的教程和踩坑资料非常多，出问题了容易找到答案，这对毕设选手非常友好。

后端项目结构建议按功能分包，而不是按层分包：

com.example.mall ├── config // 跨域配置、MyBatis-Plus分页配置、JWT拦截器配置 ├── controller // 接口层 ├── service // 业务逻辑层 ├── mapper // 数据访问层 ├── entity // 实体类 ├── common // 统一返回结果、全局异常处理、常量 └── util // JWT工具类等

按功能分包的好处是：一个模块（比如订单模块）的Controller-Service-Mapper放在同一条路径下，答辩画系统架构图时一目了然，老师看代码结构也省力。

2.2 前端：Vue + Element UI的务实搭配

前端部分Vue是主流选择。如果你用的是Vue3，搭配Element Plus；如果沿用Vue2项目模板，就用Element UI。这两个组件库在后台管理界面开发中几乎是无脑选项，表格、表单、弹窗、分页这些后台常见元素全都封装好了，效果也成熟稳定。

前端项目里有三件建议尽早做好的事：

第一，Axios请求封装。把baseURL、请求头里附带Token、响应拦截统一错误提示这些逻辑集中在一个request.js文件里，后续所有页面的接口调用都走这一个封装。这样每个页面请求不用重复处理Token和错误码，代码量会少很多。

第二，路由守卫。前台用户页和管理员后台要区分开，Vue Router的beforeEach守卫里读取本地存的Token和角色信息，没有登录就跳转到登录页，登录了但角色不对就跳转到首页。这一步做不对，就会出现直接输入URL到后台页面不加校验的问题。

第三，开发期跨域问题。本地开发时前端跑8080端口，后端跑8081端口，浏览器会拦截跨域请求。后端写一个全局CORS配置类，或者用Vite的proxy代理转发，把/api前缀的请求转发到后端地址。毕设阶段推荐后端直接放行CORS，省事。

3. 系统功能地图：从前台下单到后台发货的完整链路

3.1 前台用户端的功能线

前台面向普通用户，功能按用户操作习惯规划：

首页展示轮播图、分类入口、推荐商品。商品列表页支持按分类筛选、按关键词搜索（商品名模糊匹配）、分页展示。商品详情页展示商品图片、价格、库存、销量，加购按钮要实时判断库存是否充足。

购物车页面支持勾选商品、修改数量、删除商品、清空失效商品，结算时只提交勾选中的商品。订单确认页需要选择收货地址、填写订单备注、展示商品总价。生成订单后跳转模拟支付页面，支持“模拟支付成功”和“模拟支付取消”两个入口。订单列表页按状态分类展示，待支付订单可以取消或继续支付，已发货订单可以点击确认收货。

这里有一个容易被忽略但答辩可能会问的点：商品价格要以加入购物车时刻还是下单时刻为准？实际项目里商品价格随时可能调整，稳妥的做法是在订单表里把商品名称、下单单价、数量、小计金额全部冗余存一份。这样即便管理员后来改了商品价格，用户已下的订单依然保留下单时的价格快照，也算是对“订单不可随意变动”的业务模拟。

3.2 后台管理端的功能线

后台面向管理员，核心是商品和订单管理。

商品模块：商品列表（分页、条件搜索）、新增商品、编辑商品（修改价格、库存、图片）、上下架切换、删除商品。删除建议用逻辑删除而不是物理删除，后面数据库设计部分会细说。

订单模块：管理员查看所有订单，按状态筛选订单，对待发货订单执行“发货”操作（填写物流单号后状态变为已发货），也可以处理用户模拟申请取消的订单。

用户模块：管理员可以查看用户列表，禁用或启用用户账号。被禁用的用户登录时会收到提示，这一功能相对简单但扩展了权限管理的完整度。

其他常见功能：轮播图管理、公告管理、基础数据统计。数据统计不需要复杂，用一个汇总页查商品总数、用户总数、订单总数、累计销售额就够撑起后台门面了。用MyBatis-Plus的聚合查询，几条SQL的事。

3.3 用户角色与权限控制的简化版RBAC

完整的RBAC（基于角色的访问控制）要建用户表、角色表、权限表外加多张关联表，对毕设来说确实过剩了。这里做一个简化：用户表加一个role字段，用字符串标识普通用户和管理员。控制层面分两处：

第一，前端路由守卫按角色控制页面访问。普通用户访问/admin路径直接拦截跳转首页。

第二，后端接口按角色做二次校验。管理员相关接口在Controller层加注解或自定义拦截器校验角色，JWT中携带角色信息，拦截器中解析出来判断。前端看不代表后端安全，后端必须挡住非管理员请求，这个点答辩老师可能会专门问。

4. 数据库设计：表结构怎么建，才能既够用又经得起追问

4.1 核心表结构与字段清单

商城系统的表没有太多花哨的，但字段设计和表间关系是答辩必问的。以下是我整理的核心表清单：

用户表 user

商品分类表 category

商品分类这里做一个树形会复杂一些，但二级分类（比如“笔记本”下面分“轻薄本”“游戏本”）也不算难。如果不想做无限级分类，做两级就够。

商品表 product

购物车表 cart

购物车表加了一个checked字段，这样用户可以勾选部分商品去结算，订单确认页只需要查当前用户勾选状态的购物车数据，逻辑非常清晰。

订单表 orders

订单项表 order_item

收货地址表 address

4.2 三个关键设计决策及答辩理由

订单头和订单明细为什么要拆成两张表？

一个订单可能包含多件商品，如果用一张表存储，要么一条记录存一个商品导致同一订单出现多行重复信息，要么把所有商品塞进一个JSON字段里，后续统计和修改无从下手。拆成orders和order_item两张表，形成标准的主从表关系：orders存订单公共信息（金额、状态、收货人），order_item存每件商品的快照信息。这也是电商系统的基础建模方式，答辩时讲这一点能直接体现你对数据库三大范式的理解。

金额字段为什么用decimal而不用float/double？

float和double是浮点数，在计算机中存储的是近似值，做金额累加会出现0.1+0.2≠0.3这类精度问题。算总价时如果用了浮点类型，可能把一个含有小数位的金额算成带一串乱码的数字。Java后端处理金额也应该用BigDecimal而不是double，从前端传入的价格先转成字符串再构造BigDecimal，避免精度丢失。这个点我建议写进论文的数据库设计章节里，属于一看就说明你做过实战的细节。

商品删除为什么要用逻辑删除？

物理删除直接把记录从表中抹掉，带来的问题是：已下单的商品被删除后，订单项里的商品ID会指向不存在的记录，历史订单的统计和管理员对账都会出问题。逻辑删除是在表中加is_deleted字段，查询时自动过滤掉标记为删除的记录，但从数据库层面看数据还在，历史数据依然完整。MyBatis-Plus的@TableLogic注解可以自动完成逻辑删除的SQL拼接，是毕设里性价比极高的小功能。

5. 三块硬骨头的落地实现：鉴权、购物车、订单与库存

5.1 登录鉴权：JWT + BCrypt

商城毕竟涉及用户资产和订单数据，登录鉴权逃不掉。这里我选用JWT（JSON Web Token）而不是传统Session，原因主要有两点：一是前后端分离架构下，Session需要服务端存储，还需要解决跨域请求下的Cookie携带问题；二是JWT无状态，后端不存会话，打jar包重启后用户Token依然有效，也不用担心Session失效导致体验变差。

用户密码存储用BCrypt加密。BCrypt是带盐加密算法，同一个密码每次加密得到的密文都不同，无法通过彩虹表反查，安全性比简单的MD5加盐高一个量级，而且SpringSecurity里的BCryptPasswordEncoder可以直接使用，不引整个安全框架也能单独用。

JWT工具类的核心逻辑：

public class JwtUtil { // 生成Token，subject放用户名，claim里放userId和role public static String generateToken(Long userId, String username, String role) { return Jwts.builder() .setSubject(username) .claim("userId", userId) .claim("role", role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + 1000 * 60 * 60 * 24)) .signWith(SecretKeySpec, SignatureAlgorithm.HS256) .compact(); } // 解析Token，校验签名和过期时间 public static Claims parseToken(String token) { return Jwts.parser() .setSigningKey(SECRET_KEY) .parseClaimsJws(token) .getBody(); } }

生成Token时把userId和role写进claim而不是反复查数据库，后面的拦截器只需要解析一次Token就能获取身份信息，效率和安全都能兼顾。Token设一天有效就够了，毕竟只是毕设演示场景。

后端再用拦截器统一校验：放行登录注册接口，其余接口全部校验请求头里的Token。代码如下：

public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token == null || !token.startsWith("Bearer ")) { throw new RuntimeException("未登录或Token缺失"); } Claims claims = JwtUtil.parseToken(token.replace("Bearer ", "")); request.setAttribute("userId", claims.get("userId")); request.setAttribute("role", claims.get("role")); return true; } }

前端在Axios拦截器中携带Token：

request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = 'Bearer ' + token } return config })

这里有一个实际容易踩的坑：JWT的密钥不要硬编码在代码里提交到Git仓库，密钥泄露等于任何人都能伪造Token。毕设项目可能不涉及这个，但论文里可以提一句“密钥应当放在配置文件中或使用环境变量注入”，这个细节会让答辩老师对你有好感。

5.2 购物车的接口设计与幂等性

购物车模块看起来简单，实际接口设计有讲究。前端页面上有加购、改数量、勾选、删除、清空多个操作，后端对应设计如下：

• POST /api/cart/add：加购，参数是商品ID和数量
• PUT /api/cart/update：修改购物车项数量
• PUT /api/cart/check：勾选或取消勾选
• DELETE /api/cart/{id}：删除某个购物车项

加购接口的逻辑稍微注意一下：用户对同一商品连续加购两次，合理的表现不是出现两条购物车记录，而是把数量累加。所以我用userId + productId做联合条件先查一遍购物车表，存在就update数量，不存在才insert新记录。这个逻辑就叫“幂等”，即同一个操作反复执行结果一致。接口设计中留心幂等性，也是答辩中能拿出来讲的专业点。

另外加购和改数量时都要校验库存。如果用户手快把数量改成大于库存，后端必须拦截并提示“库存不足”。这个校验必须做在后端，前端只是提示，不能把安全性寄托在前端校验上。

5.3 下单流程、事务与库存扣减方案

订单创建是整套系统里最容易出并发问题的环节。用户点击“提交订单”的那一刻，后端要完成一串关联操作：查询购物车勾选项、校验地址、计算总金额、生成订单记录、生成订单项记录、扣减商品库存、清空已下单的购物车项。这每一步都是数据库写操作，中间任何一步失败，前面的操作都必须回滚。用Spring的@Transactional注解包住整个方法，事务回滚才能保证数据不会出现“订单建了但库存没扣”“购物车清了但订单没生成”这种半个状态。

库存扣减我重点说一下。最朴素的方案是：

UPDATE product SET stock = stock - #{quantity} WHERE id = #{productId}

这个SQL如果多个用户同时下单，可能出现超卖：两个请求同时读到库存为5，都扣到4，最后卖出6件但库存只减了2。解决办法是加库存条件：

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

受影响行数为0说明库存不足，事务回滚，报错提示。这种写法本质是乐观锁的思路——用更新时校验代替查询时校验，在毕设这个并发量级下完全够用，也比引入Redis分布式锁简单得多。如果论文里写了“用乐观锁解决超卖”，老师问起来你可以很自信地讲出这条SQL的含义。

订单状态我用一个状态机管理，避免到处都是魔法数字：

状态流转写死在Service层，比如支付接口只允许status=0的订单流转到status=1。这样不会出现“已完成的订单再次点击支付”的错乱情况。

6. 从代码到论文再到答辩：毕设全流程通关经验

6.1 毕业论文的章节骨架怎么搭

很多同学代码写得不错，论文却不知道从哪下笔。我按常见的本科毕业论文要求，整理了一个通用骨架：

第一章 绪论：写研究背景和意义（电子商务发展背景+系统开发的目的）、国内外研究现状（这里重点强调国内电商生态成熟，毕设做商城有坚实的业务参考）、研究内容和技术路线。

第二章 相关技术介绍：分别介绍SpringBoot、Vue、MySQL、MyBatis-Plus，每项一两页说明核心特性和选择理由即可，不要大段贴教程，也不要照抄官网文档。

第三章 需求分析：画用例图，分别描述前台用户用例（注册登录、浏览商品、下单支付）和后台管理员用例（商品管理、订单管理、用户管理），列出功能需求表和非功能需求（系统响应时间、安全性要求）。

第四章 系统设计：这部分是论文的重头戏。画系统功能结构图、架构图（前端Vue+后端SpringBoot+数据库MySQL的三层架构）、数据库ER图，逐一说明核心表的字段和关系。然后按模块介绍设计思路，重点写登录鉴权流程、购物车逻辑、下单流程时序、数据库表设计。

第五章 系统实现：每个核心功能配功能描述+核心代码片段+运行截图。截图建议用真实运行界面，不要用网上的占位图。截图里最好能看到地址栏URL和登录状态，否则老师会觉得你没跑起来。

第六章 系统测试：写功能测试和性能测试。功能测试列一个测试用例表格：测试名称、前置条件、操作步骤、预期结果、实际结果。性能测试用Postman并发请求几个接口截图即可。

核心原则：论文的所有图表和代码必须与项目源代码保持一致。我曾经见过A同学论文里贴的ER图和实际数据库表对不上，答辩被指出后整个人都慌了。所以论文里每一张图都要找源码核对过再放。

6.2 答辩PPT的结构与高频问题

答辩PPT跟着论文走，页数控制在12~15页比较合适。结构我建议是：选题背景和意义（2页）→ 技术栈与架构（2页）→ 功能演示截图（5~6页）→ 核心设计亮点（2页）→ 问题与改进（1页）。

功能演示的部分截图一定要高清、按用户操作路径排列：注册登录页、商品列表、购物车、订单确认、支付成功、后台商品管理、订单发货。演示的时候用真实系统走一遍流程，效果远好过播放录制视频。

老师的高频问题我整理了一份清单，提前准备就不会紧张：

1. 为什么选这个题目？答：电商业务流程完整，覆盖Web开发全链路，前端Vue后端SpringBoot都是主流技术。
2. JWT和Session的区别是什么？为什么用JWT？答：JWT无状态、适合前后端分离，Session依赖服务端存储。
3. 如果JWT被窃取了怎么办？答：加过期时间、配合HTTPS传输、重要操作二次校验。
4. 库存超卖怎么解决？答：乐观锁，更新时校验库存数量大于等于扣减量。
5. 订单金额为什么不在前端算？答：前端计算可被篡改，金额必须后端以数据库单价重新计算。
6. 数据库为什么这样设计？答：按业务模块拆分，订单主从表符合范式，金额用decimal保证精度。
7. 系统有哪些不足？答：如实说并发量级有限、未接入真实支付网关，并给出改进方向（引入Redis分布式锁、对接微信支付）。

准备这些问题时一定自己把“为什么”想清楚，而不是背答案。老师很会看出你是背的还是理解的。其中“有哪些不足”千万别答“没有不足”，说一个真实局限并给出改进思路，反而加分。

6.3 演示环境的准备与数据初始化

这最后一块是很多同学临到答辩才着急的地方。演示环境必须提前准备好三样东西：

数据库初始化数据要足够“好看”。分类至少5~6个，商品至少20~30个，商品图片用本地图片或可靠图床，名称和价格要像真实商品。有些同学数据库里只有“商品1”“商品2”这种测试数据，演示截图效果大打折扣，老师一看就知道没用心。

演示账号提前分角色准备好：一个普通用户账号，购物车里预先放好几件商品；一个管理员账号，登录后直接能看到待处理订单。这样演示时从登录到下单再到后台发货全流程一路顺畅，不会现场手忙脚乱去填表加商品。

本地环境要稳定。MySQL服务设成开机自启，后端用mvn clean package打成jar包再从命令行启动（或者用IDEA直接跑，看你自己习惯），前端npm run build之后也可以用nginx托管，也可以在开发模式下启动。演示时优先用一个能持续运行的版本，不要边演示边改代码。

我个人的习惯是准备一套“一键启动”脚本，依次启动MySQL、后端jar包、前端服务，全部跑通后做一次完整流程测试再截图留存。这样就算演示现场网络出问题，也可以放截图兜底，不至于全程尬场。

做毕设这几个月，最大的体会是：商城系统虽然常见，但真正把它从头到尾“想透”而不是“抄会”，学到的东西非常多。从需求拆分、数据库建模，到接口设计、事务处理，再到论文写作、答辩表达，这套流程走下来，等于提前模拟了一遍真实项目开发的完整链路。如果你正在为选题发愁，或者已经选了这个方向但不知道从哪里下手，按我上面讲的模块顺序逐步推进就好。最后再分享一个小技巧：动手写代码之前，先把数据库表全部建好并录入基础数据，再开始设计接口。表结构定清楚了，后面的代码开发能少走一半弯路，相信我，这是最值得先花时间的一件事。