你如果正在愁毕设选题，或者Java课设不知道做什么方向，那SpringBoot+Vue这套日常办公用品直售推荐系统管理平台，真的很适合拿来认真啃一遍。这类项目最大的特点就是“技术栈经典、业务链路完整、工作量适中、好答辩”，前有用户端的商品浏览购物流程，后有管理端的订单商品维护，中间还夹着数据分析和推荐逻辑，一套下来基本上把Java全栈开发的主线都过了一遍。而且MySQL做数据存储，前后端分离，能写的难点和亮点都不少，不管是自己学习还是直接改造成毕设题目，都非常顺手。
这篇文章我就以这个项目为例，把它拆开揉碎讲清楚——包括架构怎么搭、数据库怎么设计、推荐模块怎么从零实现、前后端怎么联调，以及我实际跑这类项目时踩过的坑和总结的避雷经验。你不需要用什么高端框架、微服务、分布式架构，就用SpringBoot、Vue、MySQL这些最主流的东西，把业务做扎实、把逻辑讲透彻，就足够在毕设答辩里站得住了。
1. 项目到底在做什么：需求拆解与工作量画像
1.1 三个关键词看懂题目
先别急着上手敲代码，第一步一定是搞清楚这个项目到底是干什么的。标题里有三组关键词，分别是“日常办公用品”“直售”“推荐系统管理平台”，这三者分别决定了业务边界、交易方式和系统复杂度。
“日常办公用品”指的是业务领域，包括笔记本、签字笔、文件夹、订书机、打印纸、硒鼓这类高频消耗品。这个选品方向非常聪明，因为商品结构简单、单价低、用户决策成本低，不需要复杂的SKU规格和库存逻辑，特别适合课程设计和毕业设计的时间容量。相比电商领域里那些动不动就拼团、秒杀、优惠券叠加的系统，办公用品直售平台可以很自然地把重心放在基础交易链路的完整性上。
“直售”意味着去掉中间商，让平台方直接面对终端用户。放在系统实现层面，就是不需要设计多商户入驻、商家审核、店铺装修之类的复杂功能，用户端只需要一套统一的前台页面和一份标准化的下单结算流程，管理端也只需要支持运营人员对商品、订单和用户进行统一管理即可。这就大幅降低了权限模块的复杂度。
“推荐系统管理平台”中的“推荐系统”是这类项目的核心亮点，也是很多同学在答辩时最怕讲不清楚的模块。其实学生项目里完全不需要上深度学习或者复杂模型，你只需要把推荐逻辑做成“基于用户行为的混合策略推荐”就行——也就是同时考虑商品热度、用户品类偏好、与相似用户的行为重叠，用Java代码和SQL聚合就能跑出可解释的推荐结果。这部分后面我会展开讲实现细节。
1.2 毕设、课设、学习三个场景如何差异化
同一个项目骨架，在不同场景下需要做不同的取舍。
如果你是用来做毕业设计，建议把重点放在完整性和深度上。完整性是指从需求分析、数据库设计到前后端实现、测试部署，每一条链路都要走通；深度则建议体现在两三个模块上，推荐模块和订单事务处理就是非常合适的深度切入点。比如你可以详细描述推荐模块的冷启动问题怎么处理、相似度怎么计算、为什么选择JWT而不是Session，这些技术决策本身就是答辩时的得分点。
如果只是课程设计，时间和人力都有限，那就砍掉非核心功能。比如后台管理的用户列表可以不做编辑，只保留查询和禁用；数据统计不要做实时大屏，只要用ECharts画几个柱状图和饼图就够了。课设的核心诉求是“功能闭环跑通”，不需要追求过度的工程化设计。
如果是纯粹为了学习，那这个项目最适合用来理解前后端分离的完整开发流程。你可以不看任何现成源码，自己从建表开始一步一步写，这样才能真正理解SpringBoot的分层思想、Vue组件通信方式、Axios请求拦截器的意义，以及一张订单表为什么要拆成主表和明细表两张表。这些知识点比项目本身更能带来长期价值。
1.3 项目功能清单梳理
先画出一个基础功能清单，你照着这个清单去落功能，基本不会跑偏。
用户端功能：注册登录、商品分类浏览、关键词搜索、商品列表筛选与排序、商品详情查看、加入购物车、修改购买数量、结算下单、在线支付(模拟)、订单列表查看、取消订单、个人资料管理、商品收藏、浏览记录。
管理端功能：管理员登录、商品分类管理、商品信息维护(上下架、库存修改)、订单查询与发货处理、用户列表管理、数据统计看板、推荐位配置。
这些功能看着多，但落到数据库里其实也就是一张用户表、一张商品表、一张分类表、一张购物车表、两张订单相关表再加上一张收藏表和一张浏览记录表。后面我会详细给出表结构设计，你会发现功能清单其实是在帮你推导数据模型，而不是反过来。
2. 技术选型：为什么是SpringBoot + Vue + MySQL
2.1 为什么SpringBoot能成为 Java 后端的事实标准
先说说后端。SpringBoot现在几乎就是Java Web开发的标准答案，你出去找工作、看开源项目、翻毕设题目，十有八九都绕不开它。它最核心的价值是“约定优于配置”，把Spring MVC、事务管理、JSON序列化、内置Web容器这些事情全部自动装配好了，你只需要写Controller、Service、Mapper三层代码。
放到这个项目里，SpringBoot能帮我们解决三个具体问题。第一个是快速搭建RESTful API，你通过@RestController和@GetMapping就能把接口暴露出去，前端拿JSON数据直接渲染，完全不需要模板引擎。第二个是事务管理，下单的时候需要同时扣减库存、生成主订单和明细订单，三步必须同时成功或者同时失败，一个@Transactional注解就能把事务边界划清楚。第三个是生态兼容性，不管是MyBatis-Plus、JWT、Swagger还是后续想引入Redis、RabbitMQ，SpringBoot都有非常成熟的starter依赖，起步成本极低。
2.2 为什么选Vue做前端而不是JSP或Thymeleaf
选前端框架之前，要先理解“前后端分离”的意义。如果是JSP或者Thymeleaf，虽然也能做页面，但Java代码和HTML耦合在一起，任何一次界面改动都要重启后端服务，而且写起来非常难受。Vue把页面渲染完全交给了浏览器，后端只负责输出JSON，前端通过Axios发起HTTP请求拿数据，各自独立开发和部署，这也是目前企业中主流的开发模式。
Vue的核心优势在于组件化。拿这个项目的商品模块举例，你可以把“商品卡片”抽成一个独立组件，在首页推荐、搜索结果、分类列表、收藏页面里反复复用，只需要传入不同的商品对象即可。再比如购物车数量加减、订单状态标签、分页条这些UI片段，都可以组件化，代码写起来非常清爽。配合Element UI组件库，表单、表格、弹窗、上传这类后台管理页面常见的交互，基本不需要你自己去写繁琐的CSS和原生JS。
需要提醒的是，Vue现在分Vue2和Vue3两个大版本。做毕设建议选Vue2 + Element UI，因为资料多、兼容性好、踩坑少；如果想在简历上体现新技术的掌握度，也可以选Vue3 + Element Plus，但要有心理准备，部分组件的写法和生态配套跟Vue2差异不小，调试成本会略高一些。
2.3 MySQL数据库在项目中的定位
MySQL在这个项目里的定位就是唯一的数据持久层，所有业务数据的存和取都靠它。为什么不选Oracle、PostgreSQL或者MongoDB？原因很直接：MySQL是学校和企业里最普及的关系型数据库，参考文档最多，遇到问题随手一搜就有答案，而且学习成本和部署成本都极低。
数据表的设计上要特别注意两个原则。第一个是“把业务状态数字化”，比如订单状态不要存字符串“待发货”，而是存int类型的0、1、2、3、4，再在Java代码里用常量或枚举去映射；第二个是“关键金额用decimal”，不要用float或double存钱，否则会出现0.1加0.2不等于0.3的浮点精度问题。办公用品单价不高，但订单统计和结算还是必须保证精确，decimal(10,2)在这个场景下足够用了。
另外一个细节是建议数据库字符集统一设置为utf8mb4，这个比utf8多了对emoji和生僻字的支持，避免前端传过来的特殊符号在入库时报错。
2.4 技术栈完整对照表
| 层次 | 选型 | 说明 |
|---|---|---|
| 后端框架 | SpringBoot 2.7.x | 稳定且资料丰富，兼容Java 8 |
| 持久层 | MyBatis-Plus | 单表CRUD零SQL，复杂查询手写XML |
| 权限认证 | JWT | 无状态登录，适合前后端分离 |
| 数据库 | MySQL 5.7 / 8.0 | 建议5.7起步，8.0也兼容 |
| 前端框架 | Vue2 + Element UI | 组件化开发，UI成熟 |
| HTTP客户端 | Axios | 统一封装请求与拦截器 |
| 构建工具 | Maven / npm | 后端依赖管理和前端打包 |
| 接口文档 | Swagger(可选) | 自动生成接口文档，答辩加分 |
这套组合的好处是每一个环节都有海量学习资源，而且面试官或答辩老师看到这些技术名词，第一反应就是“这是主流路线”，不会质疑你技术选型的合理性。
3. 数据库设计：十张业务表如何支撑整个系统
3.1 从业务功能反推数据模型
数据库设计是很多同学最容易敷衍、其实也最容易丢分的地方。记住一个原则：先不急着画表，先把你前面列的功能清单一个个过一遍，问自己“这个功能需要存取哪些数据”，然后自然推导出表和字段。
以“商品详情”为例，你需要展示商品名称、分类、主图、详情描述、价格、库存、销量；以“下单结算”为例，你需要记录用户、收货人、联系电话、地址、订单总价、支付状态、各个商品的快照信息。按这个思路走一遍，下面几张表基本就是必选项。
基础业务表包括t_user用户表、t_category分类表、t_product商品表。交易链路表包括t_cart购物车表、t_order订单主表、t_order_item订单明细表。用户行为表包括t_favorite收藏表、t_browse_record浏览记录表。如果想做推荐位配置或者轮播图管理，还可以加一张t_recommend推荐配置表。九到十张表对于毕设项目来说数量刚好，能看出你对业务的理解又不会显得冗余。
3.2 核心业务表字段详解
拿最核心的t_order订单主表举例，字段设计一般包含id主键、order_no订单编号、user_id用户ID、total_amount商品总金额、pay_amount实付金额、status订单状态、receiver_name收货人姓名、receiver_phone收货人电话、receiver_address收货地址、pay_time支付时间、ship_time发货时间、create_time创建时间。
订单编号order_no一定不能直接用数据库自增id，因为订单号需要对外展示而且需要有时序性和唯一性。常见做法是用时间戳加随机数拼一个字符串，比如“20250601203000123456”，格式是年月日时分秒加四位随机码，这样每天生成几万个订单也不会重复，而且从订单号上就能看出下单时间，非常实用。
订单状态status建议用int类型保存，0代表待支付，1代表已支付，2代表已发货，3代表已完成，4代表已取消。很多同学会觉得用字符串更直观，但实际开发中int配合Java常量类的写法，既节省存储空间又方便做条件判断。你可以单独建一个OrderStatusEnum枚举类，代码可读性反而更好。
订单明细表t_order_item必须保存商品快照字段，包括product_id、product_name、product_image、price、quantity、subtotal。为什么已经有t_product商品表了还要冗余一份商品名称和价格到明细表？因为商品价格和名称是会变动的，用户下单时是10块钱，如果商家后来改成了15块，订单明细里的金额不能跟着变。快照机制就是把这个历史事实固定下来，这也是订单表设计时最容易忽略又最容易被答辩老师追问的点。
3.3 用户行为表的取舍与扩展
t_favorite收藏表和t_browse_record浏览记录表是推荐模块的数据基础。收藏表比较简单，user_id加product_id加上create_time，联合唯一约束避免重复收藏。浏览记录表同样也是user_id加product_id加browse_time。
这里我想多说一句浏览记录表的设计细节。很多初学者会想着用一条记录去更新浏览时间，但在真实系统中，同一用户反复浏览同一商品时，正确做法往往是直接插入新记录，让历史浏览行为被完整保留下来。这样在后续做推荐统计时，你才能分析出“用户到底看了几次这个商品”，而不是只有最后一次浏览时间。数据量大了之后也可以用定时任务去清洗压缩，但学生项目阶段，全量保留是最简单的做法。
除此之外，如果你想让系统更完善，还可以加一张t_address收货地址表，支持用户维护多个常用地址；如果要做支付流水，可以加t_pay_log支付日志表。但考虑到毕设工作量，地址信息直接做进下单表单、下单时手动填写也是可以接受的，就看你想在哪个模块多做文章。
3.4 建表SQL的几点关键约定
建表SQL里有一些约定俗成的写法，我建议你直接养成习惯。所有主键统一命名为id，类型为BIGINT且自增；所有业务表都加上create_time和update_time字段，类型为datetime；所有逻辑外键字段统一命名规则，比如user_id、product_id、category_id，方便代码里识别。
字符集统一写成utf8mb4，排序规则用utf8mb4_general_ci。存储引擎使用InnoDB，因为只有InnoDB支持事务，你的下单操作必须依赖事务保证数据一致性。字段类型方面，价格用decimal(10,2)，数量用int，状态用tinyint，描述类长文本用text，图片URL用varchar(255)。这几条规范写下来，答辩时你可以理直气壮的说“我遵循了工程化数据库设计规范”。
4. 后端实现：分层架构与核心接口
4.1 项目目录与分层规范
SpringBoot项目的后端目录结构，推荐按照技术分层来组织，分成controller、service、mapper、entity、common、config这几个包。controller层只做参数接收和结果响应，service层写业务逻辑，mapper层负责数据库操作，entity层放数据库表对应的实体类，common包放统一返回结果和异常处理，config包放配置类。
这种分层的好处是职责清晰，出了问题能快速定位。接口报错了，先看controller参数是否接收正确，再看service逻辑是否跑通，最后排查mapper的SQL语句，每一层都可以单独测试。答辩的时候你也可以说，“我采用了经典的三层架构，保证了高内聚低耦合”，这句话虽然听起来套话，但如果你真按这个结构去写了，它就是货真价实的工程实践。
实体类方面，建议直接用MyBatis-Plus的注解风格，@TableName指定表名，@TableId指定主键策略，@TableField指定字段映射，字段名和数据库列名之间做驼峰和下划线的自动转换。这样一张表对应一个实体类，零配置文件，CRUD操作直接用MyBatis-Plus内置的BaseMapper即可。
4.2 统一返回结构代码实现
前后端分离项目最关键的一点是接口返回格式要统一。前端不管是拿列表、拿详情、还是报异常，都应该从同一个结构里去解析数据。我习惯定义Result类，包含code、message、data三个字段，code为200表示成功，500表示业务异常，401表示未登录。
public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.code = 200; result.message = "success"; result.data = data; return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.code = 500; result.message = message; return result; } }看到这个结构，你可以直接在Controller里return Result.success(productService.pageList(query))，前端拿到响应后统一判断code是否为200。这样处理的好处是，不管出现空数据、空指针、参数校验失败还是未登录，前端都可以写一套统一的拦截器去处理。比杂乱无章的返回Map或者什么都不返回要规范得多。
4.3 核心接口设计与数据交互流程
下面用表格列出这个系统的主要接口，你在设计RESTful API时可以直接参照这套命名规则。
| 功能模块 | 接口路径 | 请求方式 | 说明 |
|---|---|---|---|
| 用户注册 | /api/user/register | POST | 用户名密码注册 |
| 用户登录 | /api/user/login | POST | 返回JWT Token |
| 获取用户信息 | /api/user/info | GET | 根据Token解析用户 |
| 商品分页 | /api/product/page | GET | 支持分类筛选、关键词、排序 |
| 商品详情 | /api/product/{id} | GET | 商品信息+是否已收藏 |
| 加入购物车 | /api/cart/add | POST | 传入商品ID和数量 |
| 查询购物车 | /api/cart/list | GET | 返回购物车列表及总金额 |
| 提交订单 | /api/order/create | POST | 从购物车生成订单 |
| 订单列表 | /api/order/list | GET | 按用户查订单 |
| 取消订单 | /api/order/cancel | PUT | 仅待支付可取消 |
| 首页推荐 | /api/recommend/home | GET | 返回混合推荐商品列表 |
| 管理员商品列表 | /api/admin/product/page | GET | 管理端分页查询 |
| 商品上下架 | /api/admin/product/status | PUT | 修改商品状态 |
| 订单发货 | /api/admin/order/ship | PUT | 更新订单状态为已发货 |
| 数据统计 | /api/admin/stats/overview | GET | 返回销量、用户数等汇总 |
商品分页接口是用户端最高频的接口，需要同时支持分类id、搜索关键词、价格排序、销量排序、新品排序这几种组合条件。前端每次切换筛选条件或者翻页，都通过GET请求把query参数传到后端，MyBatis-Plus的QueryWrapper可以非常优雅地处理这种多条件拼接：
QueryWrapper<Product> wrapper = new QueryWrapper<>(); wrapper.eq(StringUtils.isNotBlank(keyword), "name", keyword); wrapper.eq(categoryId != null, "category_id", categoryId); wrapper.orderByDesc("sales"); Page<Product> page = productMapper.selectPage(new Page<>(pageNum, pageSize), wrapper);这一段代码最好用，也最容易被忽略的一点是eq方法前面的布尔条件是true时才拼接这个查询条件，也就是说前端没传keyword时，搜索条件根本不会参与SQL，不会因为空字符串导致全表扫描出问题。
4.4 用户认证与登录态保持
前后端分离项目里不能依赖Session，原因是后端接口部署在Tomcat、前端页面运行在浏览器，两者网络环境并不总是一致的，而且横向扩展时Session同步也是个麻烦事。所以这个项目用的是JWT方案，流程是：用户登录成功后，后端生成一个包含用户id和用户名的Token字符串返回给前端，前端存在localStorage里面，之后每次请求都在请求头Authorization字段携带这个Token，后端通过拦截器解析Token确定当前用户身份。
JWT生成可以使用io.jsonwebtoken这个库，核心代码很简洁，就是设置签发人、过期时间、主题，然后通过秘钥签名。登录时生成Token，拦截器里把Token解析出来放到ThreadLocal或请求上下文里，Controller里的方法想拿当前用户id就直接从上下文取，不用每次从请求参数里传userId。
需要特别注意Token的有效期设置。太短会导致用户用着用着突然要重新登录，体验很差；太长又会有安全风险。一般建议设置两小时，前端在拦截器里拿到401状态码时自动跳到登录页。另外由于JWT是无状态服务，Token一旦签发没办法主动失效，所以如果做了密码修改功能，可以额外维护一个Token黑名单或者强制让用户重新登录，这个细节你可以作为优化项提出来。
4.5 下单事务与库存扣减逻辑
下单是整个系统里最需要严谨对待的接口，因为它涉及多个表的数据变更。一次完整下单，需要做这几件事：校验商品库存和价格，生成订单主表记录，批量生成订单明细记录，扣减商品库存，清空用户的购物车。其中任何一步失败，前面已经写入的数据都必须回滚，否则就会出现“订单生成了但库存没扣”、“购物车清了但订单没生成”这类数据不一致问题。
SpringBoot里的实现方式就是给Service方法加@Transactional注解，一旦方法内抛出运行时异常，整个事务自动回滚。同时要注意，库存扣减的SQL不要写成先查库存再判断再更新，而是直接用一条带条件的UPDATE语句：
UPDATE t_product SET stock = stock - #{quantity} WHERE id = #{productId} AND stock >= #{quantity}这条SQL执行后返回值是1说明库存扣减成功，返回值是0说明库存不够，你可以直接抛异常让事务回滚。这样写的好处是避免并发下单时两个请求都查到剩余库存为1，然后同时扣减成负数的问题。虽然毕设场景下并发不高，但能体现你对数据并发安全的理解，这点在答辩时非常加分。
5. 前端实现：页面结构与关键交互
5.1 Vue项目结构设计
前端项目基于Vue脚手架搭建，它的目录组织直接影响后续维护体验。src目录下我习惯分成views、components、router、store、api、utils这几个目录。views放页面级组件，比如首页、商品列表、商品详情、购物车、订单、后台管理；components放公共组件，比如商品卡片、分页条、图片上传、统计图表；router放路由配置，并做好登录守卫；api目录按模块拆文件，把所有请求都封装成函数；utils里放axios实例和公共工具函数。
路由设计要区分用户端和管理端。用户端路由挂载在根路径下，比如/home、/product/list、/product/detail/:id、/cart、/order/list、/order/confirm、/user/profile。管理端统一挂在/admin下面，比如/admin/goods、/admin/orders、/admin/users、/admin/stats。通过路由meta里的role字段设置访问权限，配合全局前置守卫做未登录跳转和角色越权拦截，这样后台页面就不可能被普通用户访问到。
5.2 核心页面拆解与组件复用思路
先看首页，它是最能体现产品感的页面。首页的核心区域是推荐商品，这里的数据就来自后端/api/recommend/home接口，包含轮播图推荐位、热门商品区和猜你喜欢区。每个商品都复用ProductCard这个组件，传入一个product对象后自动渲染封面、名称、价格、销量。组件复用的好处是你只需要调整后端返回的数据顺序，前端不用做任何改动，推荐位和普通商品列表的表现效果是一样的。
商品列表页相对复杂，需要同时处理筛选条件和分页状态。左侧放分类菜单，顶部放搜索框和排序按钮（综合、销量、价格升序、价格降序），中间放商品卡片网格列表。每次筛选条件变化，重新调用商品分页接口，并用watch监听路由query参数的变化，这样用户刷新页面时筛选条件仍然能保持住。分页组件直接用Element UI的Pagination，注意把current-page和page-size绑到data里，否则翻页后条件会丢失。
商品详情页在用户点击卡片后跳转，通过路由参数拿到商品id，调用后端详情接口。页面上除了基本的商品信息和价格展示，还需要一个数量选择器和“加入购物车”“立即购买”两个按钮。这两个按钮请求的接口路径不一样，前者是走购物车逻辑，后者是直接跳转结算页。这里有一个小细节：加入购物车成功后，不要直接调跳转，而是用Element UI的Message组件弹出一个轻提示，同时更新右上角购物车角标数量，交互反馈要即时、柔和。
购物车页的难点在于选中态和金额联动。每一行购物车商品前有个复选框，全选按钮控制所有项，勾选状态变化时遍历所有勾选的商品重新计算总金额。提交订单时，把勾选中的购物车项的id列表传给后端，后端拿到这些id查询购物车详情，再进入下单流程。这种“前端传选中项、后端再查库”的方式比直接把商品信息和价格传给后端要安全得多，防止用户篡改前端数据导致金额错误。
5.3 前后端联调与Axios封装
联调是前后端分离项目里最容易出问题的一环。最常见的问题就是跨域。后端接口跑在8080端口，前端开发服务器跑在9528端口，浏览器默认会拦截跨域请求。解决方案有两个，第一个是后端加CorsFilter配置类放开跨域限制，第二个是前端在vue.config.js里配置devServer的proxy代理，把/api开头的请求转发到后端的8080端口。
我推荐用proxy方式，原因是生产环境下你还要把前端打包后的静态文件交给网关或后端托管，proxy配置和应用部署更贴近真实场景。具体配置是：
devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }Axios封装方面，创建一个utils/request.js文件，导出一个axios实例，设置baseURL为/api，请求超时时间为15秒。在请求拦截器里从localStorage取出token并设置到请求头，在响应拦截器里统一处理后端返回的code字段，等于200就返回data，401就清除本地登录状态并跳转登录页。这样一来，所有页面组件里就不需要重复写错误提示逻辑了，代码量能减少很多。
5.4 后台管理页面实现要点
后台管理页面是让项目看起来“完整”的关键。商品管理页面使用Element UI的el-table展示商品列表，支持搜索、分页、上下架切换，新增和编辑弹窗里需要处理图片上传。图片上传可以用el-upload组件搭配后端的文件上传接口，后端把图片保存到服务器本地目录，返回访问URL。富文本编辑商品详情推荐用wangEditor，这是一个纯前端富文本编辑器，集成简单，生成HTML片段后直接入库，详情页通过v-html渲染即可。
订单管理页面要展示订单列表，管理员的重点是查看订单状态和进行发货操作。一个比较实用的设计是给状态列加上el-tag标签，待支付显示灰色、已支付显示蓝色、已发货显示橙色、已完成显示绿色。发货操作直接调用后端发货接口，把订单状态从已支付更新为已发货。
数据统计看板建议用ECharts的柱状图和饼图。柱状图展示最近七天的订单量和销售额，饼图展示各类商品的销量占比，顶部再放几个统计卡片，分别显示用户总数、商品总数、订单总数和总销售额。这些数据从后端一个统计接口全部返回，前端拿到之后setOption即可。这个看板不涉及复杂算法，但图表呈现出来的视觉效果能把项目的完整度拉高一个档次。
6. 推荐系统模块：从0到1落地可解释的推荐逻辑
6.1 不要神话推荐，先从规则开始
很多同学一听到“推荐系统”四个字，就想着是不是要用机器学习、深度协同过滤，甚至开始担心不会Python怎么办。其实在课程设计和毕业设计场景里，你完全不需要那么重的技术栈。推荐系统最核心的问题是“给用户推荐他可能感兴趣的物品”，理解了这个目标，你先问自己一个问题：在没有用户历史行为的冷启动阶段，你会给人推荐什么？答案很简单，推荐最热门的和最受欢迎的。
所以我的推荐方案分三层递进：冷启动阶段，给所有用户推荐全局热门商品、新品和运营推荐位商品；用户有浏览行为后，推荐他经常浏览品类下的高销量商品；在此基础上，可以进一步引入基于用户相似度的协同过滤逻辑，找和他行为重合度最高的其他用户，把他们购买过而当前用户没接触过的商品推荐过来。每一层都有明确的数据来源和可解释逻辑，答辩时你可以一层一层讲清楚，老师会认为你是真正理解了推荐系统的常见问题。
6.2 基于行为数据的品类偏好推荐
先说第二种方案的具体实现。t_browse_record表里记录了每个用户的浏览历史，你可以通过一次SQL聚合统计出用户最常看的商品分类。比如提取当前用户在浏览记录表里出现次数最多的分类id，然后去t_product表里查这个分类下销量最高的十件商品，排除掉用户已经买过或者已经浏览过的商品，剩下的就是推荐列表。
这里有一个非常典型的问题：如果直接按销量排序，推荐出来的永远是那几件爆款，根本没有个性化。解决思路是为每个用户生成偏好分类的权重值，比如用户浏览了A分类12次、B分类5次、C分类3次，那么推荐列表里A分类的商品数量就应该比B和C更多，而不是统一分给各个分类。具体实现时不需要精确计算权重，前端推荐区域按“分类区块”划分，每个区块下方放该分类的热门商品即可，能做到这个程度，推荐的可感知度就已经非常明显了。
6.3 简化版协同过滤的Java实现思路
如果你想再往前迈一步，或者希望推荐模块在答辩时有更深的技术含量，可以尝试一下基于用户的协同过滤简化版。核心思想很简单：用户A和用户B都浏览或购买过相同的几件商品，可以认为他们偏好相似；于是把B喜欢但A还没接触过的商品推荐给A。
用Java实现时，在Service层写一个推荐方法。先查出当前用户的购买商品id集合和行为商品id集合，然后扫描所有其他用户，统计每个用户与当前用户的相似商品数量，按这个数量排序取前K个相似用户。接着把相似用户买过但当前用户没买过的商品，按销量排名返回前N件。整体逻辑用几个for循环就能实现，数据量在毕设级别完全不会成为性能瓶颈。
核心伪代码大概是这样：
buyList = 当前用户购买的商品id集合 behaviorList = 当前用户浏览+收藏的商品id集合 for each 用户U in 所有用户: if U是当前用户: continue commonBuyCount = U购买商品与buyList的交集数量 commonBehaviorCount = U行为商品与behaviorList的交集数量 score = commonBuyCount * 2 + commonBehaviorCount 放入用户相似度列表 按score降序，取前5个相似用户 candidate = 这些用户购买过的商品中，当前用户未购买的 按销量降序，推荐前10件这段逻辑没有引入向量计算和矩阵分解，但把协同过滤的精神内核体现得明明白白：相似的判断由共同行为决定，推荐的结果来自相似用户的选择。而且你可以很容易地讲清楚为什么给购买行为赋予更高的权重，因为购买行为比浏览行为更能体现真实偏好。这种对算法细节的思考远比背一堆数学公式更打动人。
6.4 推荐接口的性能和缓存优化
推荐接口如果在每次请求时都实时计算，虽然学生项目并发低也能跑得动，但毕竟每次都扫描全部用户和全部商品，效率不高。一个工程化意识更好的做法是把推荐结果缓存起来。
最简单的方式是使用SpringBoot自带的@Cacheable注解，或者自己写一个本地缓存Map，key是userId，value是推荐商品列表，过期时间设置为三十分钟。用户第一次请求推荐时实时计算并写入缓存，后续三十分钟内直接返回缓存。用户产生新的浏览、购买行为后，再手动清除该用户的推荐缓存，保证下次请求能看到最新推荐结果。这就能体现你对缓存策略和时效性的理解，是比单纯写完功能更高一层的工程思维。
7. 部署运行指南：从零跑通全套系统
7.1 本地环境准备清单
如果说前面的内容都是开发阶段，那这一步是提交验收和演示操作时必须跑通的环节。你需要准备的环境包括：JDK 1.8或11、Maven 3.6+、MySQL 5.7或8.0、Node.js 14或16、Vue CLI或Vite、IDEA和VSCode两个开发工具、Navicat或Workbench数据库管理工具。
版本问题一直都是新手最容易栽跟头的坑。SpringBoot建议使用2.7.x版本，这个版本对JDK8非常友好，MyBatis-Plus和Swagger这些配套依赖基本不会出现版本冲突。不要一上来就选SpringBoot 3.x，因为它强制要求JDK17以上，很多老依赖的适配还坑得很深，没必要给自己增加不确定性。
7.2 MySQL数据库初始化和配置
先创建数据库office_sale，字符集选择utf8mb4。然后执行项目里的init.sql脚本，它会一次性创建全部业务表并插入演示数据。演示数据很重要，用户端至少要有十个办公用品分类、每个分类五六件商品、几个测试用户、几笔不同状态的订单。原因是你演示的时候不可能当场注册用户再慢慢加购物车下单，预置数据能让整个演示流程顺畅很多。
后端配置文件application.yml里注意几个关键项：数据库地址改成localhost:3306，账号密码改成你自己的MySQL账户，同时设置server.port为8080。URL后边建议加上useSSL=false&serverTimezone=Asia/Shanghai这两个参数，前者防止加密连接报警，后者解决数据库时间字段和本地时间相差八小时的问题。
7.3 后端启动步骤与常见启动报错
启动后端前先确认Maven依赖能正常下载。如果你所在的网络环境访问Maven中央仓库慢，在settings.xml里配置阿里云镜像，仓库URL换成https://maven.aliyun.com/repository/public，速度能快好几倍。依赖下载完以后，直接运行主类上的main方法即可。
常见的启动报错第一是端口被占用，8080端口被其他程序占用时直接报“Port 8080 was already in use”，解决办法是换一个端口或者用netstat命令找到占用进程杀掉。第二个是数据库连不上，报Communications link failure，这个基本是数据库服务没启动、账号密码错误、时区参数没配这三选一。第三个是MyBatis-Plus分页插件没配置，导致分页失效，解决方式是在配置类里注入MybatisPlusInterceptor并添加PaginationInnerInterceptor。
7.4 前端安装启动与打包
前端项目先在根目录执行npm install安装依赖。如果速度很慢或者报npm ERR! ERESOLVE这类依赖树冲突错误，可以先换成cnpm或者pnpm再试。Node版本太高时，比如Node 18以上的环境跑Vue2项目偶尔会出现OpenSSL错误，解决办法是执行 export NODE_OPTIONS=--openssl-legacy-provider，这个坑在本地环境很容易遇到。
开发环境启动用npm run serve，浏览器访问localhost:9528。如果是演示给别人看，可以用npm run build打包出dist目录，这个目录就是纯静态资源，放到Nginx里配置一下反向代理就能部署上线。如果图省事，也可以直接把dist目录放到后端SpringBoot的resources/static目录下，让后端同时提供接口服务和静态页面访问，一个进程跑完整个项目，对毕设提交很友好。
7.5 演示数据重要性提醒
我再强调一遍预置数据的重要性。答辩演示的时候，你打开系统应该是已经能看到商品、订单、统计图表有内容的状态，而不是打开页面一片空白。准备一个管理员账号和一个普通用户账号，把账号密码写在一张纸上或者贴在演示文档里，登录时演示给老师看。普通用户的购物车里预置两件商品、订单列表里预置一个已发货订单和一个已完成订单，管理员后台的订单列表里预置不同状态的订单，这样你演示的时候顺理成章就能走完整个流程，不用现场去买东西。
8. 常见问题与避坑实录
| 问题现象 | 根因分析 | 解决思路 |
|---|---|---|
| 前端请求接口报跨域 | 后端未配置CORS或前端未配置proxy | 优先在devServer配置请求代理，生产环境拼绝对路径 |
| 数据库保存时间少8小时 | MySQL连接串没设置时区 | URL追加serverTimezone=Asia/Shanghai |
| 分页查询不生效 | MyBatis-Plus分页插件未注册 | 配置MybatisPlusInterceptor分页拦截器 |
| 前端npm install报ERESOLVE | node版本或依赖树冲突 | 换pnpm/cnpm，或设置legacy-peer-deps |
| JWT登录后刷新失效 | 前端未在拦截器放置token到header | Axios请求拦截器统一注入Authorization |
| 商品图片上传后访问不了 | 图片保存与访问路径不匹配 | 配置虚拟路径映射，图片URL相对路径存储 |
| 启动端口冲突 | 8080被其他进程占用 | 修改server.port或结束占用进程 |
| MyBatis查询字段无法映射 | 数据库下划线与Java驼峰未配置 | 开启map-underscore-to-camel-case |
这几种问题基本覆盖了学生项目里90%的报错场景。我想重点说一下跨域问题，因为很多同学明明已经配了后端CorsFilter，前端报错里还是能看到CORS。原因多半是前端没有使用代理，浏览器发出的请求地址是localhost:9528/api/xxx，而后端接口是localhost:8080/api/xxx，浏览器直接做了一次跨域请求。如果你把前端代理配好，那么devServer会帮你转发，浏览器看到的请求始终是同源的，跨域问题根本不会出现。
再补充一个很隐蔽的坑：如果你用Vue2的默认端口8080启动前端，而后端SpringBoot也是8080，那前端启动时会默认往后换用8081端口，但很多同学没注意到devServer已经在8081上运行了，导致页面访问的还是后端接口的8080，怎么调都不通。建议前端项目直接在vue.config.js里指定一个常用端口，比如9528，避开后端端口冲突。
最后是代码层面容易忽视的一个问题：返回给前端的实体类里如果有密码字段，记得用@JsonIgnore注解标记，否则序列化时会把密码hash也发到前端，这是非常低级的安全漏洞。登录接口返回的响应也要避免回传整个包含密码的user对象，正确做法是前端拿到token后，再通过用户信息接口获取脱敏数据。
9. 让项目真正“高级”起来的几个加分扩展
9.1 引入Redis做热门商品缓存
如果想把项目往工程化方向再推一步，可以在SpringBoot里集成Redis，把首页热门商品和分类列表缓存到Redis里，商品被更新或者上下架时再删除缓存。这样首页的访问基本不会打到数据库，响应速度大幅提升，答辩时你可以非常自然地讲出缓存穿透、缓存雪崩、缓存一致性这些词，即便还没深入实践，也已经展现出对性能优化的敏感度。
9.2 引入Spring Security替换手写拦截器
手写JWT拦截器虽然能用，但跟Spring Security或者Sa-Token这类安全框架相比，在过滤链、注解鉴权、密码加密集成、会话管理方面还是差了一些。如果你有三到四周的额外时间，可以选用Sa-Token，它对新手非常友好，注解式登录校验就一行@SaCheckLogin，同时天然支持JWT模式，替换成本很低。答辩时提到自己从手写拦截器升级到安全框架，体现出的学习能力和工程规范意识是很加分的。
9.3 用RabbitMQ优化订单取消逻辑
订单超时未支付自动取消是一个很经典的业务场景。最简单的是写一个定时任务扫描待支付且超过十五分钟的订单，但这种轮询方式不够实时且浪费资源。进阶做法是用RabbitMQ的延时队列，用户下单时发一条延迟消息，十五分钟后消费者去检查订单状态，如果还是待支付就取消。这个优化点本身不复杂，但能展示你对消息队列的掌握，在“订单管理”这一块就站住了。
9.4 用ECharts强化数据可视化效果
前面提到的数据统计看板可以继续扩展，比如增加折线图展示月度销售额变化趋势，雷达图展示不同分类的销售均衡度，表格里加入导出Excel功能等等。数据可视化是容易出效果又不容易出错的模块，因为电商系统天然就有用户数、订单量、销售额、销量排名这些“有故事”的数据，画出来的图表放在演示PPT里非常直观。
从我个人的经验来看，做这种SpringBoot+Vue的项目，最忌讳的就是一上来就写代码，写一半发现数据库表设计不合理，又回头改表、改接口、改页面，来回折腾还得不偿失。正确的顺序一定先是需求分析，再是数据库设计，然后是后端接口，最后才是前端页面。你在School里或者社团里帮别人看项目，十有八九的问题都出在表设计阶段偷懒了。先把表设计清楚，后面所有环节都会非常顺。
还有一个很实际的小建议：项目代码里一定要写好注释，尤其是Controller层的接口说明和Service层的核心业务注释。这些注释不是为了好看，是为了你在答辩前重新打开两三个月没碰过的项目时，能快速回忆起每段逻辑的意图。中途调试、熬夜改代码的时候，也记得顺手提交到Git仓库，给自己留好回滚的余地。祝你的项目顺利落地，答辩稳稳通过。
