每年毕业设计那几个月，总有一批人被电商类系统折腾得够呛。选题倒是不难，真正落地又是另一回事——后端接口要稳、前端页面要像样、数据库设计要经得起答辩老师提问，最后还得挤出时间写论文、准备演示。我自己完整趟过一遍这套流程：SpringBoot做后端、Vue搭前端、MySQL存数据，从零把一个PC端电商项目的核心业务跑通，代码、数据库脚本、论文初稿、部署文档全部整理归档。这篇文章想把整个项目从选型、架构、编码到部署的关键决策讲清楚，尤其是一些文档里根本不会写的坑，给正在做类似毕设或者想入门前后端分离开发的朋友做个参考。
1. 为什么这个技术组合能撑起电商系统的完整闭环
1.1 三个核心选型各自的加分点
先说结论：SpringBoot + Vue + MySQL 这套组合，放到今天依然是毕业设计里性价比最高的选择。不是因为它多先进，而是因为每一环都有足够的生态支撑和现成案例，遇到问题几乎都能搜到解决方案。
- SpringBoot：内嵌Tomcat、自动配置、起步依赖，开发效率远高于传统的SSM手动拼装。一个实时重载插件就能省掉大量重启时间，写接口、连数据库、做权限校验都有成熟的starter可以引入。
- Vue：渐进式框架，第一周就能上手。配合Element UI一类的组件库，几分钟能搭出像模像样的后台管理界面，对电商项目里大量存在的表格、表单、弹窗场景简直是降维打击。
- MySQL：免费开源、文档丰富、面试必问。作为毕设项目的存储层完全够用，InnoDB引擎、事务隔离、索引优化这些点还能拿来当论文亮点。
1.2 为什么不盲目追新技术栈
我见过有人给毕业设计上微服务、上K8s、上前后端彻底分离的魔改架构，结果临近答辩还在捣鼓Docker网络配置。这里不是否定新技术，而是要想清楚：毕业设计的评审重心通常落在业务完整性、工程规范性、技术基本功三个维度，而不是你有没有把全家桶全部换一遍。
微服务拆分的核心是应对高并发和团队协作，单机部署的毕设项目硬拆成"用户服务""订单服务""商品服务"，除了给自己增加服务间通讯、链路追踪、分布式事务这些额外负担之外，在答辩现场几乎展示不出增量价值。与其那样，不如把单体应用的分层架构写扎实，把接口设计、数据库设计、事务处理讲清楚，每个点都能直接回答。
1.3 这套系统能覆盖的完整业务面
一个PC端电商项目需要的核心能力大致如下：
- 用户端：注册登录、商品浏览、分类筛选、购物车、下单、个人中心
- 管理端：商品管理、分类管理、订单管理、用户管理、轮播图管理
- 公共能力：图片上传、分页查询、权限校验、统一异常处理
这些能力恰好覆盖了JavaWeb课程从入门到综合实践的全部知识点，也是后面论文里"需求分析"和"系统设计"两个章节的主要素材。技术不难，但串联起来就是一个完整闭环。
2. 动工之前先定骨架：项目结构直接影响后期效率
2.1 前后端分离的基本约定
很多第一次做前后端分离的人，最困惑的是"代码到底怎么组织"。我的建议是一开始就分成两个独立目录：前端工程和后端工程各管各的，只用接口文档和代理配置关联起来。这样做的理由很实在：
- 后端可以先用Postman调通所有接口，不需要等前端页面完成
- 前端可以用Mock数据先开发页面，不用被后端进度卡住
- 部署时可以独立推送、独立重启，出问题排查范围更小
2.2 后端目录的MVC分层
SpringBoot后端我在实践中通常按这样的结构组织：
src/main/java/com/example/mall ├── common // 统一返回结果、全局异常、常量 ├── config // 跨域配置、拦截器注册、文件上传配置 ├── controller // 接口层，只做参数接收和结果封装 ├── entity // 数据库实体类 ├── mapper // 数据访问层，配合MyBatis-Plus ├── service // 业务层，核心逻辑全部在这里 │ └── impl // 业务实现类 └── utils // JWT工具、字符串处理等对应资源目录里放的是SQL脚本和Mapper XML文件，初始化数据也直接写进脚本里，方便任何环境一键还原。
这套分包模式的优点是职责边界清晰：controller不写业务逻辑、service不直接拼SQL、mapper只负责数据查询。答辩时老师问"登录流程走了哪些层"，可以顺着链路整条讲下来，这就是工程规范性的体现。
2.3 前端目录的views与components划分
Vue前端我建议用Vue CLI或Vite创建工程后，按下面方式组织：
src ├── api // 按模块封装的请求方法 ├── assets // 静态资源 ├── components // 公共组件（分页、上传等） ├── router // 路由配置 ├── store // Vuex状态管理 └── views // 页面级组件 ├── home ├── product ├── cart ├── user └── adminviews这种东西最忌讳一股脑全塞在同一个目录里。按业务模块分文件夹，后续扩展权限控制、懒加载路由时能省不少事。
3. 后端核心模块拆解：从登录鉴权到订单状态流
3.1 JWT鉴权和拦截器的取舍
电商系统必然涉及用户状态，这里最大的决策点是Session还是JWT。
我最终选择了JWT + 拦截器的方式，原因有两个：前后端分离项目里Session天然不好处理跨域问题，而JWT把用户信息直接放在Token里，后端无状态化，前端请求时在Header里带上Authorization即可。
实现上不需要引入Spring Security这么重的安全框架，一个拦截器加一个工具类就够了：
@Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录等白名单接口 if (isWhitelist(request.getRequestURI())) { return true; } String token = request.getHeader("Authorization"); if (token == null || !JwtUtils.validateToken(token)) { response.setStatus(401); return false; } // 解析出用户id，放入request attribute，后续controller直接取 request.setAttribute("userId", JwtUtils.getUserId(token)); return true; }这个做法的好处是：登录接口返回一个Token，前端存起来，后续所有带权限的接口统一校验。答辩时还能顺带讲一讲Token过期、刷新机制的设计思想。
3.2 商品模块：列表、分页、条件搜索
商品列表是电商系统最核心的读接口。用MyBatis-Plus的Page对象配合LambdaQueryWrapper可以非常简洁地实现多条件分页查询：
public Page<Product> queryProductPage(ProductQuery query) { Page<Product> page = new Page<>(query.getCurrent(), query.getSize()); LambdaQueryWrapper<Product> wrapper = Wrappers.lambdaQuery(); wrapper.eq(StringUtils.isNotBlank(query.getCategoryId()), Product::getCategoryId, query.getCategoryId()) .like(StringUtils.isNotBlank(query.getKeyword()), Product::getName, query.getKeyword()) .eq(query.getOnSale() != null, Product::getOnSale, query.getOnSale()) .orderByDesc(Product::getCreateTime); return productMapper.selectPage(page, wrapper); }这段代码其实就是把"分类过滤""关键字模糊搜索""上下架状态过滤""按时间倒序"四个条件叠加起来。用Lambda方式写，字段名不会写错，条件拼接也可读。
商品模块有个容易被忽略的设计点：上下架状态和库存字段的联动。商品表里至少要有一个stock字段，下单扣库存时必须加条件防止超卖（后面订单模块会详细讲）。另外建议加一个sales字段，方便在首页按销量做推荐排序。
3.3 购物车与订单的核心流程
购物车相对简单，本质上就是一个"用户ID + 商品ID + 数量"的关联表。真正有技术含量的是下单流程，要保证数据的一致性：
@Transactional(rollbackFor = Exception.class) public Order createOrder(Long userId, List<CartItem> items) { // 1. 生成订单主记录，状态设为待支付 // 2. 遍历购物车条目，校验库存 // 3. 扣减库存（UPDATE ... SET stock = stock - ? WHERE id = ? AND stock >= ?） // 4. 计算订单总金额，生成订单明细 // 5. 清空已结算的购物车 }这里最关键的@Transactional注解，保证从创建订单到清空购物车要么全部成功、要么全部回滚。扣库存那句SQL一定要带stock >= ?条件，否则在并发场景下会出现超卖——这是电商跟普通增删改查最大的区别，答辩老师基本都会问，你要能答上来。
订单的支付环节一般情况不接真实支付渠道，但要在状态流里预留支付回调的入口。我的做法是设计一个pay_type字段和pay_time字段，后台管理端提供"模拟支付"按钮，前端点了之后订单状态从"待支付"变为"待发货"，这样既完整又不依赖第三方。
3.4 文件上传：本地存储和MinIO怎么选
商品图片上传是必做功能。最简单的方案是存到本地磁盘，给SpringBoot配置一个静态资源映射目录；如果接触过对象存储，推荐把MinIO集成进来，代码量差不多但扩展性好得多。
MinIO的核心流程是：客户端先把文件POST到后端接口，后端用SDK初始化客户端、上传到指定桶，然后返回可访问的URL前端存到商品字段里。相比本地存储，它把文件从应用服务中剥离出来，将来数据迁移或者多机器部署都不用改代码。
如果只是毕设演示，本地存储完全够用。但论文里"系统实现"章节可以额外写一段MinIO选型对比，显得更有深度，答辩时也能展示你对工程方案做过思考。
4. 数据库设计：表结构想清楚，代码和论文都好写
4.1 核心表清单
我最终设计的核心表有8张，基本能够覆盖一个电商项目主流程：
| 表名 | 作用 | 关键字段 |
|---|---|---|
| user | 用户表 | username, password, nickname, avatar |
| category | 商品分类表 | name, parent_id, sort |
| product | 商品表 | name, subtitle, main_image, detail, price, stock, sales, on_sale |
| cart | 购物车表 | user_id, product_id, quantity, checked |
| order | 订单主表 | order_no, user_id, total_amount, status, pay_time, ship_time |
| order_item | 订单明细表 | order_id, product_id, product_name, product_image, price, quantity |
| address | 收货地址表 | user_id, receiver, phone, province, city, detail |
| banner | 轮播图表 | image_url, link_url, sort |
这套表结构对应的ER关系也比较清晰：用户一对多订单、订单一对多明细、分类一对多商品。论文里画ER图、写数据字典都不用另起炉灶。
4.2 订单状态字段的设计细节
订单表最容易犯错的是直接用String字段存状态，比如"待发货"。数据库字段存的应该是状态码，而不是中文描述。我用的是tinyint类型，字段名叫status，状态定义统一放在后端常量类里：
0：待支付 1：待发货 2：待收货 3：已完成 4：已取消这样做的另一个好处是——前端展示时可以用一个状态映射组件统一翻译，避免每个页面各写一套判断逻辑。答辩时你还可以主动讲一讲"为什么不用枚举存中文"，体现的是数据库规范化的理解。
4.3 事务、索引与连接池的几个实战选择
普通的单表查询加不加索引看不出差别，但一旦数据量上来，慢查询会直接影响体验。我在这套项目里做了两个索引决策：
- 商品表的
category_id建立普通索引，配合分页查询 - 订单表的
user_id建立普通索引，保证"查询我的订单"不会全表扫描
连接池这块，SpringBoot默认引入HikariCP就够了，配置里设置maximum-pool-size为10、minimum-idle为5，对单机项目已经完全够用。完整的配置项长这样：
spring: datasource: url: jdbc:mysql://localhost:3306/mall?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8 username: root password: yourpassword hikari: maximum-pool-size: 10 minimum-idle: 5 connection-timeout: 30000useSSL=false为什么要加，后面部署篇会提到，这里先记住：不加它新版本MySQL连接器会默认要求SSL握手，容易报错。
5. Vue前端接入：路由、请求封装和后台管理页
5.1 路由规划与登录守卫
前端工程第一步是配置路由。我的习惯是先把所有页面路径列一张表，再一个一个映射到组件，避免后期增删路径时找不到对应页面：
/ 首页 /login 登录页 /register 注册页 /product/:id 商品详情 /cart 购物车 /user/order 我的订单 /admin/product 后台-商品管理 /admin/order 后台-订单管理 /admin/category 后台-分类管理登录守卫这件事很多新手会忽略，但我建议一定要做：在Vue Router的beforeEach里判断store中是否有token，没有就强制跳到登录页。做完之后无论是用户刷新页面还是直接输URL访问后台，都不会出现"白屏但接口狂报401"的诡异问题。
router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.path.startsWith('/admin') && !token) { next('/login') } else { next() } })5.2 axios统一封装再谈跨域
前端请求几乎不可能绕开axios，所以一定要在项目初期就统一封装一下。我的封装思路是：所有接口用一个request.js，做四件事——统一前缀、注入Token、拦截响应统一处理业务码、HTTP错误统一提示。
开发阶段最常见的问题是跨域。前后端分离时后端地址比如http://localhost:8080，前端跑在http://localhost:3000，浏览器会拦截这个跨域请求。解决方案是后端开启CORS配置，前端则通过Vue CLI的devServer代理：
module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } }这样前端请求/api/user/login，开发环境下由脚手架代理转发到后端，看起来就像是同源请求。
5.3 管理后台的增删改查页面怎么写最省力
商品管理、分类管理、订单管理这三个后台页面，本质上是同一个模板套不同的字段。最省力的写法是：每个页面都用"搜索区 + 表格区 + 弹窗表单"三件套结构，然后把所有请求方法放到src/api目录下单独维护。
以商品管理为例，一个典型页面的逻辑可以拆成这样：
- 页面挂载时调用
fetchList(params)加载第一页数据 - 表格行上绑"上架/下架"按钮，操作完刷新当前页
- 新增/编辑共用一个弹窗表单，提交时根据ID判断是POST还是PUT
- 删除走二次确认，接口成功后重新加载列表
这套模式写顺手后，三个后台页面一共花不了多少时间，而且代码风格统一，后期维护也不用到处找逻辑。这也是为什么我说Vue + Element UI这种组合对毕设项目效率极高。
6. 从本地联调到Linux服务器部署：一步步跑通
6.1 环境准备与版本匹配的坑
开始之前先把环境对齐，我自己在这块踩过不少坑，尤其是版本匹配问题。建议的版本组合如下：
| 软件 | 建议版本 | 说明 |
|---|---|---|
| JDK | 1.8 | 稳定，SpringBoot 2.x完全兼容 |
| Maven | 3.6+ | 依赖管理 |
| Node.js | 14+ | Vue工程构建 |
| MySQL | 5.7或8.0 | 二者都可，注意驱动差异 |
| SpringBoot | 2.7.x | 不要直接上3.x，除非你想折腾 |
| Vue CLI | 4.x/5.x | 配合Node版本 |
SpringBoot版本这个话题值得单独说。SpringBoot 3.x发布后很新，但它基于JDK17，并且javax的包名改成了jakarta，很多老教程和博客里的代码直接粘贴会编译报错。对一个需要快速出结果的毕设项目来说，我强烈建议用2.7.x，代码教程最多，遇到问题查得快。
数据库导入我用的是Navicat的可视化方式，右键数据库、选择"运行SQL文件"就能把初始化脚本一次性执行完。这个操作等价于命令行里的mysql -uroot -p < mall.sql，但可视化界面不容易出错。
6.2 SpringBoot配置文件的必要调整
application.yml里需要根据本机情况修改三个地方：数据库账号密码、文件上传的存储路径、端口号。前两个不用解释，第三个是经验之谈——如果你本机8080端口已经被其他程序占用，要先把server.port改掉，否则项目启动会秒报"Port already in use"。
文件上传的存储路径，用绝对路径更好，比如Linux服务器上的/home/app/images，避免部署之后相对路径指向了当前工作目录，一不小心被覆盖或权限不足。
6.3 联调时前端代理与后端CORS配合
本地联调时，最容易出现的现象是：前端页面向/api/user/login发请求，浏览器Network面板里显示请求是红色报错，后端控制台却什么都没有。
这个问题的根因基本是请求没到后端，被前端代理挡下了。检查顺序是：先看代理是否生效（Network里的请求URL是不是被替换成了目标地址），再看后端CORS配置是否放行了OPTIONS预检请求。跨域时浏览器会先发一个OPTIONS请求试探，如果后端没处理，主请求根本发不出去。
提前在SpringBoot里写好跨域配置能省很多事：
@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true); } }6.4 服务器部署：jar + nginx模式，还是打包塞进SpringBoot？
部署方案我做过对比，直接说结论：推荐jar包和前端静态文件分开部署，用Nginx做反向代理统一入口。
具体做法是：
- 后端执行
mvn clean package -DskipTests生成jar包，放到服务器上执行java -jar mall.jar启动 - 前端执行
npm run build，把生成的dist目录上传到服务器，比如放到/usr/share/nginx/html - Nginx配置里把
/api开头的请求转发到http://localhost:8080，其余静态资源直接serve
关于网上一搜一堆的"前端打包后放进SpringBoot的static目录"，这个方案我实测过，确实能跑：把dist里内容复制到src/main/resources/static，重新打包，一个jar就能直接搞定前后端。它的优点是部署极其简单，适合懒人；缺点也很明显，前端改动一次后端就要重新打包重启，调试效率太低，而且Nginx能做的静态缓存、gzip压缩全都没了。
所以我的最终选择是交给Nginx，配置核心部分其实只有一段代理规则：
server { listen 80; server_name your.domain.com; location / { root /usr/share/nginx/html; try_files $uri $uri/ /index.html; } location /api { proxy_pass http://localhost:8080; } }这套方案在答辩现场演示时也很加分：你可以在笔记本上演示本地版，然后切到服务器公网地址演示线上版，顺带说清楚"Nginx做流量转发、后端无状态化、静态资源独立部署"这套架构，临场提问基本都能接住。
7. 几个容易卡住的地方，我踩过后的解决记录
7.1 MySQL SSL连接错误的处理
第一次启动项目连数据库时，控制台直接抛了一个关于SSL的异常，提示大概是Communications link failure。原因就在于新版MySQL连接器默认启用了SSL，而本地MySQL服务端没有配置相应的证书。
解决方式是在数据库连接URL上追加useSSL=false，告诉连接器不需要做SSL握手。同样常见的另一个参数是serverTimezone=Asia/Shanghai，不加的话日期字段在插入时会报时区异常，写入的时间也可能差8个小时。这两个配置我一开始没注意到，后来在部署文档里特意标了红字提醒自己。
7.2 SpringBoot版本过高引发的依赖连锁反应
有一版我头脑发热直接把项目升到了SpringBoot 3.x，结果两个问题接踵而来：javax.*改成了jakarta.*，所有引入Security或Validation的实体类全部编译失败；同时一些第三方MyBatis-Plus和代码生成器的版本还没适配新版本，API直接变了。修了一半我果断回退到2.7.x，十分钟内一切恢复。
这次经历给我的教训是：项目框架版本要选"成熟稳定"而不是"最新"。毕业设计正确的节奏是把时间和精力花在业务正确性上，绝不是和框架兼容性作斗争。
7.3 前端刷新页面404与登录态丢失问题
上线后我发现，用户从商品详情页刷新一下，页面居然变成了404。这是SPA单页应用配合Nginx时最典型的坑：前端只有一个index.html，而刷新时浏览器会向服务器请求/product/123这个真实路径地址，服务器找不到自然返回404。
Nginx配的try_files $uri $uri/ /index.html;就是专门解决这个问题的——所有找不到的请求都回退到index.html，让前端路由再接管。登录态丢失的问题则是因为我用Vuex存Token，刷新后内存被清空。解决方式是初始化时将Token从localStorage恢复进store，同时在axios请求拦截器里统一从storage读Token。
这三个问题都属于"教科书不会明说、项目必遇"的类型，实战里记下来能帮后面人省下大量排查时间。我整理部署文档时专门加了一章"常见问题排查"，就是为了让这套项目交付出去之后，接手的人不至于在第一步配置环境就劝退。
作为一个已经把这套项目从零趟完的人，我的建议是：别急着写代码，先把表结构和接口清单定下来，再动手填业务代码。这个顺序看起来慢，实际砍掉的返工时间远比前期“快”省下来的多。如果后面有时间，还可以给项目补上订单超时自动取消、Redis缓存商品分类、Excel导出订单等进阶功能，每一个都能在论文和答辩中多出一个亮点。
