★ FEATURED ARTICLE 每年三四月份我的私信里就会涌进来一堆有没有毕设推荐的留言。前两年我先后做过几套前后端分离的管理系统其中最贴近日常生活、也最适合拿来当毕业设计和课程设计参考的就是这套 SpringBoot Vue 城市垃圾分类管理系统。后端 Java SpringBoot前端 Vue持久层 MySQL麻雀虽小但五脏俱全从用户端到管理端都覆盖到了。你如果正准备做课设、毕设或者单纯想拿个完整项目练手 SpringBootVue 前后端分离开发这篇内容应该能帮你省掉不少自己摸索的时间。我接下来会把整个项目从需求梳理、技术选型、功能实现到数据库设计、跑通步骤、答辩准备和扩展方向完整地拆开来讲建议你重点看为什么这么设计而不是光盯着代码记。先把话说在前面这类系统的定位是演示完整、结构标准、方便讲解不是生产级高并发。理解这一点之后很多技术选型上的纠结都会迎刃而解。1. 项目定位垃圾分类系统到底要解决什么问题1.1 从生活场景倒推业务需求做任何管理系统第一步都不是打开开发工具新建工程而是先回答一个最朴素的问题这套系统做出来之后谁在用、用来干什么。垃圾分类管理系统的核心场景并不复杂社区的垃圾桶旁居民拿着手里的饮料瓶、过期药品、旧电池经常不确定它们应该进哪个颜色的桶这是最高频的刚需。物业或社区工作人员需要记录居民的投放情况维护各类垃圾的分类标准偶尔还要看一看哪个投放点被投诉多、哪类垃圾清运最频繁。街道或社区的管理者则更关心数据维度的问题某个小区一周厨余垃圾投放了多少次积分发放情况如何公告阅读量怎么样。把这些角色和使用路径抽出来系统的边界就立刻清晰了普通用户端提供分类查询、知识学习、投放记录提交和个人积分累积工作人员端提供分类标准维护、投放点管理、投放记录审核和公告发布系统管理员端提供账号管理、动态配置和数据统计。很多同学做毕设喜欢堆功能觉得模块越多越显得工作量足实际上功能边界越模糊代码越难组织答辩时也越难把为什么做这个模块讲明白。我在动手前会先在纸上把这三类角色对应的功能清单列出来后面建表、画路由、写 Controller 基本就是照着这张清单翻译成代码。1.2 功能模块地图三类角色各自的使用路径我按照角色把功能切成了三条路径。普通用户登录后核心路径是搜索并查询垃圾类别 → 确认分类结果 → 提交一次投放记录 → 获取积分 → 在积分列表里查看明细。整个流程闭环下来用户才会感觉我每一次正确分类都有反馈这也是系统留存用户的关键。工作人员进入后台核心路径是维护垃圾类型和常见物品的映射关系 → 审核用户提交的投放记录 → 编辑发布垃圾分类知识或社区公告。这些操作本质上都在维护数据质量保证前台展示的分类信息准确、统计报表里的数据干净。系统管理员除了基础的账号管理之外更多在做系统配置比如初始化角色权限、查看各业务模块的运行状态、看可视化统计报表。三种角色映射清楚之后前端路由、后端接口分组、数据库表结构就自然而然有了依据。我见过不少同学代码写到一半把自己绕晕原因基本都是动手前没在纸上画这张功能地图。1.3 毕设作品与生产系统的差别在哪里这里必须提前打个预防针个人毕设项目要做的是体现你对系统生命周期的完整理解而不是复刻大厂的高并发架构。很多同学一开始就纠结要不要上微服务、要不要加 Redis 缓存、要不要搞消息队列其实对于一套单机部署的前后端分离管理系统这些都是伪需求。SpringBoot 内嵌容器跑单个服务MySQL 存数据Vue 做界面这套组合已经能完整承载业务逻辑和交互演示。把微服务和技术栈的新留给口头聊聊可以但真正在代码里落地反而容易把项目拖进调试的无底洞。2. 技术选型SpringBootVueMySQL 这套组合的取舍逻辑2.1 为什么选 SpringBoot而不是 SSM 手写整合答辩时几乎必问的一个问题就是你为什么要用 SpringBoot。我的回答逻辑是这样的SpringBoot 本身没有抛弃 Spring 的依赖注入和面向切面思想而是通过自动配置和起步依赖把搭建框架的时间从几天压缩到几分钟。对时间宝贵的毕设项目来说内嵌 Tomcat、统一配置管理、生态丰富的 starter 组件能让你把精力集中在写业务代码上。用 Spring Spring MVC MyBatis 手动整合不是不行但各种 XML 配置、容器配置会消耗大量无效时间。从技能复用的角度SpringBoot 也是目前 Java 后端的主流入口。很多公司在校招时对 Spring 系列的使用经验非常看重。你通过这个项目把 Controller-Service-Mapper 的分层开发走一遍面试时聊项目就能聊出深度。如果之前只写过 Servlet JSP这套后端代码能让你直观地看到Controller 层怎么收参数、Service 层怎么做业务编排、Mapper 层怎么操作数据库。2.2 前端为什么锁死 Vue后端接口写完总得有个界面去消费这些接口。Vue 的优势在于渐进式框架特性你不需要一开始就理解整套响应式原理先会用模板语法和 v-model 双向绑定就能做出像样的页面等工程跑熟了再逐步理解 Vue Router 的路由管理、组件通信和状态管理。垃圾分类管理系统的界面交互不算复杂无非是表格展示、表单提交、选项卡切换、图表展示这些在 Vue 生态里都有非常成熟的组件库直接接。前端状态管理我建议根据团队熟悉度来选。类项目用 Vuex 或 Pinia 都可以但状态量不大的话不一定非要用状态库。我把登录信息和用户信息放在 localStorage通过 axios 拦截器统一读取大多数页面组件之间通过路由参数和 API 返回值沟通这套模式足够简单也容易向别人解释。2.3 MySQL 和数据访问层为什么是 MyBatis 而不是其他方案数据存储选 MySQL原因很朴素社区活跃、安装简单、图形化工具完善而且绝大多数高校数据库课程用的就是它。对于垃圾分类管理系统这种结构化数据用户表、分类表、投放记录表之间天然存在外键关系用关系型数据库描述非常直接。ORM 层面经典方案是 MyBatis新派方案喜欢 MyBatis-Plus。我选的是 MyBatis因为这类系统不涉及特别复杂的动态 SQL手写 XML 反而能加深你对 SQL 的理解。如果改用 MyBatis-Plus代码量会进一步减少但讲解时容易显得你在掉包不懂底层 SQL。2.4 工程目录一前一后两个项目怎么组织前端后端我采用了完全解耦的两个工程目录。后端是标准 SpringBoot Maven 工程分包规则是经典的 controller/service/mapper/entity/config 五层偶尔加一个 common 包放统一返回结果和异常处理。前端用 Vue CLI 或 Vite 初始化工程src 下按 views、components、router、api、utils、store 区分职责。这种结构是绝大多数前后端分离项目的通用组织方式面试官一看就知道你有工程化意识。后端每个 Controller 只返回统一的 Result 对象结构code、message、data前端 axios 响应拦截器统一解包这让前后端联调时的沟通成本低了很多。3. 核心功能拆解登录、分类、投放、统计的实现链路3.1 用户认证为什么我用 JWT 自定义拦截器而不是直接上 Spring Security认证方案是一个容易纠结的点。很多同学一听说登录认证就条件反射地要上 Spring Security JWT我建议根据项目工作量评估。Spring Security 的过滤器链、AuthenticationManager 这些概念对初学者来说学习曲线偏陡用在毕设里容易让代码变成配置黑盒。我这里采用的方案是自定义 JWT 认证登录成功之后后端用用户信息和过期时间生成 token 返回前端前端存到 localStorage每次请求通过 axios 请求拦截器把 token 放进 Authorization header后端再写一个 HandlerInterceptor 统一校验 token放行登录接口和少量公开接口其余接口全部校验。这个方案的好处是你能把原理讲清楚token 是什么、为什么放 header、后端如何解析、过期怎么处理。演示的时候被问到token 过期了会怎么样你可以直接打开接口文档演示返回 401 的状态。如果你非要集成 Spring Security这个系统的权限模型也只有两种角色加接口路径匹配规则足够简单用 Security 反而显得大材小用。3.2 垃圾分类查询模糊匹配、别名映射与结果返回分类查询是整个系统的门面居民用它的频率最高。我的实现思路是维护一张垃圾物品表里面记录常见物品名称、所属大类、别名关键词、投放提示和处理方式。查询时用关键词做模糊匹配同时通过 nickname 字段做别名映射。举个例子用户搜索矿泉水瓶系统通过别名映射能命中塑料瓶这条物品记录返回的类别是可回收垃圾颜色标识是蓝色提示语是清洗后压扁投放。这个细节看似小但答辩时非常加分因为它证明你考虑了真实用户习惯而不是只做了简单 as like 查询。为了让分类知识库显得充实初始化数据阶段我准备了上百条常见物品覆盖厨房、客厅、卫生间、办公场景几乎能覆盖演示时任意一次随机搜索。垃圾大类目前按国内常见的四分法维护可回收、有害、厨余、其他。3.3 投放记录与积分累计业务闭环怎么连贯起来用户查询完分类之后可以提交一次投放记录选择投放点和垃圾类别系统记录投放时间。这一条数据落库之后就成了后续所有统计报表的基础。积分规则我设计得很直观每次有效投放积 10 分管理员可调整单次积分积分累计到一定数量之后可以在积分兑换模块里兑换一些小礼品。一条投放记录从提交到积分到账链路是前端提交记录 → 后端落库 delivery_record → 生成一条 points_record 积分流水 → 更新用户的 total_points 字段 → 前端重新拉取用户信息展示最新积分。积分流水表的出现特别重要。很多新手项目只会在用户表里存一个 total_points 字段结果就是积分变了你都不知道为什么变。加了流水表之后每次积分变动都能追溯到具体业务这既是数据库设计的经验也是答辩时可以主动聊的一个亮点。3.4 管理后台分类维护、记录审核与统计图表后台管理功能是前端和数据结构完整性的体现。工作人员可以新增、编辑、停用垃圾条目把一些有歧义的分类规则修正掉投放记录如果被标记为可疑可以在后台置为无效防止刷积分的脏数据污染统计结果。公告模块负责发布垃圾分类知识宣传内容前端以列表形式展示用户点进去能看详情。统计模块我用了 ECharts 做三张图按垃圾类别的投放占比饼图、近七天的投放趋势折线图、各投放点任务量的柱状图。后端统计接口的 SQL 并不复杂核心是 Group By 加时间函数配合定时任务可以生成日报数据。ECharts 是前端生态里最容易出效果的可视化库放到答辩 PPT 里观感非常好我强烈建议你哪怕只做这一张图也要把 ECharts 集成进去。4. 数据库设计一张表一张表讲清楚4.1 表结构总览九张核心表分四个业务域数据库我一共建了九张核心表按业务域分成四组账号权限域包括 sys_user用户表、sys_role角色表、sys_user_role用户角色关联表分类知识域包括 garbage_type垃圾大类和 garbage_item垃圾物品明细投放业务域包括 delivery_record投放记录、points_record积分流水、exchange_order积分兑换订单内容管理域有 notice公告表。不要小看这九张表的组织逻辑很多同学做系统会漏掉角色中间表或积分流水表导致后期扩展困难。表的数量不是越多越好能完整覆盖业务流程、关系清晰才是标准。4.2 sys_user 与角色关联细节都在字段设计里sys_user 表大约 12 个字段重点关注几个设计细节。username 字段加唯一索引登录时能快速检索password 字段存的是加盐哈希而不是明文这个细节体现了安全意识status 字段控制账号是否可用后端登录时先校验状态再比对密码。角色关联我用中间表 sys_user_role而不是直接在用户表里存 role_code原因是将来可能出现一个用户同时具备小区管理员和督导员两种角色一对一设计会阻塞这个扩展。这种多对多通过中间表关联的思考方式在答辩时是一个容易被加分的小亮点。4.3 garbage_type 与 garbage_item垃圾分类的层次结构垃圾分类是典型的父子结构上层是四大类下层是海量具体物品。我的做法是把大类单独建表垃圾物品表里用 type_id 做逻辑外键。相比把父类 ID 写在同表里的单表树结构分两张表更直观查询某大类的全部物品只需要一条 sql 加 where 条件即可。garbage_item 表里设了 keyword 字段存储逗号分隔的别名关键词专门为模糊查询服务。需要说明的是用逗号分隔存储多值字段在正规企业级应用里不算最佳设计但在当前场景下查询灵活、实现简单我会在答辩时主动说明这个取舍展示自己在数据建模上的思考。4.4 delivery_record 与 points_record业务数据如何沉淀投放记录表是统计的核心字段包括 user_id、garbage_type_id、delivery_point、delivery_time、audit_status、audit_remark。audit_status 这个审核位值得强调它能防止为了刷积分乱填记录的脏数据进入统计结果。管理员审核通过之后该条记录才会计入报表和积分。积分流水表记录每一次积分变动字段包括 change_type增加或扣减、amount、balance_after、remark、create_time。业务上坚持任何积分变动都生成一条流水的规则越早养成这个习惯越好以后做积分对账、数据回溯都会非常方便。4.5 索引与时间字段两个容易被忽视的坑第一delivery_record 的 delivery_time 字段建议在业务查询频繁的字段上加普通索引横跨一个月的数据量一旦上去没有索引的统计 SQL 会明显变慢。第二MySQL 的 timestamp 和 datetime 选择上建议统一用 datetime并设置默认值为 CURRENT_TIMESTAMP。这样新增数据时不需要前端传时间服务端自动补齐避免因为时区差异导致的显示错乱。数据库设计里的这些小细节往往会让看代码的人觉得你确实有实战经验而不是只会照着教程抄。5. 从拉取代码到跑通环境配置与高频踩坑记录5.1 环境准备清单先装什么、再启动什么如果你准备把这个项目跑起来环境方面请准备JDK 8 或 JDK 11Maven 3.6 以上MySQL 5.7 或 8.0Node.js 14 以上和 npm后端 IDE 推荐用 IntelliJ IDEA前端用 VS Code 即可。启动顺序上务必注意先安装 MySQL 并初始化数据库脚本再启动后端最后切到前端工程执行 npm install 和 npm run dev。这个顺序能最快帮助你定位问题到底是出在前端、后端还是数据库。很多人一上来就直接打开两个 IDE一个报错接着另一个报错很容易心态崩掉。5.2 初始化数据光建表远远不够建库建表只是第一步初始化数据才是项目能呈现出完整效果的关键。项目里准备一个 init.sql 脚本除了建表还会预置管理员账号、常用垃圾物品数据、角色数据和几条公告。这里特别提醒垃圾物品的初始化数据一定要够多、够贴近真实生活至少准备上百条常见物品。否则演示的时候随便搜一个词没有结果整场演示就变成大型尴尬现场。积分规则、垃圾大类颜色标识这类基础配置也应该提前在代码里或者配置表里初始化好不能让用户第一次打开就看到空列表。5.3 三个高频坑跨域、端口冲突、中文乱码前端跑在 8080 端口后端跑在另一个端口第一个遇到的基本都是跨域问题。解决方案很简单在后端加一个全局 CORS 配置类允许来自前端开发服务器的 origin同时允许 PUT、DELETE 等方法这是最轻量的解法。第二个坑是端口冲突很多同学开着 MySQL 或上次的前端进程导致 3306 或 8080 被占用启动时报错。建议把所有端口和连接串集中在 application.yml 文件里统一管理排错时一眼能看全。第三个坑最常见也最隐蔽——数据库连接串没加 useUnicodetruecharacterEncodingutf8导致中文字符存进数据库变成问号。这个问题一旦出现排查起来非常费劲配置里提前写好参数能省很多事。5.4 启动检查清单怎么确认项目真的没跑偏后端启动看到 Tomcat started on port 字样后先用浏览器或接口调试工具访问登录接口确认能正常返回 token再启动前端。前后端接口如果对不上优先去前端工程里查看 devServer 的 proxy 配置确认 /api 前缀正确转发到后端地址。这一环是整个联调里最容易出错的地方。前端界面能打开之后我建议完整走一遍查询分类 → 提交投放 → 管理员审核 → 查看统计的链路确认每个按钮都有响应、每张表都有数据再开始准备演示或截图。6. 让项目从合格到加分答辩准备与扩展思路6.1 答辩前要刻意准备的五个问题毕设验收和答辩老师通常不会逐行检查代码他们更关心你是否真的理解这个系统。我结合自己的经验列了五个高频问题为什么选垃圾分类作为题目系统的核心业务流程是什么请从头到尾讲一遍数据库为什么这么设计中间表和流水表解决了什么问题遇到跨域、乱码、token 过期这类问题怎么排查如果现在要增加一个新功能比如 AI 识别垃圾类型你会怎么设计。每个问题准备一个能从从容容展开三分钟的回答现场发挥会稳定很多。6.2 低成本增加亮点的扩展方向如果时间和精力允许在原系统上加一两个扩展点整体完成度会立刻不一样。我列几个比较常见的升级方向第一个是接入第三方图像识别接口用户上传垃圾照片自动识别垃圾类别这个功能演示效果极具冲击力第二个是完善积分兑换的完整流程包括积分商城库存、订单状态管理和发货记录第三个是在管理后台增加大屏统计页一打开就能看到整个区域的投放热点和趋势变化第四个是用 EasyExcel 导出投放记录和积分报表代码量不大但含金量高属于企业开发里非常常见的需求。6.3 学习这套源码的正确姿势最后聊一下学习源码的顺序。拿到代码之后不建议按目录从上到下逐行阅读那样很容易陷入细节出不来。我的推荐路径是先把项目跑通然后一边操作页面一边看数据库理解每条数据是怎么从页面流到表里的接着只看后端 controller 到 mapper 的链路理解接口的输入输出再切到前端从 router 出发看页面组件怎么调用 API最后回到数据库设计重新思考如果让你从零建库你会怎么建。这条链路完整走两三遍之后整套系统才真正变成了你自己的东西。7. 写在最后一个很实在的建议从选题、编码到帮别人排查问题我前前后后接触这套城市垃圾分类管理系统的时间不算短。如果只让我给一条最实用的建议那就是千万别跳过需求梳理和技术选型直接冲向编码。很多代码写到最后改来改去的同学问题恰恰出在动手之前对系统的功能边界没有想清楚。另外调试过程中遇到报错不要慌SpringBoot 的报错信息其实相当友好从堆栈第一行往下找八成问题都出在自己写的 SQL 或者配置文件上。你要是正在做类似项目欢迎在评论区聊聊你跑这套系统时遇到的最奇怪的问题大家一起交流解法。
阅读完成 · 觉得有帮助？
