简介面向高校毕业设计、课程设计及需要完整前后端项目参考的开发者这是一套基于JAVASpringBootVueMySQL的日常办公用品直售系统用于满足线上采购、商品管理与订单处理等真实场景的实战需求。项目涵盖商品展示、购物车、订单处理、用户管理及支付结算等核心模块界面简洁操作流程直观后台可便捷维护商品与订单数据整体功能完整且具备较高的实际应用价值开发环境采用IDEA、Maven、Navicat数据库需MySQL5.7以上技术栈成熟便于环境搭建与部署。压缩包共597个文件以java源码、vue前端页面、JavaScript逻辑、CSS样式及SQL数据库脚本为主辅以XML配置、项目文档和运行脚本资源内附项目源码、数据库脚本及工具前后端代码完整便于直接导入与二次开发。整体包大小16.1MB结构清晰适合对照学习目前已有39人学习下载经过严格调试确保可运行能够为快速完成毕设演示或商城类项目实战提供有效支撑。1. 日常办公用品直售系统为什么我先做“下单闭环”再做页面做过办公用品采购的人都知道一笔A4纸、签字笔的报销单背后是一堆电话、邮件和Excel表而直售系统要做的事就是把“看商品、加购物车、下单、付款、后台发货”这条闭环打通。这套基于JAVASpringBootVueMySQL的日常办公用品直售系统不是一个花架子页面而是一个能跑通“用户端选购—管理端处理订单—结算对账”全流程的高分毕设项目。它适合两类人需要课程设计和期末大作业的在校学生以及想快速搭建内部采购商城、又不想从零造轮子的中小团队。2. 总体架构设计前后端分离下的四层结构与订单主链路拿到这个项目的第一件事不是看某个页面好不好看而是先理解它的分层结构。日常办公用品直售系统把前端和后端分成两个独立工程前端负责页面渲染和交互后端负责提供接口和业务逻辑两者通过JSON格式的REST接口通信。这样拆分的好处是前端可以单独调试后端可以单独写测试后续如果要做小程序或移动端后端接口可以直接复用不需要重写一套代码。2.1 架构分层与一次请求的完整流转系统整体上可以看作四层表现层、接口层、业务层、数据层。表现层是Vue单页应用由路由和组件构成用户看到的所有页面都在这层。接口层是SpringBoot的Controller负责接收前端请求、参数校验、调用业务层、返回统一格式数据。业务层是Service承载购物车计算、订单生成、库存扣减这类核心逻辑。数据层是Mapper与MySQL负责把数据持久化到数据库。一次“添加购物车”的请求会从前端的购物车组件发起经过Vue Router跳转、axios封装到达后端ControllerController调用ServiceService操作Mapper完成记录写入最后返回成功结果给前端刷新数量。整个过程就是一条单向链路每层只做自己的事出了问题也能按层排查。后端工程里通常会有这样的包结构src/main/java/com/office/shop ├── config # 跨域、拦截器、静态资源映射 ├── controller # 商品、购物车、订单、用户等接口 ├── service # 业务逻辑下单事务在这里 ├── mapper # MyBatis接口或JPA Repository ├── entity # 数据库实体类 ├── common # 统一返回体、异常处理、工具类 └── OfficeApplication.java # 启动类接口层统一返回Result对象包含code、message、data三个字段。前端只需要判断code是否为200不需要各自解析不同的返回格式这个约定看起来简单却能在联调时省掉大量对字段名的扯皮。2.2 功能模块拆分用户端、管理端与六大核心模块从使用者角度系统分成用户端和管理端两端。用户端面向普通员工提供注册登录、首页商品展示、商品详情、购物车、结算支付、订单查询管理端面向后台管理员提供商品管理、订单管理、用户管理、统计概览。核心模块可以拆成六个商品展示模块、购物车管理模块、订单处理模块、用户管理模块、支付结算模块、后台管理模块。商品展示模块负责按分类展示办公用品每件商品包含图片、名称、价格、库存和描述购物车模块支持添加、删除、修改数量、自动计算小计订单模块负责生成订单号维护待支付、已支付、已发货、已完成、已取消几种状态用户模块区分普通用户和管理员角色支付结算模块在毕设中通常用模拟支付页面代替真实第三方。六个模块之间的依赖关系也很清楚用户必须先登录才能操作购物车购物车确认后才能生成订单订单支付后才能流转到发货完成。所以在演示或者答辩时一定要按这条主流程走不能跳步。2.3 技术栈选型SpringBoot、Vue、MySQL在项目里的分工这套系统的技术组合是经过实际对比后确定的。SpringBoot负责后端它内置Tomcat自动配置依赖用Maven管理jar包避免了传统SSH项目里一大堆XML配置的麻烦。Vue负责前端采用组件化开发页面上的商品卡片、购物车列表、分页栏都可以拆成一个独立组件改一处不会影响其他区域。MySQL负责存储用Navicat可以可视化建表、导数据、查看订单记录对答辩演示也很友好。开发工具方面IDEA是主力开发环境Maven负责项目构建和依赖下载Navicat管数据库。这些工具解决的是开发和调试效率问题不是运行依赖所以部署时可以不用它们。有一点需要提前说清楚MySQL需要用5.7以上版本太老的版本在某些字段默认值、索引处理上会和新代码有差异容易出现“本地没问题换到同学电脑就报错”的情况。3. 数据库与后端实现五张核心表和SpringBoot接口落地数据库设计决定了这套系统能不能支撑起完整的购物流程。很多毕设翻车都翻在表结构上要么字段太少存不下信息要么订单和商品之间没有明细表导致一个订单只能存一件商品。这套系统在数据库层面用了五张核心表分别是用户表user、商品表product、购物车表cart、订单表orders和订单明细表order_item用逻辑关联代替物理外键既能保证查询效率又方便误删数据时做恢复。3.1 数据库表结构用户、商品、购物车、订单与订单明细下面是我在项目里常用的一份建表SQL字段做了精简但足够覆盖业务主流程CREATE DATABASE office_shop DEFAULT CHARSET utf8mb4; USE office_shop; CREATE TABLE user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, real_name VARCHAR(50), phone VARCHAR(20), role TINYINT DEFAULT 0, -- 0普通用户 1管理员 create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE product ( id BIGINT PRIMARY KEY AUTO_INCREMENT, category_id BIGINT, name VARCHAR(100) NOT NULL, description VARCHAR(500), image VARCHAR(200), price DECIMAL(10,2) NOT NULL, stock INT DEFAULT 0, status TINYINT DEFAULT 1, -- 1上架 0下架 create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE cart ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, product_id BIGINT NOT NULL, quantity INT DEFAULT 1, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE, user_id BIGINT NOT NULL, total_price DECIMAL(10,2) NOT NULL, status TINYINT DEFAULT 0, -- 0待支付 1已支付 2已发货 3已完成 4已取消 receiver VARCHAR(50), address VARCHAR(200), phone VARCHAR(20), pay_time DATETIME, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE order_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, product_id BIGINT NOT NULL, product_name VARCHAR(100), price DECIMAL(10,2), quantity INT );为什么订单表要拆成orders和order_item两张表因为一个订单可能包含多件商品比如“签字笔十支、笔记本五本”应该在同一个订单里。如果把商品信息直接拼到订单表里查询和统计都会变得很痛苦。订单明细表里冗余了product_name和price字段看上去有点重复但这是故意的商品表里的价格如果改了历史订单里的成交价应该保持不变否则后续对账会对不上。这个细节在答辩时主动讲出来是加分项。3.2 SpringBoot实体与Mapper用MyBatis还是Spring Data JPA这个项目选择的是MyBatis风格配合Maven引入依赖SQL由自己编写执行过程更加透明。实体类可以直接对应数据库字段例如User实体Data public class User { private Long id; private String username; private String password; private String realName; private String phone; private Integer role; private LocalDateTime createTime; }我一般在项目里加上Lombok的Data注解省去getter/setter的样板代码。需要提醒的是MySQL字段如果用的是下划线分隔的real_nameJava实体需要配置mapUnderscoreToCamelCase否则查询回来realName为空。这个配置写在application.properties里一行就能解决mybatis.configuration.map-underscore-to-camel-casetrue如果不加这一行数据库列名和Java驼峰属性对不上最容易出现的现象是数据库里明明有值接口返回的字段却是null而且控制台一点报错都没有。3.3 核心接口实现商品列表、购物车与下单事务后端接口遵循RESTful风格前端传参通过JSON返回统一Result对象。以商品列表接口为例RestController RequestMapping(/api/product) public class ProductController { Autowired private ProductService productService; GetMapping(/page) public Result page(RequestParam(defaultValue 1) Integer page, RequestParam(defaultValue 10) Integer size) { return Result.success(productService.page(page, size)); } GetMapping(/detail/{id}) public Result detail(PathVariable Long id) { return Result.success(productService.getById(id)); } }Controller只负责接收和返回真正的查询在Service里处理这样便于对每个方法做事务控制。再来看下单方法这是整个系统最需要谨慎的地方因为它同时要写订单表、明细表、扣库存、清空购物车任何一步失败都必须回滚Service public class OrderServiceImpl implements OrderService { Autowired private OrderMapper orderMapper; Autowired private OrderItemMapper orderItemMapper; Autowired private ProductMapper productMapper; Autowired private CartMapper cartMapper; Transactional(rollbackFor Exception.class) public Long createOrder(Long userId, ListCartDTO cartList) { BigDecimal total BigDecimal.ZERO; for (CartDTO item : cartList) { Product product productMapper.findById(item.getProductId()); if (product null || product.getStock() item.getQuantity()) { throw new RuntimeException(商品库存不足); } total total.add(product.getPrice() .multiply(BigDecimal.valueOf(item.getQuantity()))); } Orders order new Orders(); order.setOrderNo(generateOrderNo()); order.setUserId(userId); order.setTotalPrice(total); order.setStatus(0); orderMapper.insert(order); for (CartDTO item : cartList) { Product product productMapper.findById(item.getProductId()); OrderItem orderItem new OrderItem(); orderItem.setOrderId(order.getId()); orderItem.setProductId(product.getId()); orderItem.setProductName(product.getName()); orderItem.setPrice(product.getPrice()); orderItem.setQuantity(item.getQuantity()); orderItemMapper.insert(orderItem); productMapper.deductStock(product.getId(), item.getQuantity()); cartMapper.deleteByUserAndProduct(userId, product.getId()); } return order.getId(); } }这段代码有几个关键点。Transactional保证整个方法在同一事务里如果库存扣减失败订单和明细不会残留。金额计算用BigDecimal而不是double避免浮点数精度问题导致金额对不上。库存判断和扣减要连在一起做最好在SQL里加一个stock quantity条件防止多人同时下单造成超卖。在答辩时把这个“先校验库存、再扣减”的细节讲出来能证明你真的考虑过并发问题。3.4 登录鉴权拦截器与统一返回体系统里有普通用户和管理员接口必须做权限控制否则任何人都能调用后台接口删除商品。通常的做法是登录成功后生成一个Token返回给前端前端在后续请求的Header里带上Token后端通过拦截器统一校验。public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || !JwtUtil.validate(token)) { response.setStatus(401); return false; } return true; } }拦截器注册到配置类里再设置放行路径登录、注册、商品列表和详情不需要Token购物车、订单、后台管理接口必须带Token。这样权限逻辑集中在一个地方不会散落在每个Controller里。实际项目中还会区分管理员接口和普通用户接口管理员接口在拦截器后面再加一层角色判断确保普通用户拿到Token也访问不了后台。4. 前端交互与订单流程Vue组件与购物车状态管理前端这套Vue项目是典型的单页应用页面路由切换由Vue Router控制公共状态统一放到Vuex里管理。目录结构里会看到IndexMain.vue、IndexHeader.vue、BreadCrumbs.vue以及一批以.bak结尾的备份文件比如IndexAsideStatic.vue.bak、update-password.vue.bak这些是开发过程中调整布局遗留的历史版本不影响编译也可以直接忽略。见到.bak文件不用慌它们不是多余代码而是我迭代过程中的“后悔药”改乱了随时能翻回上一版。4.1 前端目录与页面组织src ├── api # axios接口封装 ├── assets # 静态资源 ├── components # 公共组件Header、Footer、BreadCrumb、分页 ├── router # 路由配置 ├── store # Vuex状态 ├── views │ ├── home # 首页与商品列表 │ ├── product # 商品详情 │ ├── cart # 购物车 │ ├── order # 订单确认、支付、订单列表 │ ├── user # 登录、注册、个人中心 │ └── admin # 商品管理、订单管理、用户管理 └── App.vue页面按功能域拆到views目录每个目录里放自己的组件。登录页和注册页放在user目录后台管理页面放在admin目录这样路由和文件路径一一对应拿到项目的人能在几秒钟内找到对应代码而不需要全工程搜索页面标题。4.2 购物车状态管理为什么用Vuex而不是组件内部变量购物车有一个特点Header角标要显示数量购物车页面要显示列表结算页要显示总价如果每个组件各自保存一份购物车数据用户一边改数量一边切页面数据就会不一致。所以购物车状态要放到Vuex里让所有组件读取同一份数据。// store/modules/cart.js const state { cartList: [], totalPrice: 0 }; const mutations { SET_CART_LIST(state, list) { state.cartList list; state.totalPrice list.reduce((sum, item) { return sum item.price * item.quantity; }, 0); }, UPDATE_QUANTITY(state, { index, quantity }) { state.cartList[index].quantity quantity; state.totalPrice state.cartList.reduce((sum, item) { return sum item.price * item.quantity; }, 0); } }; const actions { fetchCart({ commit }) { return api.getCart().then(res { commit(SET_CART_LIST, res.data); }); } };购物车数量变更后不需要重新请求后端前端先把Vuex里的总价重新算一遍操作体验会非常流畅。真正提交订单时再把cartList发给后端重新计算金额以后端为准。这样既保证了显示速度又避免了前端篡改金额的风险。4.3 订单结算从购物车到模拟支付的完整流程用户点击“去结算”后前端要做的事包括从Vuex取出购物车数据跳转到订单确认页展示商品清单和总价填写收货人和地址点击提交订单然后调起支付页面。这里的支付在毕设项目中通常不会真正对接支付宝或微信支付而是用一个模拟支付页面点击“确认支付”后直接调用后端的支付接口把订单状态从0改成1。async function submitOrder() { const res await api.createOrder({ userId: user.id, items: cartList.map(item ({ productId: item.productId, quantity: item.quantity })), receiver: form.receiver, address: form.address, phone: form.phone }); if (res.code 200) { const orderId res.data; // 跳转到模拟支付页 router.push({ path: /pay, query: { orderId } }); } } async function payOrder(orderId) { const payRes await api.pay(orderId); if (payRes.code 200) { store.commit(CLEAR_CART); router.push({ path: /order/list }); } }这段逻辑有一个常见问题用户可能多次点击提交按钮导致生成多个订单。前端要在按钮上做防重复提交比如提交后立刻禁用按钮同时后端也要在createOrder方法里做幂等处理最直接的办法是生成一个前端请求唯一标识后端校验这个标识是否已处理过。另外支付完成后必须清空Vuex里的购物车同时调用后端清空数据库购物车两边保持一致否则用户下次进购物车会看到已经买过的东西。4.4 前后端联调跨域配置与接口字段对齐前端开发服务器和后端接口服务器端口不同浏览器会拦截跨域请求。最省事的开发方案是在后端配置允许跨域Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOrigins(http://localhost:8081) .allowedMethods(GET, POST, PUT, DELETE) .allowedHeaders(*); } }联调过程中最常翻车的地方不是跨域而是字段名对不上。后端返回的是orderNo前端写的是orderNo明明看起来一样但就是取不到值。这种问题大多是驼峰和下划线混用造成的建议前后端统一使用驼峰命名所有接口注释写清楚返回结构像拿到order列表这种接口直接在注释里粘贴一份返回JSON示例比自己翻代码快得多。5. 部署运行与常见问题排查从环境配置到启动脚本的避坑清单很多同学下载项目后第一步就卡在跑不起来。这不是代码问题而是环境差异。这套系统依赖JDK、Maven、MySQL、Node.js每个环节的版本不对都可能起不来。我一般会把运行步骤固定下来按顺序执行能避免90%的翻车。5.1 环境版本与启动顺序数据库使用MySQL 5.7以上版本开发环境用Navicat导入数据库脚本。后端用IDEA打开springboot后端工程等待Maven下载依赖然后修改application.properties里的数据库用户名密码。前端用命令进入vue工程目录安装依赖再启动开发服务器。# 前端工程目录 npm install npm run serve # 后端IDEA中直接运行Application启动类或者执行打包 mvn clean package java -jar target/office-shop.jar项目压缩包里会看到run.bat和build.bat开发时还可以用2-run.bat启动后端、3-build.bat打包前端这些脚本帮我省掉了每次重复输入命令的麻烦。脚本本质就是把上面几行命令封装成可点击的文件如果你在别的电脑上运行需要先确认脚本里的路径和本机环境一致。5.2 启动后如何验证系统正常后端启动日志出现“Started OfficeApplication in xx seconds”说明成功。前端启动后浏览器访问开发地址能看到首页商品列表说明基础页面通了。然后做一次“登录—加购—下单”的完整操作确认订单表里出现状态为0的记录说明前后端和数据库链路是通的。如果页面出来了但接口报错优先看浏览器F12里的Network面板看请求是否发出去、返回HTTP状态码是多少。看不懂接口报错时再切到后端控制台找异常堆栈。我见过太多人只盯着页面完全没有看后端日志的习惯导致一个小问题排查几个小时。5.3 五个最容易翻车的问题与排查办法下面按“现象→原因→解决”的方式列出项目里最容易踩的坑。第一个是数据库连接失败。现象后端启动时报错Access denied for user rootlocalhost或者Communications link failure。原因账号密码配置错误或者MySQL服务没启动。解决确认application.properties里spring.datasource的url、username、password和本机一致本地没装MySQL的先启动服务或改用Docker启动MySQL容器再测试Navicat能连上后端才能连上。第二个是时区报错。现象启动后插入数据的时间字段差8小时或者控制台提示serverTimezone异常。原因MySQL驱动和系统时区不一致。解决在数据源URL后面加上serverTimezoneAsia/ShanghaiuseUnicodetruecharacterEncodingutf8同时确认索引、字段排序规则使用utf8mb4。第三个是离职再导入项目时前端依赖版本冲突。现象npm install报错或者启动后console有红色报错。原因package.json的依赖版本和当前Node版本不兼容。解决删除node_modules目录和package-lock.json重新执行npm install不要手动修改依赖版本号因为项目源码里锁定的组合是经过验证的。第四个是登录后刷新页面就退出。现象用户登录成功但按F5刷新后回到登录页。原因Token只存在内存里没有持久化到localStorage或sessionStorage。解决登录成功后把Token存到localStorageaxios拦截器里每次从localStorage取Token并加到请求Header路由守卫里只有发现localStorage里没有Token才跳登录页。第五个是后台管理页面操作后列表不刷新。现象新增商品后列表页没有出现新数据。原因新增成功后没有重新调用查询接口或者调用时机不对。解决在新增成功后调用fetchList()重新拉取当前页数据而不是只操作当前数组。这里还要顺带检查分页组件当前页数和数据条数设置避免新增后被分页逻辑挡住看不到。6. 验收与答辩功能用例与演示主流程6.1 功能验收用例表答辩前先按下面这张表过一遍能快速确认系统没有漏功能模块操作步骤预期结果注册登录注册新用户用新账号登录能正常进入首页个人信息正确显示商品展示打开首页点击商品进入详情商品图片、价格、库存、描述完整展示购物车将两件商品加入购物车修改数量购物车总价随数量变化角标数量正确下单支付购物车结算填写地址确认支付生成订单号订单状态变为已支付购物车清空订单查询进入我的订单列表能看到最新订单状态符合当前流程后台管理管理员登录新增商品并上架用户端首页出现新商品下架后消失6.2 答辩演示的一条主流程演示时一定要让评委“看懂一个完整业务闭环”而不是零散地点几个页面。我通常这样演示先用普通账号登录从首页挑选一件商品加入购物车修改数量再添加第二件商品然后结算、填写收货地址、确认支付最后切换到管理员账号在后台看到这笔订单并完成发货。再回到用户端查看订单状态变成已发货。这条链路走完系统的主要模块都被覆盖了评委能直观感受到项目是完整的。6.3 被追问时的应对技巧评委最常问的问题有三个支付是怎么实现的、订单并发怎么处理、为什么用前后端分离。回答时不用回避支付是模拟支付真实对接需要商户号和签名机制并发问题通过减少库存的SQL条件和事务控制来解决目前单体架构适合中小规模真要上高并发需要引入Redis和消息队列。坦率说明设计边界比强行吹嘘更有可信度。从那以后我每次做这类系统都会先跑通主流程再打磨页面答辩前把闭环完整走一遍希望帮到你。本文还有配套的精品资源点击获取