每年毕业设计那几个月总有一批人被电商类系统折腾得够呛。选题倒是不难真正落地又是另一回事——后端接口要稳、前端页面要像样、数据库设计要经得起答辩老师提问最后还得挤出时间写论文、准备演示。我自己完整趟过一遍这套流程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 PageProduct queryProductPage(ProductQuery query) { PageProduct page new Page(query.getCurrent(), query.getSize()); LambdaQueryWrapperProduct 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, ListCartItem 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, avatarcategory商品分类表name, parent_id, sortproduct商品表name, subtitle, main_image, detail, price, stock, sales, on_salecart购物车表user_id, product_id, quantity, checkedorder订单主表order_no, user_id, total_amount, status, pay_time, ship_timeorder_item订单明细表order_id, product_id, product_name, product_image, price, quantityaddress收货地址表user_id, receiver, phone, province, city, detailbanner轮播图表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?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8 username: root password: yourpassword hikari: maximum-pool-size: 10 minimum-idle: 5 connection-timeout: 30000useSSLfalse为什么要加后面部署篇会提到这里先记住不加它新版本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 环境准备与版本匹配的坑开始之前先把环境对齐我自己在这块踩过不少坑尤其是版本匹配问题。建议的版本组合如下软件建议版本说明JDK1.8稳定SpringBoot 2.x完全兼容Maven3.6依赖管理Node.js14Vue工程构建MySQL5.7或8.0二者都可注意驱动差异SpringBoot2.7.x不要直接上3.x除非你想折腾Vue CLI4.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/htmlNginx配置里把/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上追加useSSLfalse告诉连接器不需要做SSL握手。同样常见的另一个参数是serverTimezoneAsia/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导出订单等进阶功能每一个都能在论文和答辩中多出一个亮点。