做毕设选方向的时候很多人一听“智能垃圾分类”第一反应就是“这不就是个带搜索功能的增删改查嘛”然后随随便便找个模板套上去。结果做到答辩才发现老师问“智能”在哪体现、数据怎么流转、前端复用怎么做一个都答不上来。我手头正好整理了一套基于Spring Boot Vue的智能垃圾分类系统代码、文档、数据库脚本都齐也有配套的视频讲解这篇文章就围绕这个项目把核心模块的设计思路、前后端的关键实现、联调部署时容易踩的坑以及拿到源码后应该怎么二次扩展都拆开了讲一遍。无论是单纯想交一份合格的毕设还是真的想把“智能推荐”“积分激励”这些点做深这篇都能给你实打实的参考。1. 项目整体设计与思路拆解1.1 需求定位毕设项目到底要解决什么问题智能垃圾分类乍看是个小系统但深挖之后可以发现它其实覆盖了“用户端操作 管理员后台 基础数据维护 规则引擎 数据统计”五条线。毕设选题最怕的既不是太简单也不是太复杂而是找不到一个能自圆其说的业务故事。垃圾分类系统天然就自带一条清晰的主线用户来到系统查询某样垃圾属于什么类别完成分类投放获得积分积分可以兑换小礼品管理员维护垃圾种类、管理投放记录、审核反馈、查看统计报表。这套基于Spring Boot Vue的智能垃圾分类系统在功能设计上就遵循这条主线。前端用Vue做单页应用用户端和管理员端拆成两套界面后端用Spring Boot提供RESTful接口MySQL存业务数据。这种设计的好处是无论答辩老师问你“前端怎么跟后端通信”“数据库为什么这么设计”你都能从业务流和技术流两个角度回答上来而不是背一段网上抄来的概念。1.2 技术选型分析为什么是Spring Boot Vue而不是其他组合很多同学纠结过要不要用更“新”的技术比如前后端不分离的Thymeleaf或者换Python系的Flask、Django。我的观点很直接毕业设计的第一诉求是“稳”第二诉求是“能讲清楚”。Spring Boot的优势不在性能而在约定大于配置一个注解就能把接口、参数校验、异常处理串起来对Java基础一般的同学来说出问题的概率远低于SSH那套老古董。Vue这边选择的是Vue 2 Element UI的组合理由也很朴素Vue 2的生态最成熟Element UI的组件基本能满足后台管理页面的全部需求网上资料多到可以闭眼抄。如果你自己有精力换成Vue 3 Element Plus也不会伤筋动骨前后端分离的思路完全一致只是组件库API略有差异。说到底毕设考察的是你对这套架构的理解和运用不是炫技。1.3 功能模块划分一份拿得出手的功能清单这套系统在功能模块上划分为用户端、管理员端和公共模块三大部分。用户端包含注册登录、垃圾搜索查询、分类投放记录、积分查看与兑换、留言反馈等功能。垃圾搜索查询是核心需要支持按名称模糊搜索也能按类别浏览。管理员端包含后台登录、垃圾分类管理、投放记录管理、用户管理、积分规则管理、反馈管理和数据统计。公共模块则包括图片上传、Excel导入导出这类基础能力其中Excel导入用于初始化垃圾数据库毕竟几千条垃圾数据不可能靠手动一条条插入。模块划分本身不复杂但边界要清楚。我曾经见过有同学把管理员接口跟用户接口写在一个Controller里结果权限控制乱成一团。这套项目里用户端跟管理端接口是严格分离的用户端走/api/user/**管理端走/api/admin/**统一通过拦截器做角色校验。2. 核心功能与数据库建模详解2.1 数据库表设计用实体关系图理解数据流向数据表设计是毕设评分的重头戏也是面试时容易被追问的部分。我把这套系统的核心表归纳成6张它们之间的关联关系非常清晰。用户表sys_user用于存储用户和管理员信息包含密码等加密字段以及状态字段用于禁用账号。垃圾类别表garbage_category存储大类比如可回收垃圾、厨余垃圾、有害垃圾、其他垃圾并设置了排序字段和图标地址。垃圾信息表garbage_info是系统最核心的数据表每条记录对应一个具体物品名称通过category_id外键关联到类别表同时给名称字段加了全文索引不然几万条数据模糊查询会很吃力。投放记录表recycle_record记录用户每次投放的时间、垃圾类别、重量或数量、获取的积分这里做了按用户id和时间段的组合查询优化。积分规则表points_rule把不同垃圾类型的积分规则独立成表方便管理员调整系数。反馈表feedback存储用户提交的意见建议或问题申报管理端审核后可以修改处理状态。数据表之间必须是清晰的“一对多”关系这也是判断垃圾信息属于哪个类别的逻辑基础。答辩时如果你能顺手在白板上画一下这几个表之间的关系再解释一下为什么积分规则要单独建表而不写成硬编码这题基本就稳了。2.2 “智能”在哪里分类识别模块的设计思路这一条是很多拿到源码的人最想搞清楚的部分。系统里的“智能”不是深度学习、图像识别那套高深的东西而是基于关键词匹配的智能搜索引擎。对于毕设而言这反而是好事因为逻辑更可控、解释起来更直白。具体的实现思路是用户输入一个垃圾名称后端先把输入做分词处理去掉空格和常见的量词比如“一个塑料瓶”会被打成关键词“塑料瓶”。然后拿着关键词去garbage_info表里做匹配匹配方式分三层精确匹配优先完全命中直接返回类别其次做模糊匹配通过数据库索引查询名称中包含关键词的记录如果找到多条结果按相关度排序相关度可以简单定义成名称长度与关键词长度的差值越短越靠前。如果三层都没匹配到就返回“未收录根据常识选择类别”的提示避免直接报错。这种设计在代码里就体现为GarbageServiceImpl中的search方法。它先做精确查询没结果再走like查询最后对结果集做排序封装。整段逻辑不超过50行但效果很稳定。注意不要为了显得“高级”而硬上深度学习图像识别。识别一张图片需要训练集、推理模型、GPU服务器毕设答辩现场只要网络一卡整体体验会很糟糕。2.3 积分与兑换闭环业务如何串起来积分系统是很多展示型项目容易忽略的一环但垃圾分类系统如果砍掉积分用户投放记录就变成了流水账没有任何让人眼前一亮的东西。这套项目的积分流程是用户提交投放记录时前端传垃圾名称和预估重量后端先查垃圾类别再根据类别查points_rule表里的积分单价计算获得积分后写入recycle_record同时更新用户表的points字段。这中间有两个容易出错的地方。第一个是积分变更的原子性如果投放记录写入成功但用户积分更新失败数据就对不上了。项目里直接用Transactional把两步操作包在同一个事务里解决简单可靠。第二个是积分配置变更后老数据的处理逻辑项目里的处理方式是保留投放记录的当时积分快照字段避免规则修改后历史数据全乱。3. 后端Spring Boot关键实现细节3.1 项目骨架与分层架构拿到源码后不要急着打开所有文件先看包结构。这套项目采用经典的四层结构controller层做参数接收和接口定义service层写业务逻辑mapper层基于MyBatis操作数据库entity层对应数据表实体。另外还有独立的config包里放了CORS跨域配置和拦截器配置common包里放了统一返回结果类、异常处理类和分页对象。统一返回结果是我特别建议保留的一个设计。项目里所有接口返回的都是Result对象包含code、message、data三个字段。前端拿到返回体后统一判断code是否为200再做后续处理。好处是无论查询成功、参数错误还是服务器内部异常前端都走同一套处理逻辑调接口时心智负担小很多。{ code: 200, message: 操作成功, data: { total: 128, records: [...] } }3.2 数据库访问与接口开发MyBatis还是MyBatis-Plus项目里的数据访问层用的是MyBatis-Plus这一点要特别说明一下。MyBatis-Plus对单表CRUD的支持极好BaseMapper已经内置了增删改查方法开发效率比纯手写XML高出一大截。对于垃圾分类这种以单表操作为主的项目能用内置方法就绝不写SQL。但复杂查询也不能逃避手写SQL比如投放记录的分页统计、按时间段聚合积分这些都在mapper的XML文件里写原生SQL确保查询性能和灵活性。一个小建议如果你打算在这个基础上扩展一定要学会MyBatis-Plus的条件构造器QueryWrapper。这是最常见的写法也是网上教程代码出现频率最高的方式。我见过有人把QueryWrapper用成字符串拼接结果嵌套条件一多SQL直接报错。正确姿势是链式调用清晰又安全。QueryWrapperGarbageInfo wrapper new QueryWrapper(); wrapper.like(StringUtils.isNotBlank(name), name, name); wrapper.eq(category_id, categoryId); wrapper.orderByAsc(sort);3.3 登录鉴权与权限控制用户端和管理员端必须严格区分权限不然谁都能进后台的管理页面这个系统就没有任何可信度。项目用的是JWT 拦截器的方案。用户登录成功后后端生成一个包含用户id和角色信息的Token返回给前端。前端把Token存在localStorage里每次请求在Authorization请求头带上。后端拦截器拦截所有/api/**请求解析Token并校验有效期同时把用户信息放进ThreadLocal供业务层随时取用。这种方案比Session更契合前后端分离的场景因为没有服务端会话状态后端可以随时水平扩展。拦截器里要注意的是放行路径的配置登录接口和注册接口必须加到白名单否则会出现“登录接口自己报未登录”的奇怪问题。registry.addInterceptor(jwtInterceptor) .addPathPatterns(/api/**) .excludePathPatterns(/api/user/login, /api/user/register);拦截器里解析Token失败时统一返回401状态码。前端在Axios的响应拦截器里检测到401就跳转到登录页并清除本地Token。这个闭环不复杂但能让整个系统的登录体验顺滑很多。3.4 文件上传与Excel导入导出垃圾数据库如果靠手动录入几千条数据能录到崩溃。所以项目里做了一个Excel导入功能管理员在后台下载模板填写垃圾名称和类别后上传后端用EasyExcel解析并把数据批量插入数据库。配套的还有导出功能可以把投放记录、用户列表导出成Excel。EasyExcel的使用门槛很低只需要定义一个跟Excel列对应的实体类然后调用EasyExcel.read()传入输入流和监听器即可。项目里监听器每读取1000条数据就批量插入一次避免大文件上传时一次插入过多数据导致内存溢出。这个细节答辩时可以拿出来讲一下体现你对实际业务体量的考虑。4. 前端Vue实现与页面交互设计4.1 前端工程结构与路由设计前端部分用Vue CLI构建目录结构划分得很规范views目录按模块分页面router目录配置路由api目录封装每个模块的请求方法components目录放公共组件utils目录里是请求封装和工具函数。路由设计上用户端和管理员端采用不同的布局组件。用户端路由挂在LayoutUser下管理端路由挂在LayoutAdmin下同时在路由守卫里判断用户角色如果是管理员却访问用户端页面直接跳转到管理端首页。这种通过路由做权限控制的方式在后端拦截器之外又增加了一道防线安全性是双保险。const routes [ { path: /user, component: LayoutUser, children: [ { path: search, component: GarbageSearch }, { path: records, component: RecycleRecords }, { path: points, component: PointsMall } ] }, { path: /admin, component: LayoutAdmin, meta: { role: ADMIN }, children: [ { path: garbage-list, component: GarbageManage }, { path: records, component: RecordManage }, { path: statistics, component: Statistics } ] } ]4.2 页面组件拆分与复用思路前端最容易犯的错是一个页面写成一个巨大的组件几百行模板叠在一起改一个按钮要看半天。这套项目里的页面都做了组件拆分。以垃圾查询页为例它被拆成搜索区组件、结果列表组件、类别标签组件三个部分。搜索区负责输入和搜索按钮结果列表负责渲染列表和翻页类别标签负责筛选。这样每个组件只干一件事后续要调整样式或者替换交互逻辑改动范围非常小。复用性最高的是分页组件和图片上传组件。分页组件封装了页码切换和每页条数选择所有需要分页的列表页直接引用图片上传组件封装了上传逻辑、回显逻辑和删除逻辑投放记录里的照片和反馈里的图片都可以共用。4.3 Axios封装与接口对接前端与后端对接离不开Axios但很多人把代码写成了到处import axios到处写一遍get/post。这套项目在utils/request.js里做了一个统一封装实例化Axios时设置了baseURL、超时时间为10秒请求拦截器里从localStorage取Token并放到请求头响应拦截器统一处理后端返回的code。如果code不等于200弹出错误消息如果HTTP状态码是401跳转登录页。数据字典这类公共接口在api/dict.js里单独抽取避免每个页面重复写接口地址。实践下来这么做的最大好处是后端接口地址一旦变更只需要改一个文件不会出现全局搜索替换的灾难现场。4.4 数据可视化让项目在答辩时有亮点管理端的数据统计页面使用了ECharts展示了四类垃圾的占比统计、每天投放数量的趋势图、积分发放量排名前十的用户柱状图。这些图表的背后是后端提供的统计接口例如/api/admin/statistics/category-ratio返回各类垃圾的记录数占比前端拿到数据后简单组装成ECharts需要的格式即可。做图表有几个经验可以分享。第一个是图表容器必须设置固定高度否则ECharts渲染出来是空白。第二个是组件销毁前要调用chart.dispose()否则页面切换后内存泄漏会导致页面越来越卡。第三个是数据量少的时候不要硬做动态效果一个简单的饼图带图例已经足够清晰表达数据含义。5. 前后端联调、部署与问题排查实录5.1 本地联调环境搭建拿到源码到真正跑起来中间隔着的往往是一堆环境问题。后端要装JDK 8、Maven、MySQL前端要装Node.js和npm。后端启动前必须改两个配置文件application.yml里的数据库连接地址和密码以及file.upload-path指向本地一个存在的目录不然文件上传接口会报目录不存在。前端启动前在vue.config.js里配置开发服务器代理把/api开头的请求转发到后端http://localhost:8080这样才能解决跨域问题。devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }需要特别提醒的是后端如果加了跨域配置前端代理又转发一遍可能会出现二次跨域。解决办法是二选一要么后端配置CORS要么前端配代理不要两个同时上。5.2 部署打包步骤线上部署分成三步走。第一步是前端执行npm run build把生成的dist目录里的静态文件部署到Nginx。第二步是后端执行mvn clean package -DskipTests把项目打成jar包。第三步是配置Nginx做反向代理静态文件走Nginx/api的请求转发到后端的http://localhost:8080。Nginx配置里一个必须注意的坑是history路由模式。Vue Router如果用了history模式刷新页面时Nginx会返回404需要在location /里加上try_files $uri $uri/ /index.html;。这个问题在本地开发时不会暴露很多同学都是部署完刷新页面才发现白屏然后慌慌张张查两天。项目里路由默认用的是hash模式可以减少这个坑但如果你改成了history这段配置一定要加上。location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://localhost:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }5.3 常见问题与排查技巧速查表在实际开发调试过程中有一些问题出现的频率特别高我把它们整理成一个排查列表。问题现象可能原因排查与解决前端请求404代理配置错误或后端接口路径不一致先看浏览器Network请求的URL是否正确再确认RequestMapping路径和前端api目录里的地址是否一致后端启动报数据库连接失败MySQL没起或密码错误检查application.yml里的url和密码确认数据库已执行过初始化脚本登录报“用户名不存在”密码加密方式不一致或用户状态禁用确认注册时密码加密算法和登录校验算法一致检查status字段是否为1列表页数据不刷新后端返回分页数据格式不对确认返回体里total和records字段名与前端约定一致上传图片失败上传路径不存在或大小超限检查file.upload-path配置确认目录存在并检查spring.servlet.multipart.max-file-size配置跨域请求被拦截CORS配置缺失或重复使用后端CORS或前端代理二选一不要混用分类查询结果为空垃圾数据表里没有对应记录先执行Excel导入功能确认库里有数据再测试5.4 几个容易卡住的细节坑第一个坑是前后端时间格式不一致。后端Java返回的时间默认格式是2024-01-01T12:00:00前端显示的时候如果不做格式化页面上的时间看起来特别别扭。解决方式是在后端实体的时间字段上加JsonFormat(pattern yyyy-MM-dd HH:mm:ss)或者在全局配置里统一设置Jackson的日期格式。第二个坑是密码明文问题。有些初版源码里密码直接明文存储这是答辩时会被老师质疑的点。项目里提供了BCrypt加密方案注册时加密存入数据库登录时用BCryptPasswordEncoder校验千万别图省事改成明文。第三个坑是分页查询里的“幽灵数据”。如果你改了数据库里的数据但列表一直显示旧内容先检查浏览器是不是缓存了响应数据或者前端created生命周期里漏掉了首次加载数据的调用。6. 文档撰写、答辩准备与后期扩展6.1 毕设文档怎么写得有质量拿到完整源码只是第一步文档才是决定评分的另一只脚。这套项目自带的文档包含了选题背景、可行性分析、需求分析、系统设计、数据库设计、系统实现、系统测试和总结几个核心部分。写文档时要特别注意两点。第一点是数据库设计章节必须配上ER图和表结构说明。简洁的画几个表格把每个字段的含义、类型、约束列出来不需要堆砌十几页但要能讲清楚为什么这么设计。第二点是系统测试章节不能只写“功能正常”要写成你实际测试过的真实结果比如“输入关键词塑料瓶返回可回收垃圾响应时间125ms”这种数据才有说服力。6.2 答辩时容易被追问的6个问题根据我过往看过的答辩现场以下几个问题的高频程度相当高。第一个问题是“系统中智能体现在哪里”不要回避直接讲基于关键词匹配的分类识别逻辑把三层匹配策略说清楚再补充一句“如果后续要提升准确率可以引入分词服务和知识图谱”。第二个问题是“数据库表为什么这么设计”以积分规则独立建表为例解释这是为了灵活配置不侵入业务代码。第三个问题是“如何处理并发下的积分更新”提Transactional事务管理再把乐观锁思路讲一下。第四个问题是“前端如何实现权限控制”讲路由守卫加Token鉴权双层机制。第五个问题是“为什么选择Spring Boot而不是SSM”从配置简化、内嵌容器、生态整合三个角度回答。第六个问题是“系统有哪些可以改进的地方”不要只说“不知道”可以讲“目前分类匹配依赖关键词后续可以增加图像识别模块数据分析还停留在基础统计后续可以增加预测模型”这反而会加分。6.3 拿到源码后怎么做二次开发如果不想只做一个“复制粘贴型”选手建议在原有基础上做下面三个方向的扩展。第一个方向是给garbage_info增加别名表或同义词映射。目前匹配逻辑对“塑料瓶”“饮料瓶”这种同义词可能漏查新增一张别名表通过外键关联搜索时先查别名表再查主表能明显提升命中率。第二个方向是将积分兑换扩展成商品订单模块。现在积分兑换可能是简单的扣除逻辑如果加上商品表、订单表、发货状态整个项目的业务完整度立刻上升一个档次也更好写进文档。第三个方向是增加数据可视化的大屏展示页在管理端做一块大屏看板用ECharts把垃圾分类趋势、地区分布、投放热力图全部展示出来视觉效果非常加分。7. 写给大家的一些实在话我经手过不少类似的毕设项目也帮很多同学看过代码、改过Bug。最想说的一点是源码只是给你提供一套可运行的骨架真正值钱的是你能不能在老师面前把每个设计决策讲出道理。你不需要全部重写但一定要把核心代码逐行读一遍尤其是垃圾分类匹配、积分事务、登录鉴权这三块因为大概率会成为被提问的焦点。另外如果要往“简历项目”方向发展我强烈建议在做完上述扩展后把项目重新整理进自己的作品集附上系统截图、技术栈说明和你在项目里独立完成的模块列表。也许它只是一个课程级别的项目但只要你把“为什么这么设计”和“怎么排查问题”讲得清楚它依然能成为一份扎实的实践佐证。我个人在实操中最大的体会是答辩翻车往往不是因为项目不够复杂而是因为很多东西只是‘能跑’但没想通。把每个核心环节的逻辑都吃透哪怕代码是拿来的最后讲出来的效果也会完全不一样。针对这套系统最有价值的二次开发点就是把搜索命中率做上去、把积分商城做完整这两件事做完项目从“典型毕设”立刻变成“有业务深度的作品”。之后不管你是拿去参加比赛还是写进简历都拿得出手。
