“又到一年毕业设计选题的‘纠结季’”。每次刷到这类话题，总能看到满屏的图书商城、疫情打卡系统、校园二手交易。不是说这些题目不行，而是答辩老师早就看腻了，一问“你的项目有什么亮点”，学生自己都答不出个所以然。今天聊的这套SpringBoot+Vue日常办公用品直售推荐系统，是我反复整理过的一套毕设方案，项目完整度很高，源码、SQL脚本、接口文档三件套齐全，非常适合Java Web方向的同学参考。
这套平台的核心切入点有两个：一是“直售”，业务链路短，用户注册登录、浏览商品、加购下单、支付流程模拟、后台管理，一套标准的电商闭环；二是“推荐”，不是花里胡哨的大模型推荐，而是基于用户行为标签加权打分的一套轻量推荐逻辑，既能给论文凑出技术亮点，又能真真切切跑出“猜你喜欢”的效果。不管你是想直接拿来做毕设，还是打算照着这个思路重新写一套，这篇文章都值得看完。
1. 为什么选“办公用品直售推荐”当毕设题目
1.1 垂直场景比通用商城更容易做出辨识度
图书商城、通用商城这种题目最大的问题不是难度，而是“雷同”。十个选电商方向的人，八个是做图书，剩下两个做二手。办公用品这个场景天然有一层“企业采购”“日常耗材”的滤镜，商品品类丰富——文具、打印耗材、收纳、办公设备、茶水间用品——每类商品都可以打上细分的标签，这让推荐功能有了落地的土壤。
而且“直售”这两个字很关键。它表示平台方自己对货品负责，不像淘宝那种商家入驻模式需要设计店铺体系、商家后台、三级分销，业务边界非常清晰。对于一个本科生来说，一周能理清需求，两周能做完核心功能，这是最理想的工作量。
1.2 推荐功能是论文里最好写的“技术亮点”
很多人一听推荐系统就慌，觉得那是算法工程师干的事。实际上，在毕设这个体量下，完全不需要协同过滤、矩阵分解这类东西。用“用户行为+商品标签”打分排序，已经足够支撑起一个完整的推荐模块。
这套系统的推荐思路很简单：系统记录用户浏览、加购、下单三类行为，为每类行为分配不同的权重，再提取用户近期行为涉及的标签频次，给候选商品打标签匹配分。再加上新品补偿、热门补偿、库存过滤，最终推出来一个排序列表。这个方案讲得清楚、代码写得出来、演示效果也直观，答辩老师挑不出大毛病。等你把协同过滤的改进方向在论文里篇幅一写，亮点直接拉满。
1.3 一个平台覆盖了Java Web的全部核心考点
我粗略数了一下这套系统的技术覆盖点：前后端分离架构、RESTful接口设计、JWT无状态登录、SpringBoot自动配置、MyBatis数据持久、MySQL事务与索引、Vue组件化开发、Axios请求封装、跨域处理、接口文档编写。说句不夸张的，答辩现场老师从这几个方向随便问，你都能掏出对应代码讲两分钟。
2. 技术栈选型与整体模块拆分
2.1 后端这套组合为什么至今还很能打
我见过很多同学习惯用最新版本，SpringBoot 3.x、JDK 17、Vue3+TS全套上。实话说，做毕设真没必要追新。我整理这套项目时后端用的是SpringBoot 2.7.x + JDK 8，这个组合最大的优势是“兼容性极好”：
- 网上搜到的报错解决方案基本都是这个版本区间，遇到问题不容易卡死；
- MyBatis-Plus 3.5.x对单表CRUD的简化力度非常大，商品、订单、用户这些基础表基本不用写SQL；
- Java生态里大量遗留代码、工具类都跑在JDK8上，毕业设计不涉及高并发性能调优，没有必要上虚拟线程那套新特性。
鉴权这块用了JWT（具体实现是jjwt库），配合一个HandlerInterceptor拦截器统一校验。为什么不用Session？因为前后端分离之后，Session天然不适合跨域场景，而且JWT的无状态特性在答辩时更容易讲出设计感。
2.2 前端为什么用Vue2而不是Vue3
这个问题肯定有人问。答案是：Vue2 + Element-UI这套组合在中文技术社区的教程存量太大了。
毕设不是企业级项目，讲究的是快速出活。Vue2的Options API对新手非常友好，data、methods、computed写起来直观；Element-UI的表单、表格、弹窗组件直接拿来用，无论是用户端的商品卡片还是管理端的订单表格，半天时间就能搭出有模有样的界面。Vue3就算用Composition API，逻辑上更灵活，但对一个毕业设计来说，这种灵活反而是负担。
2.3 系统模块怎么拆
这套系统的模块划分如下：
| 模块 | 使用者 | 核心功能 | 对应后端Controller |
|---|---|---|---|
| 用户认证 | 所有用户 | 注册、登录、个人信息维护 | AuthController, UserController |
| 商品直售 | 普通用户 | 商品列表、详情、分类筛选、搜索 | ProductController, CategoryController |
| 智能推荐 | 普通用户 | 首页推荐流、热门商品、相似推荐 | RecommendController |
| 购物车与订单 | 普通用户 | 购物车增删改查、下单、订单列表、订单详情 | CartController, OrderController |
| 行为采集 | 普通用户 | 浏览、加购、购买行为记录 | BehaviorController |
| 后台管理 | 管理员 | 商品管理、分类管理、订单处理、用户管理、推荐配置 | AdminProductController, AdminOrderController等 |
| 数据统计 | 管理员 | 销量统计、分类占比、用户增长 | StatsController |
这个拆分逻辑对应着“前台用户端 + 后台管理端”两套界面体系，但后端共用同一套SpringBoot服务。很多毕设项目喜欢把代码拆成前后端两个仓库，其实对于一个学生项目，为了保证演示方便，我更推荐前端Vue项目和后端Java项目物理分离，但最终部署时打包成一个可执行jar。
3. 后端核心链路：从登录鉴权到下单扣库存
3.1 JWT登录与统一鉴权
先看登录流程：用户提交用户名密码，后端校验通过后签发一个JWT Token，前端把它存在localStorage里，之后每次请求都在请求头带上Authorization: Bearer xxx。
@PostMapping("/login") public ResultInfo<String> login(@RequestBody LoginDTO dto) { User user = userService.login(dto.getUsername(), dto.getPassword()); if (user == null) { return ResultInfo.error("用户名或密码错误"); } String token = JwtUtil.createToken(user.getId(), user.getRole()); return ResultInfo.success(token); }核心校验逻辑放在拦截器里，注意要放行登录注册接口、商品查询接口，其余接口一律校验Token：
@Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (request.getMethod().equals("OPTIONS")) { return true; } String token = request.getHeader("Authorization"); if (token == null || !token.startsWith("Bearer ")) { throw new BizException(401, "未登录或登录已过期"); } // 解析token，将userId放入request attribute供后续使用 Claims claims = JwtUtil.parseToken(token.substring(7)); request.setAttribute("userId", claims.get("userId")); return true; }这里有个小细节：拦截器只是负责“认不认这个Token”，具体的“用户是否存在、权限是否足够”得在Service层再做一次校验。很多人只写了拦截器，结果把已经删除的用户Token也能放进来，这就是安全意识不足。
3.2 商品直售模块：分页查询必须处理好三个条件
商品列表是用户端的门面，接口设计上要支持关键词模糊搜索、分类筛选、上下架状态过滤、价格区间、分页。MyBatis-Plus的LambdaQueryWrapper可以很轻松搞定：
LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>(); if (StringUtils.hasText(keyword)) { wrapper.like(Product::getName, keyword); } if (categoryId != null) { wrapper.eq(Product::getCategoryId, categoryId); } wrapper.eq(Product::getStatus, 1); // 只展示已上架 wrapper.orderByDesc(Product::getSales); Page<Product> page = productMapper.selectPage(new Page<>(pageNum, pageSize), wrapper);这里建议大家注意一个点：管理端的商品列表和用户端的商品列表要分开接口。用户端永远只查已上架商品，管理端需要看到全部商品包括下架的。我见过有同学图省事用一个接口，前端控制状态，结果用户直接改参数就能看到管理端的停售商品数据。
3.3 下单与库存扣减：事务和行锁缺一不可
下单是电商类项目最容易暴露问题的环节。很多初写代码的同学，先查库存，if判断库存充足再减库存，最后插入订单——这套逻辑在并发环境下会出大问题。两个请求同时查到库存还有1件，双双判断“充足”，结果两个都下单成功，库存变成-1。
正确的做法是把“判断库存”和“扣减库存”合并成一条原子SQL，利用MySQL的行锁，同一时间只有一条更新能成功：
@Transactional(rollbackFor = Exception.class) public OrderVO createOrder(Long userId, List<CartItemDTO> items) { // 1. 校验购物车数据 // 2. 遍历扣减库存 for (CartItemDTO item : items) { int affected = productMapper.deductStock(item.getProductId(), item.getQuantity()); if (affected == 0) { throw new BizException("商品库存不足：" + item.getProductName()); } } // 3. 创建订单主表 // 4. 批量插入订单明细 // 5. 清空购物车，写入购买行为 // 6. 返回订单详情 }对应的SQL语句是：
UPDATE product SET stock = stock - #{count}, sales = sales + #{count} WHERE id = #{productId} AND stock >= #{count}受影响的记录数为0，说明库存不足或者商品下架，直接抛异常回滚事务。这种写法在高并发下依然成立，因为数据库行锁保证了并发更新串行执行。答辩现场被问“如何防止超卖”，这个答案绝对够用。
3.4 统一返回体和全局异常处理
前后端分离项目最忌讳的就是每个接口返回结构都不一样。这套系统的所有接口统一返回ResultInfo<T>结构：
- code：状态码，200成功，401未登录，500业务异常
- message：提示信息
- data：业务数据
配合一个全局异常处理器@RestControllerAdvice，业务中任何地方抛出BizException，前端都能拿到格式一致的错误信息。刚开始写代码的同学可能觉得麻烦，但这套规范能让你少踩很多联调阶段的坑。
4. 推荐逻辑实战：标签加权排序也能做出“像样”的推荐效果
4.1 推荐逻辑的完整链路
这套系统推荐的实现路径是：用户行为采集 -> 行为权重计算 -> 标签提取与候选召回 -> 标签匹配打分 -> 排序与过滤。
用户发生的每一条关键行为都会写入行为表，包括商品ID、行为类型、时间戳。行为类型权重在设计上是这样分配的：
| 行为类型 | 权重 | 含义 |
|---|---|---|
| browse | 1 | 浏览商品详情页，表示初步兴趣 |
| addCart | 3 | 加入购物车，购买意向明显 |
| purchase | 5 | 实际下单，兴趣最强烈 |
同时商品表里维护了一个tags字段，用逗号分隔，例如一份商品“A4复印纸”的标签是“办公,耗材,纸张”。后台管理商品时可以随时调整标签。
4.2 用标签匹配给候选商品打分
当用户进入首页请求推荐流时，后端做的事情分为三步：
第一步，查用户最近30天的行为记录，按行为类型加权，计算每个标签的总得分。代码逻辑参考：
Map<String, Double> tagScoreMap = new HashMap<>(); // weightMap: browse=1, addCart=3, purchase=5 for (Behavior behavior : recentBehaviors) { for (String tag : productService.getProductTags(behavior.getProductId())) { tagScoreMap.merge(tag, weightMap.get(behavior.getType()), Double::sum); } }第二步，遍历候选商品（排除用户已购商品、下架商品），对每个商品打标签匹配分。每命中一个用户高偏好标签就累加对应的标签得分，没有命中的标签不加分。
第三步，在标签匹配分的基础上，叠加“热门商品基础分”和“新品补偿分”，再乘一个库存权重系数。这一步是为了避免所有的推荐都被几款热门商品霸占，新品和长尾商品也能有机会露出。
最终按照总分倒序，取前20条作为推荐结果。整套逻辑在Java侧做循环计算，对于几百条商品数据毫秒级返回，完全够用。
4.3 冷启动场景：登录前后完全两种体验
新用户没有行为数据，标签匹配就没法做，这时候推荐接口自动降级为“热门商品榜”，按照销量和浏览量倒序。用户在未登录状态下也可以浏览商品，但行为采集在前端判断到用户已登录时才会上报，避免脏数据污染推荐模型。
这种行为数据的新老分离是很多同学容易忽略的点。我看到过某个项目把所有匿名浏览都记录进行为表，结果推荐出来的东西乱七八糟，就是因为没做登录态判断。
4.4 答辩时怎么把推荐算法讲清楚
给老师讲推荐模块的时候，一定要强调设计思路：先明确“用户兴趣由行为表达”，再解释“标签是商品和用户之间的桥梁”，最后说明“权重可配置化”——后台管理模块专门有一个推荐参数配置页，可以调整行为权重、热门补偿分、新品补偿分。这一个设计细节，直接体现了你具备“参数可调、系统可运维”的工程意识。
5. 前端页面的实现要点：从Element-UI到Axios封装
5.1 页面路由清单
用户端和管理端是两套独立路由，整体页面清单如下：
| 角色 | 路由 | 页面 | 核心交互 |
|---|---|---|---|
| 未登录用户 | /login, /register | 登录注册 | 表单校验、Token存储 |
| 普通用户 | / | 首页推荐流 | 推荐商品卡片、热门榜单 |
| 普通用户 | /product/list | 商品列表 | 分类联动、关键词搜索 |
| 普通用户 | /product/detail/:id | 商品详情 | 加入购物车、立即购买、相关推荐 |
| 普通用户 | /cart | 购物车 | 数量修改、选中计算 |
| 普通用户 | /order/confirm | 确认订单 | 地址管理、提交订单 |
| 普通用户 | /order/list | 我的订单 | 订单状态筛选 |
| 管理员 | /admin/dashboard | 数据看板 | ECharts统计图表 |
| 管理员 | /admin/product | 商品管理 | CRUD、上下架、标签编辑 |
| 管理员 | /admin/order | 订单管理 | 发货、退款处理 |
| 管理员 | /admin/recommend | 推荐配置 | 行为权重参数设置 |
5.2 Axios请求封装：每一处请求都自动带Token
说个真实经验：很多同学把携带Token的逻辑写在每一个页面的方法里，写了一百遍冗余代码，改一个后端接口前缀还要全局搜索替换。
这套项目里只封装一次Axios实例，所有网络请求统一走它：
import axios from 'axios' const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = 'Bearer ' + token } return config }) request.interceptors.response.use( response => { const res = response.data if (res.code === 401) { localStorage.removeItem('token') router.push('/login') return Promise.reject(new Error('登录已过期')) } if (res.code !== 200) { Message.error(res.message) return Promise.reject(new Error(res.message)) } return res.data }, error => { Message.error(error.response?.data?.message || '网络异常') return Promise.reject(error) } )这段代码的价值在于：所有页面调接口只需要关心业务数据，不需要重复处理Token、错误弹窗和登录跳转。
5.3 本地开发跨域代理配置
前后端分离联调阶段，跨域是非常经典的坑。前端跑在8080端口，后端跑在8080端口，浏览器直接请求后端接口会被CORS拦截。解决方式有两种：后端加CORS配置，或者前端用开发服务器做代理转发。
我推荐用代理转发方案，配置在vue.config.js里：
module.exports = { devServer: { port: 3000, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, pathRewrite: { '^/api': '' } } } } }这里的关键点是路径规划：前端请求统一加/api前缀，代理转发时去掉前缀再转发给后端。这样即使以后部署到生产环境，用Nginx做反向代理时也能复用同一套规则，不需要改前端代码。
5.4 购物车数量和用户信息的全局状态
购物车数量角标这种数据用户不可能十秒不刷新就能忘记状态，所以一定不能靠组件通信传来传去，要用Vuex或Pinia做全局状态管理。我在这套项目里把“用户信息、购物车数量、待支付订单数量”这几个高频使用的数据放进了Vuex，每次登录后拉取一次，加购、下单成功后重新计算。前端状态一致了，后端数据一次查询到位，交互体验比从零开发要自然很多。
6. SQL脚本里的关键设计：建表、数据脚本与常见坑
6.1 核心表结构与表关系说明
这套系统的SQL脚本里一共十来张表，环环相扣，我挑核心的几张开个头：
| 表名 | 功能 | 关键字段 |
|---|---|---|
| sys_user | 系统用户（普通用户+管理员） | id, username, password, role, avatar |
| product_category | 商品分类 | id, name, parent_id |
| product | 商品表 | id, category_id, name, price, stock, tags, sales, status, image |
| behavior | 用户行为表 | id, user_id, product_id, type, create_time |
| cart | 购物车表 | id, user_id, product_id, quantity |
| trade_order | 订单主表 | id, order_no, user_id, total_amount, status, create_time |
| trade_order_item | 订单明细表 | id, order_id, product_id, product_name, price, quantity |
| recommend_config | 推荐参数配置表 | id, behavior_type, weight |
设计表的时候，我最想强调的一点是不要建物理外键，但要在逻辑上有外键关系，比如trade_order_item.order_id对应trade_order.id，cart.user_id对应sys_user.id。物理外键在单机演示时不会有问题，但未来如果要分库分表或者做数据迁移，物理外键就是灾难。很多企业开发规范里默认禁用物理外键，这可以作为答辩时的一个加分回答。
6.2 订单状态流转设计
订单状态我没用孤立的字符串，而是用整数状态码加字典解释：
| 状态码 | 含义 | 可操作动作 |
|---|---|---|
| 0 | 待付款 | 取消订单、去支付 |
| 1 | 待发货 | 管理员发货 |
| 2 | 已发货 | 用户确认收货 |
| 3 | 已完成 | 申请售后/评价 |
| 4 | 已取消 | 无 |
| 5 | 退款中 | 管理员同意/拒绝退款 |
状态流转必须由后端代码控制，比如只有状态为0的订单才能执行取消操作，否则返回“当前订单状态不支持该操作”。这种设计虽然简单，但能把边界条件卡得很稳。
6.3 SQL脚本导入的三大坑
从零导入SQL脚本到MySQL时，最常见的坑是这三个：
第一是字符集。建表语句必须显式声明CHARSET=utf8mb4，否则中文商品名导入后直接变乱码。utf8mb4比utf8多了对Emoji的支持，宁可一步到位。
第二是执行顺序。如果脚本里不是按主表在先、从表在后的顺序导出的，带物理外键的表就会导入失败。这类问题排查起来很费时间，不如干脆不建物理外键。
第三是时间字段默认值。很多MySQL的datetime默认值在5.7和8.0版本表现不同。设置create_time DATETIME DEFAULT CURRENT_TIMESTAMP在8.0下没问题，但在某些低版本下会报错。稳妥做法是Java代码插入数据时显式设置时间字段。
6.4 演示数据怎么造才像模像样
一套空数据库，演示推荐功能的时候什么效果都跑不出来。我建议用脚本批量生成演示数据：50个左右的测试用户，200个商品，每个商品3到5个标签，然后模拟每个用户随机产生几十条浏览、加购、购买行为。推荐接口的Demo效果基本上一跑一个准，真实感满分。
7. 接口文档、环境搭建与部署排错
7.1 接口文档到底要写到什么程度
很多同学拿到项目之后，觉得接口文档就是鸡肋。实际上，对于毕设来说，接口文档是毕业论文“系统详细设计”那一章的现成素材，答辩时直接翻给老师看，比空口讲设计有说服力得多。
一个合格的接口文档至少要包含这些内容：接口名、请求URL、请求方式、请求参数说明（参数名、类型、是否必填）、返回结果示例、错误码业务含义。如果能再把接口分成“用户端接口”“管理端接口”两个分类，读者看起来会更清晰。
7.2 本地运行的全流程和环境配置
这套项目的环境要求如下：
| 组件 | 推荐版本 | 说明 |
|---|---|---|
| JDK | 1.8 | 高版本需调整部分依赖 |
| Maven | 3.6+ | 国内镜像源加速依赖下载 |
| Node.js | 14 LTS 或 16 LTS | Vue2项目不要用太高版本 |
| MySQL | 5.7 或 8.0 | 两者都支持，注意驱动版本 |
启动步骤非常简单：先创建数据库，导入SQL脚本；再修改后端application.yml里的数据库账号密码；启动后端SpringBoot应用；进入前端目录，执行cnpm install或npm install，再执行npm run serve；浏览器访问3000端口即可。
7.3 部署排错最常见的几个实测坑
按真实使用反馈，下面这几个坑出现的频率最高，我按排查优先级列出来：
| 现象 | 排查点 | 解决方案 |
|---|---|---|
| 后端启动后端口被占用 | 检查8080端口占用 | 杀掉占用进程或修改server.port |
| 数据库连接报错 “Public Key Retrieval is not allowed” | MySQL8.0连接串 | url末尾加allowPublicKeyRetrieval=true |
| 数据库连接报错 “The server time zone” | 时区问题 | url中加serverTimezone=Asia/Shanghai |
| 前端请求报404 | 代理路径和后端context-path | 统一约定 /api 前缀转发规则 |
| 上传的商品图片不显示 | 静态资源映射 | 在配置里设置资源映射路径指向本地磁盘目录 |
尤其是上传图片这个问题，很多人喜欢把图片存到项目的resources/static/upload目录，但打包成jar之后，写入jar内部的文件再想访问就特别别扭。更合理的方案是上传到本地磁盘的固定目录，再通过配置类把/upload/**映射到那个物理路径。运行环境变了，只需要改配置，代码不用动。
7.4 前后端最终打包合并成单jar
毕设答辩现场，最怕的是演示环境网络出问题，前端依赖装不上、后端服务起不来。稳妥的方案是：前端执行npm run build生成dist目录，把dist里的内容复制到后端src/main/resources/static下，然后用mvn package打成可执行jar包。启动jar之后直接访问http://localhost:8080，SpringBoot会自动把前端静态资源一起托管，单进程部署，演示零压力。
这个方案需要额外注意一点：Vue Router要使用hash模式而不是history模式，否则刷新二级页面时会出现404。
8. 答辩现场被问得最多的几个问题和应对思路
8.1 高频问题与回答要点
| 老师常问的问题 | 回答要点 | 延伸话术 |
|---|---|---|
| 为什么用JWT不用Session？ | 前后端分离、跨域友好、天然适合集群扩展 | 生产环境会用Redis做Token黑名单实现主动下线 |
| 怎么防止库存超卖？ | 原子条件更新+事务回滚 | 高并发可以用乐观锁，更极端可以引入MQ串行化 |
| 推荐算法的原理是什么？ | 用户行为加权+标签匹配+补偿分 | 后续可以改进成基于物品的协同过滤 |
| 前后端是怎么通信的？ | Axios封装成统一实例，走Restful接口，JSON格式 | 接口文档里每个接口都有请求和返回结构定义 |
| 为什么用MyBatis-Plus？ | 单表CRUD零SQL，复杂SQL手写XML | 对比MyBatis的效率提升点 |
| 你的项目里哪个部分最难？ | 订单事务一致性 | 把下单那段代码和事务注解圈出来讲 |
8.2 被问“后续怎么优化”的高阶技巧
如果老师问“还有什么可以改进的地方”，千万别答不知道。可以这样接：
第一，库存扣减可以引入Redis缓存预扣减，降低数据库压力；第二，推荐算法可以升级成协同过滤，用物品间相似度矩阵做实时推荐；第三，文件存储可以接入对象存储，把本地磁盘换成云端桶；第四，支付模块可以对接真实第三方支付网关，把模拟支付换成真实支付流程。
这四条只要说出来，任何一个有实际经验的评委都会觉得你确实思考过系统的演进方向。
8.3 论文里怎么把项目讲得有深度
写论文的时候，建议把第4章的推荐模块作为系统详细设计的重点，数据模型、权重公式、算法伪代码画出来就占了不少版面。答辩PPT里放一张推荐流程图，加上几张不同行为数据下的推荐效果截图。相比那些满页贴登录注册代码的同学，你的工作量饱和度在这几个技术点上会被明显感受到。
最后再说几句掏心窝的话
我见过很多同学拿到项目源码后拼命背代码，结果答辩时老师换个角度问一句就露馅了。我个人的体会是，这类毕设项目的价值不在“代码跑通了”，而在你是不是真的吃透了里面的每一条SQL、每一个设计决策背后的原因。
所以最后分享一个小建议：拿到任何一套类似的SpringBoot+Vue项目，不要急着改项目名交差。先按照我上面讲的链路，从登录鉴权到下单扣库存，手动改写一遍核心代码；再把推荐模块的权重表改成你自定义的参数，然后重新造一批演示数据。这个过程走完，不仅答辩稳如磐石，面试官问“你的毕设做了什么”时你也能讲得底气十足。Java Web方向不缺从零到一搭框架的能力，缺的是能说清楚“每个模块为什么这么设计”的实战理解。
