SpringBoot+Vue垃圾分类管理系统实战：从功能设计到权限控制全解析

1. 这个项目的真实定位：毕设/课设为什么都盯上它

城市垃圾分类管理系统，这个名字听起来平平无奇，但它几乎是目前Java毕设选题里最稳的一类。你要是去各大师兄师姐的选题清单里翻一圈，十有八九能看到类似的东西，因为它的需求足够明确、业务逻辑足够完整、技术栈又正好踩在主流路线上。

先说技术栈：SpringBoot + Vue + Java + MySQL。这四个词放在一起，基本就是国内后端开发的“标准配置”。SpringBoot负责后端接口，Vue负责前端页面，MySQL存数据，Java是SpringBoot的底层语言。这套组合的覆盖面很广，学校里教的Java Web、数据库、前端基础全都能用上，而且出去找工作面试，聊这套也完全不虚——企业里大量的内部管理系统就是这么搭的。

再说业务侧。垃圾分类这个主题，天然适合做系统：用户端要注册登录、要查询垃圾类别、要预约回收、要积累积分；管理端要管理用户、管理分类规则、管理回收订单、看统计数据。这些功能组合起来，构成了一个“麻雀虽小五脏俱全”的管理系统，CRUD（增删改查）、权限控制、文件上传、图表统计全都能涉及。用在毕设答辩上，评委老师不会觉得太简单，也不会觉得跑偏；用在课设上，工作量适中，一个人完全扛得住。

我见过不少同学毕设选这题，但最后拿出来的东西千差万别。差别不在“能不能跑”，而在“做出来像不像那么回事”。同样是垃圾分类管理系统，有人交的是几个页面堆在一起、数据库就三五张表的demo，有人交的是角色清晰、流程完整、界面规整的完整平台。差距从哪里来？从设计思路上来，从功能取舍上来，从细节打磨上来。这篇文章我就把这套系统的设计思路、核心实现和坑，从头到尾拆一遍。

2. 功能模块设计与技术选型拆解

2.1 用户端功能：先想清楚“谁会用什么”

做任何管理系统，第一步不是写代码，是先想清楚系统里有哪几类人，每类人进来干什么。

垃圾分类管理系统一般分三类角色：普通用户、垃圾分类管理员（或审核员）、系统管理员。

普通用户端大概需要这些功能：

• 注册/登录，密码加密存储，别明文入库。
• 垃圾分类查询，这是整个系统的灵魂功能，输入垃圾名称，返回属于哪类、怎么投放。
• 预约回收，用户提交回收请求，填写地址、垃圾类型、预约时间。
• 积分体系，完成回收、正确分类可以获得积分，积分可以兑换小奖品或抵扣费用。
• 个人中心，查看自己的积分记录、回收记录、预约状态。

管理员端则围绕“审核与配置”展开：

• 用户管理，查看用户列表、禁用违规账号。
• 分类规则管理，维护垃圾分类标准，尤其是易错品类的说明。
• 回收订单处理，查看待处理预约、指派回收员、更新订单状态。
• 数据统计，按区域、按垃圾类别展示回收量、用户活跃度。

这套功能设计有两个好处。第一，每个功能都是刚需，不存在硬凑的模块；第二，功能之间是有关联的——用户预约回收会生成订单，订单完成后会触发积分变动，积分变动又会进入统计报表，整条链路是通的。答辩时老师顺着这条链路往下问，你能一直回答到他满意为止。

2.2 技术栈选型：为什么是SpringBoot+Vue而不是别的

选SpringBoot而不是SSH（Struts+Spring+Hibernate），选Vue而不是JSP，最直接的原因是：时代变了。

SpringBoot最大的价值是“约定优于配置”。以前用SpringMVC，光写配置就要折腾半天：web.xml、spring-mvc.xml、数据源配置、事务管理器。SpringBoot把这些全部内置或自动配置了，一个启动类起来，项目就跑起来了。对毕设来说，这意味着你少踩一半的坑，把精力花在业务实现上。对企业来说，快速交付、独立部署，也正是后端服务该有的样子。

Vue这边就更不用说了。Vue2/Vue3 + Element UI（或者Element Plus），是中后台管理系统的黄金搭档。组件化开发把页面拆成一个个组件，写起来清晰，维护起来也轻松。相比之下，JSP那套前后端不分离的写法，交出去说难听点，已经不太拿得出手了。前后端分离是当前主流，你在毕设里用前后端分离架构，本来就是加分项。

MySQL没什么好多说的，免费、稳定、生态成熟，大学课程、培训机构、中小企业都用它。配合Navicat或DBeaver管理数据库，建表、导数据都方便。另一个细节是MyBatis-Plus，用它的MyBatis-Plus可以省掉大量XML SQL，简单查询直接用封装好的方法，复杂查询再手写SQL，对毕设来说效率高不少。

2.3 角色与权限：权限控制做到什么程度算“够用”

权限这块，很多课设级项目做得非常简陋——登录进去，一个按钮切角色，或者压根不做角色区分。这不行，因为权限控制是管理系统的基本功，也是答辩时老师大概率会问的点。

我的建议是基于SpringBoot整合Spring Security或者Shiro，用JWT做无状态认证。大概思路是这样的：

• 登录成功，后端生成一个JWT token，里面带上userId和role。
• 前端把token存到localStorage里，每次请求在header里带Authorization: Bearer xxx。
• 后端用拦截器或Spring Security的过滤器链校验token，根据接口要求的角色判断能不能放行。
• 前端路由也用角色做守卫，普通用户访问管理页面直接拦掉。

这套机制并不难，核心代码量不大，但做完之后系统的完成度会明显上一个台阶。权限控制的意义在于：确保每个角色只能操作自己该操作的东西。这是系统安全性的最低要求，也是毕设评分里容易拉开差距的地方。

3. 核心细节解析与实操要点

3.1 垃圾分类查询功能：数据库设计决定体验

垃圾分类查询是整个系统的门面，也是用户用得最多的功能。它的核心是“一个垃圾名称对应一个分类结果”，但实际做起来要注意的事情不少。

数据库层面，我建议单独建一张garbage_category_rule表，存垃圾分类规则。字段可以这样设计：

• id：主键，自增。
• garbage_name：垃圾名称，加索引，查得快。
• category_type：分类类型，1可回收物、2有害垃圾、3厨余垃圾、4其他垃圾。
• category_name：分类名称冗余字段，方便前端直接显示。
• tips：投放提示，例如“沥干水分后投放”“灯管请轻放”。
• create_time、update_time。

接口设计上，提供两个接口：

• 精确匹配：GET /api/garbage/query?name=电池，命中就返回分类。
• 模糊搜索：GET /api/garbage/search?keyword=废纸，返回匹配列表，用户选一个。

这里有个体验细节：不能只做精确匹配。用户输入“塑料瓶”，你库里存的是“PET塑料瓶”，精确匹配就找不到了。所以查询接口一定要考虑模糊搜索，甚至可以做同义词映射——比如“垃圾袋”和“塑料袋”在很多地方属于不同分类，你要么在规则表里分别建两条数据，要么做一层名称归一化。

我见过最朴素但很有效的方案：规则表数据量做到几百条以上，把日常生活中常见垃圾全部覆盖一遍。数据量充足时，用户随便搜一个常见垃圾都能出结果，系统的“智能感”马上就出来了。数据哪里来？各城市的垃圾分类指导目录、环保类公众号的推文，都可以整理导入。

3.2 预约回收与订单状态机：流程要能闭环

预约回收不能只是一个简单的“提交成功”，否则后台管理员没有任何事情可做。一个合理的流程应该是：

用户提交预约（状态：待审核） → 管理员审核通过并指派回收员（状态：待回收） → 回收员上门完成回收并确认（状态：已完成） → 系统发放积分并记录 → 用户确认收货？不需要，管理员确认就够。

这就是一条状态机。状态字段建议用整型或者字符串枚举存，比如1待审核、2待回收、3已完成、4已取消。每次状态变更，在order_log表里留一条操作记录，谁在什么时间把订单从什么状态改到什么状态。这样出了问题能追溯，答辩时也能展示“操作留痕”的思路。

预约单的数据库表，核心字段包括：

• order_no：订单号，自己生成的业务编号，别用自增id直接给用户看。
• user_id：下单用户。
• garbage_type：垃圾类型。
• estimated_weight：预估重量，方便回收员带工具。
• address：上门地址。
• appointment_time：预约上门时间。
• status：状态值。
• handler_id：处理该订单的管理员或回收员。
• remark：备注。

3.3 积分体系：别小看这个模块的联动性

积分模块看似简单，其实它牵扯到好几张表：积分规则表、用户积分明细表、积分兑换记录表。如果你做的是“积分兑换礼品”，那还要加一张礼品表和一份库存字段。

我的建议是，积分变动一律走“积分流水表”，不要直接改用户身上的总积数字段。什么意思？比如用户完成一单回收得50分，你不要只执行update user set points = points + 50，你要往points_record表里插入一条记录：用户ID、变动数额（+50）、余额（变动后的总积分）、来源类型（回收订单）、关联订单号、时间。

这个做法的价值在于：所有积分变动有据可查，用户质疑“我积分怎么少了”时你能直接翻流水。而且做报表、做统计分析的时候，流水表就是天然的数据源。

至于积分兑换，可以在前端做一个积分商城页面，展示可兑换的商品和所需积分，用户点击兑换，后端校验积分充足则扣减并生成兑换记录，然后管理员在后台标记“已发货”或“待领取”。加上这个模块之后，用户端就不只是“查询工具”，而是一个有激励闭环的产品。

4. 实操过程与核心环节实现

4.1 后端工程结构：分包分得好，代码写不愁

我强烈建议后端工程按下述结构分包，别把所有类都堆在一个包下：

com.example.garbage ├── controller // 接口层 ├── service // 业务逻辑层 │ ├── impl ├── mapper // MyBatis-Plus Mapper接口 ├── entity // 数据表实体类 ├── dto // 请求/响应对象 ├── config // 配置类（跨域、安全等） ├── common // 统一返回结果、异常处理、工具类 └── utils // JWT工具、加密工具等

controller层只做参数接收、调用service、返回结果，业务逻辑全放service层，mapper只做数据库操作。这样分层的好处是代码清晰，出了问题好定位，也方便答辩时讲“我采用了分层架构设计”。

统一返回结果类也很重要。前端拿到的不应该是裸数据，而是一个固定结构，比如：

{ "code": 200, "message": "success", "data": { ... } }

前端根据code判断成功还是失败，这样前后端对接时心智负担小很多。这个Result类建议封装好，整个项目都用它。

4.2 数据库建表：一张表都不能少

数据库是整个项目的地基。这里我给出一个最小可用的表结构清单，覆盖前面提到的所有功能：

• user：用户表。ID、用户名、密码（BCrypt加密）、昵称、手机号、角色类型、积分、状态、创建时间。
• garbage_category_rule：垃圾分类规则表。
• recycle_order：回收预约订单表。
• points_record：积分流水表。
• points_goods：积分商品表（如果你做商城）。
• points_exchange_record：积分兑换记录表。
• announcement：公告表（可选，但建议加，管理端发布通知，用户端展示）。
• feedback：用户反馈表（可选，用来体现系统的“完整度”）。

建表时一些通用字段别省：create_time、update_time用datetime类型，deleted用tinyint做逻辑删除。逻辑删除是个细节，MyBatis-Plus自带@TableLogic注解，配置一下就能用。好处是数据不真正删除，误删可以恢复，统计时也能保留历史数据。

下面给出一段建表SQL示例，建recycle_order表：

CREATE TABLE `recycle_order` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `order_no` varchar(64) NOT NULL COMMENT '订单编号', `user_id` bigint(20) NOT NULL COMMENT '用户ID', `garbage_type` varchar(32) DEFAULT NULL COMMENT '垃圾类型', `estimated_weight` decimal(10,2) DEFAULT NULL COMMENT '预估重量(kg)', `address` varchar(255) DEFAULT NULL COMMENT '上门地址', `appointment_time` datetime DEFAULT NULL COMMENT '预约上门时间', `status` tinyint(4) DEFAULT '1' COMMENT '状态: 1待审核 2待回收 3已完成 4已取消', `handler_id` bigint(20) DEFAULT NULL COMMENT '处理人ID', `remark` varchar(500) DEFAULT NULL COMMENT '备注', `create_time` datetime DEFAULT NULL, `update_time` datetime DEFAULT NULL, `deleted` tinyint(1) DEFAULT '0', PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_user_id` (`user_id`), KEY `idx_status` (`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='回收预约订单表';

几个细节：订单号加唯一索引，避免重复；user_id和status加上普通索引，因为查用户订单、按状态筛选是高频查询；字符集用utf8mb4，不要用utf8，否则生僻字和表情符号会出问题。

4.3 前后端联调环境：跨域和代理一次配好

前端开发服务器（比如Vue默认的8080端口）是localhost:8080，后端接口是localhost:9090，两者端口不一致，必然遇到跨域问题。这个问题不解决，前端调接口全是CORS报错。

推荐的解决方式有两个，建议前后端配合使用：

方式一：后端开启全局跨域配置。在SpringBoot里加一个配置类，或者直接在启动类上加@CrossOrigin注解的全局写法。我用的是实现WebMvcConfigurer的方式：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("*") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

方式二：前端Vue开发环境配置代理。在vue.config.js里配置：

module.exports = { devServer: { port: 8080, proxy: { '/api': { target: 'http://localhost:9090', changeOrigin: true } } } }

这两种方式在实际开发里经常同时存在，但部署到生产环境时，前端打包后通常由Nginx托管，反向代理到后端服务，跨域问题在Nginx层面解决就可以了。

4.4 一个关键接口的完整实现示例

以垃圾分类查询为例，从Controller到Mapper，我们看一遍全链路代码。这个例子能帮你理解SpringBoot项目的请求处理过程：

Controller：

@RestController @RequestMapping("/api/garbage") public class GarbageController { @Autowired private GarbageService garbageService; @GetMapping("/query") public Result<GarbageCategoryRule> queryByName(@RequestParam String name) { return Result.success(garbageService.queryByName(name)); } @GetMapping("/search") public Result<List<GarbageCategoryRule>> search(@RequestParam String keyword) { return Result.success(garbageService.search(keyword)); } }

Service：

@Service public class GarbageServiceImpl implements GarbageService { @Autowired private GarbageCategoryRuleMapper garbageCategoryRuleMapper; @Override public GarbageCategoryRule queryByName(String name) { return garbageCategoryRuleMapper.selectOne( new LambdaQueryWrapper<GarbageCategoryRule>() .eq(GarbageCategoryRule::getGarbageName, name) .last("limit 1")); } @Override public List<GarbageCategoryRule> search(String keyword) { return garbageCategoryRuleMapper.selectList( new LambdaQueryWrapper<GarbageCategoryRule>() .like(GarbageCategoryRule::getGarbageName, keyword)); } }

Mapper：

public interface GarbageCategoryRuleMapper extends BaseMapper<GarbageCategoryRule> { }

MyBatis-Plus的BaseMapper已经提供了selectOne、selectList这些基础方法，配合LambdaQueryWrapper用起来非常顺畅，不需要写XML。这也是我推荐MyBatis-Plus的原因之一——基础CRUD直接被封装好了。

5. 常见问题与排查技巧实录

5.1 问题速查表

我做毕设指导时，见过太多同学卡在同样几个问题上，这里整理一个速查表：

5.2 后端启动不了？大概率是端口或依赖冲突

SpringBoot项目起不来，是新手遇到最多的问题。我遇到过的几种典型情况：

MySQL版本和驱动不匹配。现在很多同学用的是MySQL 8.x，驱动类名是com.mysql.cj.jdbc.Driver，URL里要加serverTimezone=Asia/Shanghai。如果你用的是MySQL 5.7，老配置也能跑，但建议统一用新版。

端口被占用。后端默认8080，Vue开发服务器也默认8080，两边没改配置就会冲突。建议后端端口改成9090或者8081，前端保留8080，两边各占一个，互不干扰。

依赖冲突。SpringBoot版本和MyBatis-Plus版本如果不兼容，会出现各种莫名其妙的报错。我的建议是：直接用SpringBoot官网生成的初始项目，再引入MyBatis-Plus时选对应兼容版本，别在版本号上乱试。

5.3 前端启动不了？先检查Node环境和依赖安装

Vue项目起不来，十有八九是依赖没装好。第一次npm install可能要等很久，甚至失败。常见原因包括网络问题、Node版本过低。解决方式：把npm镜像源切到国内镜像，然后用npm install重新安装依赖。如果node_modules坏了，删掉重新装：

rm -rf node_modules package-lock.json npm install

Vue项目还需要关注Node版本。Vue3通常要求Node 14以上，版本太低会直接报语法错误。装个nvm来管理Node版本会省心很多。

5.4 答辩前最容易忽略的检查项

代码都跑通了，功能都做完了，但离“高分毕设”可能还差几步：

第一，把系统里的垃圾数据清掉，把演示账号准备好。评委很可能自己上手点两下，别让他看到一堆乱码和测试数据。

第二，把README写好。写上项目简介、技术栈、功能清单、运行步骤、默认账号密码。这份文档既是给评委看的，也是给未来的自己看的。

第三，把数据库初始化脚本单独放在sql/目录下。有的评委想看建表语句，你直接给他一个SQL文件，印象分会好很多。

6. 写代码前必须想清楚的几件事

6.1 “抄”代码可以，但不能只会抄

毕设选题撞车率极高，SpringBoot+Vue的垃圾分类管理系统，网上确实有一堆现成的源码。但我的建议是：你可以拿源码当参考，但一定要能回答“为什么这么写”。

具体来说，你把源码下载下来之后，先别急着跑，先做三件事：

• 看数据库表结构，理解每条字段的意义。
• 看Controller和Service层的代码，搞清楚一个请求从前到后走了哪些步骤。
• 自己动手改一个功能，比如把“回收订单列表”改成按时间倒序，或者加一个“按区域筛选”。

等你把这三点做完了，这套源码才是你的。否则一问三不知，答辩时老师随便问一句“这个状态字段为什么要用数字而不是字符串”，你就卡住了。这种场面，每年都在发生。

6.2 工作量不够？这些方向可以增加亮点

如果你的课设或毕设要求比较高，基础功能做完之后，可以考虑这些方向扩充：

• 图表统计：用ECharts做垃圾分类占比、月度回收量趋势、用户增长图。这是最直观的提分项。
• 文件上传：在管理端允许上传垃圾分类宣传图片，或者用户上传垃圾照片辅助判断分类。
• 消息通知：用户预约状态变更时，通过站内信或邮件提醒。
• 回收员角色：在管理端和用户端之间加入回收员角色，形成完整的三角色协作。

6.3 关于“二次开发”这件事

前端想换成Vue3？后端想加个Redis缓存？这些都是可行的，但没必要为了炫技而做。毕设的核心是完成度和逻辑自洽。你用了Redis，就要能说清楚缓存了什么、缓存失效策略是什么。你用了Vue3，就要能回答Composition API和Options API的区别。如果你当前的水平还说不清楚，那宁可保持技术栈简单，也不要给自己挖坑。

从实用的角度说，SpringBoot + Vue2（或Vue3）+ MySQL这套组合，已经完全足够支撑一个有深度、有广度、能答辩、能跑通的毕设项目了。把基础模块做扎实，把关键流程讲清楚，比盲目堆技术更能拿高分。

我个人在实际指导中感触最深的一点是：很多同学不是写不出代码，而是不知道做到什么程度算“好”。垃圾分类管理系统这个题目，下限很低，上限也不低。你愿意在积分流水、状态流转、权限控制这些细节上去打磨，呈现出来的作品和那些只做了个增删改查的demo，一眼就能看出差别。把这些细节吃到透，你的项目就不只是“能跑”，而是“耐看”。