能跑起来和能上线跑得好是两个世界。手头拿到一份标注着“SpringBoot后端Vue前端MySQL【可直接运行】”的Web电子产品销售系统源码时我的第一反应不是急着双击 jar而是先把工程结构和配置文档翻了一遍。这类系统在大学课程设计、Java实训、个人简历项目里出镜率极高核心价值是让你在最短时间内跑通一个包含登录、商品、购物车、订单的完整电商闭环。这篇文章就从“拿到源码之后怎么办”的角度出发讲讲这套系统怎么落地、怎么改、怎么避开我踩过的坑。1. 项目概览这套电子商城源码实际解决了什么问题1.1 功能模块与适用人群先别急着谈技术细节你拿到这套源码第一件要搞清楚的事是它帮你完成了哪些功能。一套Web电子产品销售系统本质上就是一个简化版电商平台前台给用户逛后台给管理员管。我实际跑下来的功能清单大概是下面这张表模块前台用户看到的能力后台管理员看到的能力用户体系注册、登录、退出用户列表、状态禁用商品中心分类浏览、模糊搜索、商品详情商品增删改、上下架、库存调整购物车加购、改数量、勾选结算不直接参与订单流程提交订单、支付模拟、查看状态订单列表、发货操作数据支撑热销商品、分类导航基础统计或运营数据这个范围对大多数课设和实训项目来说刚好。太多业务会写到崩溃太少又撑不起答辩时那句“我的系统功能完善”。如果你是刚学完SSM或者刚入门SpringBoot的学生这套系统的代码量不会让你望而生畏如果你已经是工作中的人把它当脚手架来改造也很方便比如给第三方支付或者物流查询留出扩展位。1.2 技术栈组合为什么这么搭SpringBoot负责后端接口Vue负责前端页面MySQL负责数据存储这套组合在Java生态里已经是“标准答案”级别。为什么不是JSP为什么不是纯Servlet因为这套源码要解决的不是“能不能访问”而是“前后端是否分离、后期是否好维护”。SpringBoot让你用最少的XML配置把一个Web工程跑起来内嵌Tomcat打包后一个jar直接执行这对新手极其友好。Vue把页面拆成组件商品列表、商品卡片、购物车这些UI模块可以复用不用像传统JSP那样一个页面堆满Java代码。MySQL则负责把商品价格、库存、订单状态这类强关系数据稳稳落地。三者的分工就像门店、店员和仓库前端是门面后端是收银台数据库是货架缺一个整个交易流程都转不动。2. 数据库设计商品、订单、用户是三个核心圆环2.1 表结构整体规划很多人拿到源码后第一步就去看Controller和Service这是错误的顺序。你先应该打开数据库脚本看看有哪些表表跟表之间怎么关联。表结构一旦理解后端所有接口都会变得非常好懂。这套系统的核心表基本会落在这些上用户表、商品分类表、商品表、购物车表、订单表、订单明细表可能还有收货地址表和管理员表。商品的分类用外键关联订单与订单明细用一对多关系订单里的商品信息不能简单只放一个product_id还要冗余商品名称、图片、价格因为商品可能改价、甚至可能被删除订单必须保留下单那一刻的快照。“购物车里面的商品数量和库存是两回事”这个点也值得跟评委掰扯清楚购物车是用户在结算前的临时意愿库存是商品真实剩余量。真正扣减库存的时刻是用户点击“提交订单”那一刻而不是加入购物车那一刻。2.2 商品表和订单表建表核心逻辑数据库脚本里商品表的核心字段大概是这样的CREATE TABLE product ( id INT NOT NULL AUTO_INCREMENT, name VARCHAR(120) NOT NULL COMMENT 商品名称, category_id INT NOT NULL COMMENT 分类id, main_image VARCHAR(255) DEFAULT NULL COMMENT 商品主图, detail TEXT COMMENT 商品详情, price DECIMAL(10,2) NOT NULL COMMENT 实际售价, original_price DECIMAL(10,2) DEFAULT NULL COMMENT 原价用于划线价展示, stock INT NOT NULL DEFAULT 0 COMMENT 库存, sales INT NOT NULL DEFAULT 0 COMMENT 销量, status TINYINT NOT NULL DEFAULT 1 COMMENT 1上架 0下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_category (category_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里我特别提醒几个细节价格一定用DECIMAL不要用FLOAT或DOUBLE否则金额精度会出问题钱的事开不得玩笑status字段用TINYINT比用VARCHAR省空间也好判断排序按销量sales来排适合热销推荐场景外键在大型互联网公司里可能不建但在课设和中小系统里加索引分析要比纠结物理外键更实用。订单表会把总金额、收货人、收货电话、收货地址这些信息直接冗余下来订单明细表再记录当时的快照CREATE TABLE order_item ( id INT NOT NULL AUTO_INCREMENT, order_id INT NOT NULL, product_id INT NOT NULL, product_name VARCHAR(120) NOT NULL, product_image VARCHAR(255) DEFAULT NULL, price DECIMAL(10,2) NOT NULL, quantity INT NOT NULL, subtotal DECIMAL(10,2) NOT NULL, PRIMARY KEY (id), KEY idx_order (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;订单总金额一般在前端展示时汇总后端再次从明细里算一遍避免前端篡改价格。2.3 库存扣减的安全做法电商系统最容易被挑剔的点就是库存。如果你写的逻辑是“先查库存再判断是否大于购买数量然后更新”在高并发下一定会超卖。为什么两个请求同时查到库存为5都认为可以买3件最后库存可能变成2甚至负数但订单却生成了两份。在这套源码里如果作者用了如下这种带条件的UPDATE就比较安全UPDATE product SET stock stock - #{quantity}, sales sales #{quantity} WHERE id #{id} AND stock #{quantity};这条SQL把“检查库存”和“扣减库存”合并成一个原子操作数据库行锁会保证同一时间只有一个请求能成功更新这条商品记录。如果返回影响行数是0就意味着库存不足或商品被下架后端直接抛出异常。这个思路叫乐观锁的一种落地变体不需要引入复杂的分布式锁课设阶段完全够用而且说出来能体现你对并发问题的理解。3. 后端落地SpringBoot的分层、鉴权与核心接口3.1 工程目录里藏着哪些关键包打开后端工程不要被几十个Java文件吓到。成熟的SpringBoot项目目录结构是固定的顺着包名走就能摸清逻辑com.example.mall ├── config // 配置类例如WebMvcConfig、拦截器注册 ├── controller // 控制器接收前端请求 ├── service // 业务层处理具体逻辑 │ └── impl ├── mapper // 数据访问层MyBatis或MyBatis-Plus接口 ├── entity // 数据库实体类 ├── common // 公共返回体、异常处理、工具类 └── MallApplication.java重点看common里的统一返回体。比如返回结构是{ code: 0, msg: success, data: ... }前端axios就能统一拦截处理不用每个接口各写一套判断。config里的拦截器控制哪些接口需要登录哪些接口公开比如注册、登录、商品列表、商品详情通常公开下单、购物车、订单列表必须走鉴权。3.2 JWT登录鉴权流程我见过很多课设系统用Session做登录PageHelper分页配Session也能跑通但一旦前后端分离浏览器和服务器不在同一个端口Session的跨域问题会让人炸毛。这套源码如果用的是Token方案那就省心很多。常规流程如下用户提交用户名密码后端用BCrypt校验密码校验通过后签发一个JWT字符串返回给前端前端存到localStorage里之后每一次请求都在Header里带上Authorization后端拦截器解析这个Token。核心拦截器代码大概长这样Component public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (StringUtils.hasText(token) JwtUtil.verify(token)) { return true; } response.setStatus(401); return false; } }注册拦截器时要排除公开接口Configuration public class WebConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new AuthInterceptor()) .addPathPatterns(/api/**) .excludePathPatterns(/api/user/login, /api/user/register, /api/product/list, /api/product/*); } }这里有个常见坑JWT里的过期时间设置。设置太短用户逛几下就被踢出去设置太长安全性差。课设场景建议2小时起步管理员接口可以单独再校验一次角色不用死磕“无状态”这个理论。3.3 商品列表分页接口实现商品列表是PC端最核心的接口一个接口通常要同时处理分类筛选、关键字搜索、分页、排序。如果用了MyBatis-Plus代码会非常清爽Override public PageProduct queryPage(int page, int size, Integer categoryId, String keyword) { LambdaQueryWrapperProduct wrapper new LambdaQueryWrapper(); if (categoryId ! null) { wrapper.eq(Product::getCategoryId, categoryId); } if (StringUtils.hasText(keyword)) { wrapper.like(Product::getName, keyword); } wrapper.orderByDesc(Product::getSales); return productMapper.selectPage(new Page(page, size), wrapper); }注意分页页码从1开始这是前端传来的习惯值size要限制最大不能超过100否则有人恶意传入10000会把数据库拖垮。商品详情接口建议单独实现因为列表不需要查detail大字段详情页才需要避免列表查询时把一堆长文本加载出来拖慢响应。3.4 下单接口事务与库存要一起处理订单流程是这套系统的“心脏”。用户从前端购物车勾选商品点击结算后端要做以下几件事生成订单主记录、生成订单明细快照、扣减库存、清空已结算购物车。中间任何一步失败都不能出现“订单生成了但库存没扣”或者“库存扣了但订单没生成”的脏数据。所以下单接口必须加事务注解Transactional(rollbackFor Exception.class) public Order createOrder(OrderCreateDTO dto, Integer userId) { Order order new Order(); order.setOrderNo(SO System.currentTimeMillis() userId); order.setUserId(userId); // 计算金额、写入收货地址快照... orderMapper.insert(order); for (CartItemVO item : dto.getItems()) { Product p productService.getById(item.getProductId()); int rows productMapper.deductStock(p.getId(), item.getQuantity()); if (rows 0) { throw new BizException(商品[ p.getName() ]库存不足); } // 插入 order_item累加 totalAmount... } cartService.removeCheckedItems(userId, itemIds); return order; }为什么要写rollbackFor Exception.class因为Spring默认只在遇到RuntimeException时回滚如果业务代码里异常被捕获又转成检查异常抛出事务可能不会回滚。建议你把自定义的BizException继承RuntimeException并且统一用全局异常处理类接收这样前端拿到的永远是结构一致的错误提示。4. 前端落地Vue页面、路由与接口联调4.1 Vue初始化与开发环境搭建前端工程拿到手先检查本地环境。Node版本太旧或太新都会导致依赖装不上建议使用LTS版本。安装依赖用npm install如果之前装过带有版本锁定的依赖用npm ci会更稳定。源码若用的是Vite启动命令是npm run dev若用Vue CLI启动命令同样是npm run serve但底层构建速度差距明显Vite热更新在开发体验上确实舒服很多。项目里的Vite配置要尤其关注。开发环境下前后端端口不一样前端3000端口后端8080端口直接请求肯定跨域。解决方案是在vite.config.js里配代理import { defineConfig } from vite import vue from vitejs/plugin-vue export default defineConfig({ server: { port: 3000, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })这样前端代码里请求/api/product/list开发服务器会自动转发到http://localhost:8080/api/product/list浏览器端不会出现跨域报错。4.2 路由设计与导航守卫Vue Router是前端的神经系统。这套商城的路由我建议分成两块用户端和管理端。用户端包括首页、商品列表、商品详情、购物车、订单结算、订单列表、登录注册管理端包括商品管理、分类管理、订单管理、用户管理。路由不该全堆在一起可以按模块拆文件。导航守卫控制页面访问权限这是一个看起来很细但必须做的点router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { next(/login) } else if (to.path /admin localStorage.getItem(role) ! ADMIN) { next(/) } else { next() } })路由传参一定要分清楚。商品详情页跳转用/product/${id}路径参数更符合语义刷新页面不会丢参数如果存到query里会暴露在URL上刷新虽然不会丢但观感差一些。具体到这套系统this.$router.push({ path: /product/ id })是标准做法。4.3 axios封装与代理配置每个前端页面都直接调用axios会写死大量重复代码。把网络请求统一封装成模块是这套源码里值得保留的工程习惯import axios from axios import { ElMessage } from element-plus import router from /router const service axios.create({ baseURL: /api, timeout: 8000 }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization token } return config }) service.interceptors.response.use( response { const res response.data if (res.code ! 0) { ElMessage.error(res.msg) return Promise.reject(new Error(res.msg)) } return res.data }, error { if (error.response error.response.status 401) { router.push(/login) } return Promise.reject(error) } ) export default service一个重点如果baseURL写成了完整的http://localhost:8080/api那么在开发环境里即便配了Vite代理也没用因为请求不会经过前端开发服务器而是直接打到后端跨域一样会出现。这是我见过最隐蔽的联调问题——代理配了网络请求还是能飞到后端但浏览器拦截了Response整个页面白屏控制台报CORS错误。调试思路是优先让请求路径保持相对路径把跨域问题全部交给代理层处理。4.4 购物车和订单页面怎么互相配合购物车数据不应该只放在组件内部因为用户刷新页面后购物车就没了。常见做法是前端存localStorage或者后端在用户登录状态下把购物车同步到数据库购物车表。这套源码里如果购物车是后端表那么商品数量变化要实时请求更新接口如果是前端存储结算时要把勾选商品明细一次性传给后端。从工程化角度我更偏向后端购物车表因为数据可持久化换设备登录也能看到购物车而且库存不足这种错误可以在勾选时提前提示而不是等到下单才报错。不过后端购物车表意味着每个加购操作都要调一次接口代码量略多。你可以打开源码先确认它采用的是哪一种再决定要不要改造不建议两手抓复杂度会翻倍。5. 本地运行与上线打包从源码到可访问5.1 初始化数据库和配置文件拿到手先创建数据库并导入SQL脚本。MySQL安装好后命令行执行mysql -u root -p CREATE DATABASE electronic_mall DEFAULT CHARACTER SET utf8mb4; USE electronic_mall; SOURCE /your/path/init.sql;然后检查后端application.yml。最常出问题的三个配置项分别是数据库地址、数据库账号、数据库密码。如果本地MySQL版本是8.xURL里建议显式加useSSLfalseserverTimezoneAsia/Shanghai否则时区报错和SSL警告能烦死你spring: datasource: url: jdbc:mysql://localhost:3306/electronic_mall?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver注意MySQL 5.7和8.0的驱动类名不一样老项目用com.mysql.jdbc.Driver在MySQL 8下会报错新版驱动是com.mysql.cj.jdbc.Driver。如果你用SpringBoot 2.7以上的版本其实可以省略driver-class-name让框架根据URL自动推断。5.2 后端启动步骤后端有两种启动方式。开发时在IDEA里直接运行MallApplication.java即可如果要模拟生产环境先打包mvn clean package -DskipTests java -jar target/mall-0.0.1-SNAPSHOT.jar这里分享一个经验尽量不要用SpringBootApplication里直接写spring.profiles.activeprod这种硬编码而是打包后用命令行指定java -jar mall.jar --spring.profiles.activeprod这样本地用dev配置部署用prod配置一份代码跑两个环境数据库密码也不用写死在配置文件里。源码里如果这一步没做你可以自己加一个application-dev.yml和application-prod.yml也算一个不错的优化点。5.3 前端启动步骤前端开发模式下运行npm install npm run dev如果是构建生产包npm run build打包产物在dist目录下里面是静态HTML、CSS和JS。如果你的后端接口地址是/api开头那么部署时只需要把静态文件交给nginx把/api请求反代给SpringBoot就能实现前后端同域名访问不会再有跨域问题。nginx配置大致如下server { listen 80; server_name yourdomain.com; location / { root /opt/mall/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }最后那行try_files非常重要因为Vue是前端路由用户访问/product/12这个路径时服务器上并没有这个目录文件需要让它回到index.html由前端路由接管。不配这行刷新详情页就会404。5.4 前后端分离部署的两种方式如果你的服务器资源紧张或者目标环境是课程设计演示推荐直接在服务器上跑一个jar再用nginx托管前端静态文件。后端和前端其实是两个独立进程互相之间只通过HTTP通信这就是前后端分离的核心好处。如果你不想装nginx也可以用SpringBoot的resource目录存放前端打包产物把dist内容复制到/src/main/resources/static这样最终只有一个jar启动后直接访问同一个端口。这种方式适合快速演示但不适合正式项目因为前端小版本更新也得重新打jar包工程化程度太低。我更推荐nginx方案改前端页面只需要替换静态文件然后reload nginx完全不用碰后端。6. 踩坑记录我把常见问题按现象整理成速查表6.1 典型问题速查表跑这套源码过程中无论是自己写还是改别人的大概率会遇到下面这些问题。我按“现象-原因-解决”三步整理成一张表你遇到问题直接对照着查现象大概率原因解决方法前端白屏控制台报404npm run build产物没配try_filesnginx加try_files $uri $uri/ /index.html;控制台报CORS跨域axios baseURL写死成后端地址改为相对路径/api交给代理转发后端启动报端口占用8080被某个进程占用改application.yml的server.port或kill进程数据库连接报拒绝密码错误或url host不对核对application.yml里数据库账号密码时间字段差8小时MySQL时区没设置URL加serverTimezoneAsia/Shanghai图片裂掉图片路径存的是绝对路径或旧域名统一改成相对路径或把图片放到静态资源目录登录后调接口401Token过期或Bearer前缀处理不一致统一在axios拦截器加Token后端按同样规则解析商品列表点第2页没反应前端页码从0开始后端从1开始统一页码约定并转换成一致的值加了商品一直进不了购物车用户未登录购物车接口走鉴权先调用登录流程再看拦截器排除路径6.2 我单独排过的三个隐蔽坑第一个坑来自JDK版本。源码如果基于SpringBoot 2.7JDK 8和JDK 11都能跑如果你本机装的是JDK 17要当心某些依赖用的反射接口在更高版本JDK里被限制启动时报“IllegalAccessError”这类错误。不是源码写错而是环境不一致。所以拿到源码先看pom.xml里的java.version本机版本要对齐省得浪费时间。第二个坑是数据库初始化脚本里的中文字符乱码。如果导入SQL时用了命令行Windows下默认编码可能不是UTF-8导入后商品名称变成乱码。解决方法是导入前执行SET NAMES utf8mb4;或者直接用Navicat选中SQL文件导入并在连接属性里把编码设成UTF-8。这个坑不影响代码但会让答辩效果大打折扣。第三个坑是前端响应式数据不更新。很多新手在购物车改数量后直接写this.cartList[index].quantity valVue的响应式系统在部分场景下不会触发更新尤其是直接按下标修改简单数组时。换成this.cartList.splice(index, 1, newItem)或者用Vue.set才稳定。这个细节在Vue 3的Proxy方案里没那么明显但如果源码是Vue 2技术栈就要格外小心。我再强调一个容易被忽略的安全点后端接口接收前端传过来的用户ID时千万不要无条件信任下单接口的userId应该从登录Token中解析而不是从请求体里拿。否则用户把请求里的userId改成别人就能冒用身份下单这种问题在答辩现场被评委点出来非常尴尬。这套系统跑通之后我通常会做三件很小的改造来提升它的完成度第一给订单号加一个全局工具类生成不要只靠System.currentTimeMillis()同毫秒并发会重复第二把商品图片上传从本地目录改成可配置的路径后端打包成jar后没有固定工作目录的情况下图片默认会存到临时目录重启就丢第三给下单接口加上库存校验的日志万一出现“库存扣成负数”的诡异现场能快速定位是哪一笔请求干的。最后再分享一个小技巧。前端构建完的dist目录里资源默认会带哈希文件名但如果你发现index.html引用的JS文件名和实际产物对不上十有八九是浏览器缓存了旧页面。演示前养成强制刷新CtrlF5的习惯或者让nginx设置add_header Cache-Control no-cache。演示功能时最怕的不是功能坏了而是功能其实是好的但演示机器里的缓存骗了你。这套项目真正的价值不在于代码有多高级而在于你能通过它理解一个Web系统从数据库到后端、再从后端到前端的数据流动。把商品、订单、用户这三个核心闭环吃透SpringBoot和Vue的课设乃至实习面试中的基础追问基本都能接得住。至于要不要继续加模块我的个人建议是先把稳定性和易用性打磨好再考虑Redis缓存热门商品、MQ异步处理订单这类进阶功能别一上来就把架构堆得太重。跑通之后顺手做的这几个小优化才是你从“会用源码”到“能讲清楚源码”的分水岭。