简介：基于JAVA+SpringBoot+Vue+MySQL开发的日常办公用品直售系统毕业设计，面向计算机专业学生，可用于毕业设计、课程设计或期末大作业；项目经导师指导并通过高分，前后端代码齐备，涵盖商品展示、购物车、订单处理、用户管理、支付结算等模块，界面简洁、操作直观、后台管理便捷。资源包共597个文件、16.1MB，包括139个Java后端源码、96个Vue前端页面、SQL数据库脚本、部署配置及开发工具说明，目录清晰，便于二次开发；部署环境为IDEA、Maven、MySQL5.7以上及Navicat。项目经严格调试确保可稳定运行，已有39人学习下载，适合需要可直接运行的高分毕设源码，或希望参考前后端分离商城系统开发流程的读者。
1. 日常办公用品直售系统：从毕设选题到可交付运行的完整方案
做过办公用品采购的人都知道，真正麻烦的从来不是下单，而是线下比价、询价、汇总、报销这一连串动作。一套基于 JAVA + SpringBoot + Vue + MySQL 的日常办公用品直售系统，想解决的就是这件事：把商品展示、购物车、订单、支付结算和管理后台装进一个完整流程里，让学生能拿它交毕设，也能让中小团队直接改成日常采购工具。这个项目适合两类人，一是正在做毕业设计或课程设计、需要一套完整且能讲清楚原理的系统来参考的同学，二是想快速搭一个直售类业务后台、验证运营流程的从业者。下文按需求分析、总体设计、核心实现、避坑排查、验收答辩的顺序拆开讲。
2. 需求分析与技术选型：核心场景、功能边界与 SpringBoot+Vue+MySQL 的组合理由
2.1 办公用品直售的真实业务场景与功能需求清单
办公用品直售系统和普通电商系统在功能上有重叠，但它有自己的特殊性。普通电商商品种类繁多、促销规则复杂、用户体量大；办公用品直售的典型场景是行政人员或普通员工购买打印纸、签字笔、文件夹这类固定品类，采购频次高、单笔金额小、商品标准化程度高，所以系统不需要海量促销引擎，反而要把“商品管理、库存状态、订单流转、用户权限”四条线做扎实。
按照这个场景推算，系统至少需要两个视角：用户端和管理端。用户端要完成注册登录、浏览商品、按分类筛选、加入购物车、修改数量、生成订单、支付结算、查看个人订单；管理端要完成商品上下架、分类维护、库存调整、订单状态管理、用户账户管理。两边加起来就是这个系统的功能全貌，也是毕设答辩时展示业务闭环的主线。
隐藏在产品背后的还有几个容易被忽略的需求。库存扣减要在下单时锁定而不是支付时才扣，避免超卖；订单状态要能在待支付、已支付、已发货、已完成之间流转并留痕；不同角色的接口要有访问控制，不能让普通用户调用管理接口。这些需求都来自办公用品采购的日常操作逻辑，不算额外加戏，但恰恰是评审老师喜欢追问的点。
2.2 技术选型：为什么是 SpringBoot 而不是 SSH，为什么前端选 Vue
SpringBoot 在这套方案里的作用是“把后端工程的复杂度压到最低”。它内嵌了 Tomcat，用 java -jar 能直接起服务，不需要单独装容器；自动配置机制免掉了一大堆 XML 配置，开发者只需要在 application.yml 里写数据源和端口；配合 Maven 做依赖管理，项目结构一眼就能看明白。对毕设来说，SpringBoot 的 MVC 分层和注解风格能清楚地展示 Controller、Service、Mapper 的调用链，评卷老师容易从代码里读出设计意图。
Vue 的作用是让前端页面具备组件化开发的能力。商品列表、购物车、订单页拆成独立组件后，数据流用 Vuex 或组件 props 传递，页面刷新时只有局部数据更新而不是整页跳转。这个系统不用引入重型状态管理库也能跑，因为业务状态集中在下单流程上，购物车的数据结构足够简单。Vue 生态里最实用的部分是 axios 请求封装和 Element UI 这类组件库，表格、表单、弹窗都是现成的，开发效率比手写 DOM 高一个量级。
MySQL 在这里负责所有业务数据的持久化，支撑商品、分类、购物车、订单、用户五类核心数据。直售业务的数据量不大，单库单表即可，MySQL 5.7 以上版本在事务支持和 UTF-8 字符集方面没有坑，navicat 可视化工具也能快速完成建库、导数据和排查。开发环境用 IDEA 写代码、Maven 管依赖、navicat 管数据库，这套工具链是当前学生和工作团队里最常见的组合，出了问题网上案例多，好排查。
3. 总体架构与数据库设计：三层链路、三类角色与核心表的字段规划
3.1 前后端分离架构下，一次完整请求的流转链路
系统采用前后端分离架构，前端 Vue 工程和后端 SpringBoot 工程独立部署，通过 HTTP 接口通信。一次商品查询请求的链路是这样的：用户浏览器打开商品列表页，Vue 组件在 created 生命周期里调用封装好的 axios 方法，向后端 Controller 发送 GET 请求；Controller 解析参数后调用 Service 层业务方法，Service 层通过 Mapper 接口操作 MySQL 数据库，查询结果一层层返回，最后在页面渲染成商品卡片。
整个链路里需要关注的三个角色是普通用户、管理员和系统本身。普通用户通过前端登录页获取 Token，后续请求带上 Token 访问自己的购物车和订单数据；管理员用户拥有额外的商品管理和订单管理接口权限；系统本身通过 Spring Security 或拦截器校验接口访问权限。前端根据角色动态渲染菜单，后端对每个接口标注访问权限，两层约束保证管理接口不会暴露给普通用户。
3.2 功能模块划分：五块核心业务与后台管理的边界
从模块角度看，系统可以分成五块核心业务：用户模块、商品模块、购物车模块、订单模块、支付模块。用户模块负责注册、登录、个人信息维护；商品模块负责分类、列表、详情、上下架；购物车模块负责加购、改数量、删条目；订单模块负责生成订单、订单状态流转；支付模块负责结算和支付回调处理。五块业务在前端对应五个功能页面，在后端对应五组 Controller 和 Service，形成清晰的对应关系。
后台管理模块与用户端模块共用底层数据库表，但在接口层进行了边界划分。管理员操作商品分类、库存和订单发货状态的接口放在 /admin 路径下，前置拦截器校验管理员身份，普通用户即使知道接口地址也无法访问。这个设计既保证了前后端兼顾，又体现了权限控制的思路，是方案里比较出彩的地方。
3.3 数据库设计：六张核心业务表的字段规划与关系
数据库设计决定了系统能不能支撑完整业务闭环。这套系统至少要包含六张核心表：用户表、商品分类表、商品表、购物车表、订单表、订单明细表。用户表存放账号和角色标识，商品分类表和商品表是一对多关系，购物车表和订单表都通过用户 ID 关联用户，订单表与订单明细表是典型的主从表结构，一个订单包含多件商品明细。
下表是六张核心表的字段规划：
| 表名 | 核心字段 | 说明 |
|---|---|---|
| user | id, username, password, role, create_time | role 区分普通用户与管理员 |
| category | id, name, sort | 商品分类，层级不多，单级即可 |
| product | id, category_id, name, price, stock, image, status | status 控制上下架 |
| cart | id, user_id, product_id, quantity | 每条记录对应购物车中的一件商品 |
| orders | id, order_no, user_id, total_amount, status, create_time | status 表示订单状态，如待支付、已支付、已发货等 |
| order_item | id, order_id, product_id, product_name, price, quantity | 下单时快照商品信息，避免价格变动影响历史订单 |
创建订单相关表的设计通常是这样：
CREATE TABLE `orders` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `order_no` VARCHAR(32) NOT NULL UNIQUE COMMENT '订单编号，前端展示用', `user_id` INT NOT NULL COMMENT '下单用户ID', `total_amount` DECIMAL(10,2) NOT NULL COMMENT '订单总金额', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0待支付 1已支付 2已发货 3已完成 4已取消', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '下单时间', KEY `idx_user_id` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `order_item` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `order_id` INT NOT NULL COMMENT '所属订单ID', `product_id` INT NOT NULL COMMENT '商品ID', `product_name` VARCHAR(100) NOT NULL COMMENT '商品名称快照', `price` DECIMAL(10,2) NOT NULL COMMENT '成交单价快照', `quantity` INT NOT NULL COMMENT '购买数量' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;字段注释里专门标出的“快照”是有讲究的。如果 order_item 直接关联 product 表，下单后商品改价或删除，订单历史就会被篡改，验收时演示“下单后改商品价格、历史订单金额不变”时就会翻车。在 order_item 里冗余商品名称和价格，属于典型的空间换时间做法，代价是每个字段看起来有点重复，换来的是订单数据的历史可追溯性。订单表里增加 order_no 字段也同理，用户和管理员沟通订单时，用一串唯一单号比用自增 ID 方便得多。
4. 核心模块实现：购物车、下单支付与权限控制的落地代码
4.1 后端购物车模块：Controller、Service 与异常处理的配合
购物车模块是前后端最早对接的功能之一，逻辑相对简单，但代码结构必须完整，要能体现 Controller -> Service -> Mapper 的分层调用。先看购物车模块的 Controller 部分：
@RestController @RequestMapping("/api/cart") public class CartController { @Autowired private CartService cartService; // 查询当前用户的购物车列表 @GetMapping("/list") public Result list(@RequestAttribute("userId") Integer userId) { return Result.success(cartService.getCartList(userId)); } // 添加商品到购物车 @PostMapping("/add") public Result add(@RequestBody CartAddDTO dto, @RequestAttribute("userId") Integer userId) { cartService.addItem(userId, dto.getProductId(), dto.getQuantity()); return Result.success(); } // 修改购物车中某件商品的数量 @PutMapping("/update") public Result update(@RequestBody CartUpdateDTO dto, @RequestAttribute("userId") Integer userId) { cartService.updateQuantity(userId, dto.getCartId(), dto.getQuantity()); return Result.success(); } // 删除购物车中的某条记录 @DeleteMapping("/delete/{cartId}") public Result delete(@PathVariable Integer cartId, @RequestAttribute("userId") Integer userId) { cartService.removeItem(userId, cartId); return Result.success(); } }CartController 里的 userId 不是前端传的，而是从拦截器解析 Token 后塞进请求属性里的，这样设计有两个好处：前端永远不需要手动传用户 ID，杜绝了越权操作的可能；后续下单、查询订单的接口都能复用这套获取用户身份的机制。这里需要说明的是，DTO 类的字段校验可以在 add 方法里加 @Validated 注解完成，比如 quantity 最小值为 1，否则捕获到校验异常后统一返回错误信息，不需要各处重复判断。
Service 层的核心逻辑要做两件事：查询时组装商品信息和数量；新增时判断是新增记录还是更新已有记录。
@Service public class CartServiceImpl implements CartService { @Autowired private CartMapper cartMapper; @Autowired private ProductMapper productMapper; @Override public List<CartItemVO> getCartList(Integer userId) { List<Cart> carts = cartMapper.selectByUserId(userId); List<CartItemVO> result = new ArrayList<>(); for (Cart cart : carts) { Product product = productMapper.selectById(cart.getProductId()); if (product == null || product.getStatus() == 0) { continue; // 已下架商品不出现在购物车列表 } CartItemVO vo = new CartItemVO(); vo.setCartId(cart.getId()); vo.setProductName(product.getName()); vo.setPrice(product.getPrice()); vo.setQuantity(cart.getQuantity()); vo.setStock(product.getStock()); result.add(vo); } return result; } @Override public void addItem(Integer userId, Integer productId, Integer quantity) { Cart exist = cartMapper.selectByUserIdAndProductId(userId, productId); if (exist != null) { exist.setQuantity(exist.getQuantity() + quantity); cartMapper.updateById(exist); return; } Cart cart = new Cart(); cart.setUserId(userId); cart.setProductId(productId); cart.setQuantity(quantity); cartMapper.insert(cart); } }这段代码里的“已下架商品不出现在购物车列表”是一个容易被忽略但很体现细节的写法，它保证了下架商品不会在用户购物车里留下一个无法结算的脏数据。addItem 里先查再改而不是直接插入，避免同一商品在购物车中出现多条记录，用户体验会顺很多。如果遇到商品库存不足或商品不存在的情况，我一般会在 addItem 里先查一遍商品状态并抛出业务异常，由全局异常处理器统一转成友好提示。
4.2 前端 Vue 组件：商品列表、购物车与状态联动
前端页面的价值是把后端接口串成完整操作流。商品列表页通过 axios 请求 /api/product/list 获取商品数据，点击“加入购物车”按钮时调用购物车接口并提示结果；购物车页面根据接口返回的列表渲染每一行商品，数量修改器绑定 input 事件，失焦或点击加减时触发数量更新。
<template> <div class="cart-page"> <el-table :data="cartList" v-loading="loading"> <el-table-column prop="productName" label="商品名称" /> <el-table-column label="单价"> <template slot-scope="scope">{{ scope.row.price }}</template> </el-table-column> <el-table-column label="数量"> <template slot-scope="scope"> <el-input-number :value="scope.row.quantity" :min="1" @change="(val) => updateQuantity(scope.row.cartId, val)" /> </template> </el-table-column> <el-table-column label="小计"> <template slot-scope="scope">{{ (scope.row.price * scope.row.quantity).toFixed(2) }}</template> </el-table-column> <el-table-column label="操作"> <template slot-scope="scope"> <el-button type="text" @click="removeItem(scope.row.cartId)">删除</el-button> </template> </el-table-column> </el-table> <el-button type="primary" @click="checkout">去结算</el-button> </div> </template> <script> export default { data() { return { cartList: [] }; }, mounted() { this.loadCart(); }, methods: { async loadCart() { this.loading = true; const res = await this.$http.get('/api/cart/list'); this.cartList = res.data; this.loading = false; }, async updateQuantity(cartId, quantity) { await this.$http.put('/api/cart/update', { cartId, quantity }); this.loadCart(); // 刷新，重新计算小计 }, async removeItem(cartId) { await this.$http.delete(`/api/cart/delete/${cartId}`); this.loadCart(); }, checkout() { this.$router.push({ path: '/order/confirm' }); } } }; </script>去结算按钮不是直接调下单接口，而是先跳转到订单确认页，让用户核对商品清单和总金额后再提交。这个设计更贴近真实电商流程，也自然引出了订单模块：订单确认页从购物车数据生成订单预览，点击提交时请求后端创建订单接口，后端创建订单和扣减库存放在同一个事务里，保证两张表的数据同步更新。前端用 el-input-number 做数量修改，比手写 input 少了数字格式校验的烦恼，这是组件库带来的实际收益。
4.3 订单状态机与支付结算：如何做一个可演示又不出错的流程
订单模块是整个系统的核心，也是最容易被验收提问的地方。订单状态用整数标识，0 待支付、1 已支付、2 已发货、3 已完成、4 已取消，流转方向是：创建订单后进入 0，支付成功后进入 1，商家发货进入 2，用户确认收货或系统自动确认后进入 3，取消只能发生在 0 或 1 阶段。这种状态机设计保证了订单的每一步都有据可查。
创建订单的 Service 代码通常长这样：
@Override @Transactional(rollbackFor = Exception.class) public Long createOrder(Integer userId) { List<Cart> cartList = cartMapper.selectByUserId(userId); if (cartList.isEmpty()) { throw new BizException("购物车为空，无法下单"); } BigDecimal total = BigDecimal.ZERO; LocalDateTime now = LocalDateTime.now(); for (Cart cart : cartList) { Product product = productMapper.selectById(cart.getProductId()); if (product == null || product.getStatus() == 0) { throw new BizException("商品已下架：" + cart.getProductId()); } if (product.getStock() < cart.getQuantity()) { throw new BizException("库存不足：" + product.getName()); } total = total.add(product.getPrice().multiply(BigDecimal.valueOf(cart.getQuantity()))); } Orders order = new Orders(); order.setOrderNo(generateOrderNo(now)); order.setUserId(userId); order.setTotalAmount(total); order.setStatus(0); orderMapper.insert(order); // 批量插入订单明细并清空购物车 orderItemMapper.batchInsert(order.getId(), cartList); cartMapper.deleteByUserId(userId); return order.getId(); }@Transactional 是这里的关键。下单操作至少要经历“查库存、算总价、插入订单、插入明细、清空购物车”五步，任何一步失败都可能导致订单和购物车数据不一致，事务保证这组操作要么全部成功、要么全部回滚。我把库存从下单逻辑里拆出来单独看，是因为不同团队的扣库存策略不一样，简单方案是下单时校验库存充足即可，不预扣库存，发货完成后再减库存；严格方案是在下单时扣减库存并锁定，超时未支付再回补。毕设场景用前一种更稳妥，逻辑简单且容易演示成功路径，也不会因为支付环节卡住导致库存一直被占用。
支付模块在毕设里通常用模拟支付代替，前端点击“模拟支付”按钮直接调用后端的支付回调接口，把订单状态从 0 改为 1。接口会校验订单是否属于当前用户、状态是否为待支付，若不是则返回错误提示。支付对接第三方平台时也是从这个模拟接口替换成平台 SDK 调用的形式，整个业务流程和回调处理的骨架不需要变。
5. 常见问题与部署避坑：从 IDEA 到 MySQL 的调试排查清单
5.1 本地部署最容易翻车的四个点
第一个高频问题是 IDEA 运行 SpringBoot 主类直接报端口被占用。现象是启动日志里出现 “Port 8080 was already in use”，原因多半是本机已有进程占用了默认端口。解决方法是打开命令窗口输入 netstat -ano | findstr 8080，查出占用进程的 PID 后到任务管理器结束进程，或者修改 application.yml 里的 server.port。这个问题的本质是环境冲突，而不是代码错误，先改端口是最快的解法。
第二个问题是 Maven 依赖下载速度极慢或直接失败。现象是 IDEA 底部进度条长时间卡住，控制台报错显示无法从中央仓库下载某个 jar 包。原因通常是网络访问中央仓库不稳定。解决方式是在 Maven 的 settings.xml 里配置国内镜像源，这里要注意的是配置完成后必须点击 IDEA 里的 Maven 刷新按钮，否则依赖还是旧的。排查时如果某个依赖反复下载失败，先检查是不是镜像地址写错了，再检查仓库配置优先级。
第三个问题是前端 npm install 安装依赖失败。现象是命令行报 ERESOLVE 或 node-gyp 相关错误，原因是 Node.js 版本与项目依赖版本不兼容，这在 Vue 项目里很常见，不同版本的 npm 处理依赖树的方式不一样。解决方法是查看项目说明文件里要求的 Node 版本，用 nvm 切到对应版本后删除 node_modules 重新安装。不要在不清楚版本要求的情况下盲目升级 Node，升级带来的新报错比原报错还难排查。
第四个问题是前端调后端接口报 404。现象是浏览器控制台显示某个 /api 路径请求失败，排查思路是先确认后端接口是否正常返回。在浏览器地址栏直接访问后端的接口路径，如果返回 JSON 说明接口没问题，问题出在前端；如果 404 则检查后端 Controller 的 RequestMapping 路径是否多写或少写了一层。前后端分离项目里，这类路径不一致属于低级但高频问题，我在联调阶段都会先用浏览器的直接访问或者 Postman 验证一遍后端接口，再开始写前端对接代码。
5.2 数据库相关的三个注意点
数据库环节第一个问题是 navicat 导入 SQL 脚本时报语法错误。现象是脚本执行到一半中断，原因是本机 MySQL 版本与脚本使用的语法不兼容，比如用了 5.7 不支持的新特性。解决方法是核对项目要求的环境版本，优先使用 MySQL 5.7 版本建库，导入前先用文本编辑器检查脚本里的 CREATE TABLE 语句是否包含版本敏感语法。
第二个问题是 SpringBoot 连接数据库后控制台报时区错误。现象是启动时提示 “The server time zone value is unrecognized”，原因是 MySQL 连接串里没有指定时区。解决方法是在 application.yml 的 JDBC 连接串末尾加上 serverTimezone=Asia/Shanghai 和 useSSL=false 参数，这个问题在 MySQL 8.0 版本尤其明显，5.7 相对少一点，但对初学者来说第一次见到时容易慌。
第三个问题是插入数据后中文变问号。这个问题的根因几乎都出在字符集上，解决方法是数据库连接串里显式加上 characterEncoding=utf8，建表语句统一使用 utf8mb4 编码，navicat 连接时在连接属性里设置编码为 UTF-8。三层都统一后，中文乱码基本就消失了。排查时不要只看一个层面，先看数据库连接串，再看表编码，最后看页面 HTML 的 charset 声明，从链路两头往中间检查通常能快速定位。
6. 验收标准与答辩技巧：功能用例、演示脚本与评分视角
6.1 功能验收清单：从登录到下单的全流程用例
验收不是“打开页面看一眼没问题就行”，而是按照用户操作路径逐条走一遍并记录结果。我一般会准备一张功能验收清单，覆盖系统全部核心链路。下面这张表可以照抄使用，每条用例对应一个预期的操作结果。
| 编号 | 验收用例 | 预期结果 | 对应模块 |
|---|---|---|---|
| 01 | 用户注册、登录、退出 | 注册成功后可用账号登录，退出后访问受限接口跳转登录页 | 用户模块 |
| 02 | 管理员登录后台 | 管理员可见商品管理与订单管理菜单，普通用户无该入口 | 权限控制 |
| 03 | 商品列表页按分类筛选 | 点击分类后列表数据刷新为对应分类商品 | 商品模块 |
| 04 | 添加商品到购物车 | 购物车数量增加，相同商品不重复新增 | 购物车模块 |
| 05 | 修改购物车商品数量 | 小计金额实时更新，数量最小为 1 | 购物车模块 |
| 06 | 从购物车生成订单 | 生成待支付订单，订单总金额与购物车合计一致，购物车被清空 | 订单模块 |
| 07 | 模拟支付订单 | 订单状态从待支付变为已支付，页面状态同步更新 | 支付模块 |
| 08 | 后台修改订单状态为已发货 | 前端订单页可见已发货状态 | 订单模块 |
| 09 | 后台下架商品 | 前台商品列表不再展示该商品，购物车不可见该商品 | 商品模块 |
| 10 | 下单后修改商品价格 | 历史订单金额不变，订单明细中金额保持下单时快照 | 订单模块 |
6.2 答辩时怎么讲设计亮点
答辩环节的提问基本围绕“这个系统的设计为什么是这样”展开，与其被问到再临时解释，不如在讲 PPT 或演示时主动抛亮点。第一个值得讲的是“业务闭环”：注册登录、逛商品、加购物车、下单、支付、发货、收货，整条流程全部打通，展现的不只是几个 CRUD 页面，而是完整业务系统。第二个是“权限控制”：前端动态渲染菜单，后端接口拦截，两个层面说明系统不是仅仅能跑，而是考虑了安全性。第三个是“订单状态机加事务保证”：用状态字段驱动订单流转，下单过程用事务保证数据一致性，这两个点是后端设计能力的直接证据。
演示顺序需要提前设计。先以普通用户身份登录，完整走一遍加购、下单、支付流程，让评审看到前端交互和界面；再切换到管理员身份，展示商品上下架和订单发货的操作，让评审看到管理端能力。演示过程中如果碰到网络请求卡顿或者某个页面渲染慢，不要慌，先看是不是数据库连接串配置问题，这类问题通常不影响最终结果，重点是让流程走通，让功能被看到。
6.3 演示脚本与准备工作
在正式答辩或验收前，我会强制自己把演示脚本完整跑一遍，顺序是这样的：第一步，启动 MySQL 服务，用 navicat 确认数据库导入成功、商品数据存在；第二步，启动后端 SpringBoot，观察控制台日志确认数据库连接成功、项目监听端口正常；第三步，启动前端 Vue 工程，浏览器打开登录页；第四步，登录管理员账号，检查商品库存、订单列表数据齐全；第五步，切换普通用户账号，走一遍从浏览到支付的全流程，确认每个页面数据能正常展示。
这五步里最容易出问题的是第一步和第二步，因为环境变量、数据库连接、依赖版本这些影响大且容易被忽略。建议提前一天做一次全流程演练，把发现的问题在正式验收前修复完。从那以后，我每次交付项目前都强制自己走一遍这份清单，宁可多花十分钟，也不要在演示中途面对一个意外报错。希望帮到你。
本文还有配套的精品资源，点击获取
