毕业设计实战：基于SpringBoot+Vue+MySQL的垃圾分类回收系统设计与实现指南
在开发“基于SpringBoot+Vue+MySQL的垃圾分类回收系统”毕业设计时，曾因“垃圾出库申请表未通过垃圾ID与用户ID双外键关联”踩过关键坑——初期仅单独设计申请表的编号字段，未与垃圾回收表、用户表建立关联约束，导致统计某垃圾的出库记录时需手动匹配数据，耗费1.2天重构表结构、补全关联SQL才解决问题📝。基于此次实战经验，本文精简拆解核心开发流程，附避坑要点，为同类毕设提供高效落地参考。
一、需求分析：聚焦核心功能，避免冗余返工
部分同学易陷入“功能堆砌”误区，比如笔者曾耗时1.5天开发“垃圾数据可视化大屏”，最终因偏离“垃圾管理、运输跟踪、出库申请、公告通知”核心需求被导师要求删减。明确“角色-功能”对应关系是关键。
1. 核心角色与功能（精简版）
| 角色 | 核心功能 |
|---|---|
| 管理员 | 垃圾管理（新增/编辑/删除垃圾信息）、运输管理（跟踪运输进度）、出库审核、公告发布、用户管理 |
| 用户 | 垃圾回收查询、出库申请（提交申请理由/时间）、公告查看、个人中心管理 |
2. 需求避坑要点
- 拒绝空想调研：邀请5-6名同学模拟“管理员录入垃圾-用户提交出库申请-管理员审核”流程，基于“用户需快速查看垃圾库存”需求，增设“库存状态标签”，实用性远大于冗余的“可视化大屏”；
- 明确约束条件：提前规定“垃圾照片仅限JPG/PNG（≤5MB）”“垃圾编号自动生成（格式：LJ+年份+序号，如LJ2024001）”“出库申请理由≥10字”，为编码提供依据。
二、技术选型：优先稳定适配，拒绝盲目追新
前期曾跟风选用SpringBoot 3+Vue 3+Redis技术栈，因Redis缓存配置不当导致垃圾库存数据丢失，调试耗时1天。最终确定“稳定型”技术组合，新手易上手：
| 技术工具 | 选型理由 | 避坑提醒 |
|---|---|---|
| SpringBoot 2.7 | 简化配置，支持自动装配，高效实现垃圾管理、出库审核等模块 | 配置数据库连接时需加“useSSL=false”，避免连接失败 |
| Vue 2.x | 轻量易上手，组件化开发，快速实现垃圾列表、申请表单等页面 | 搭配ElementUI，避免Vue 3.x兼容问题 |
| MySQL 5.7 | 支持事务与外键，满足多表关联（垃圾-出库申请-用户），utf8mb4解决生僻字乱码 | 手动设置编码为utf8mb4，避免申请备注乱码 |
| Tomcat 8.5 | 适配SpringBoot与Vue，支持热部署，减少重启耗时 | 端口设为8081，避免与默认8080端口冲突 |
三、数据库设计：精简关联，避免数据混乱
数据库是系统核心，前期因未关联“垃圾回收表”与“出库申请表”，导致无法追溯垃圾出库历史，后续用“实体-属性-关系”分析法梳理，效率显著提升。
1. 核心表结构（精简版，共7张表）
- 管理员表（admin）：id（主键）、username（账号）、password（MD5加密）、role（角色）；
- 用户表（yonghu）：id（主键）、yonghu_name（姓名）、yonghu_phone（手机号）、yonghu_photo（头像路径）；
- 垃圾回收表（huishou）：id（主键）、huishou_name（垃圾名称）、huishou_uuid_number（编号）、huishou_photo（照片路径）、huishou_kucun_number（库存）、huishou_address（回收地点）；
- 垃圾出库申请表（huishou_yuyue）：id（主键）、huishou_id（垃圾ID，外键关联垃圾表）、yonghu_id（用户ID，外键关联用户表）、huishou_yuyue_text（申请理由）、huishou_chuku_time（出库时间）、huishou_yuyue_yesno_types（申请状态）；
- 运输表（chuku）：id（主键）、chuku_name（运输名称）、chuku_address（运输地点）、chuku_mudi_address（目的地）、chuku_photo（运输照片）；
- 公告表（gonggao）：id（主键）、gonggao_name（标题）、gonggao_content（详情）、insert_time（发布时间）；
- 字典表（dictionary）：id（主键）、dic_code（字段）、index_name（编码名称），用于统一垃圾类型、申请状态等数据。
2. 核心关联测试
建表后立即验证关联逻辑，示例SQL：
SELECT h.huishou_name, h.huishou_kucun_number,
hy.huishou_yuyue_text, hy.huishou_chuku_time, hy.huishou_yuyue_yesno_types,
y.yonghu_name, y.yonghu_phone
FROM huishou h
JOIN huishou_yuyue hy ON h.id = hy.huishou_id
JOIN yonghu y ON hy.yonghu_id = y.id
WHERE h.id = 1;
若能查询出“垃圾信息+出库申请+用户信息”，说明关联正确；若报错，检查字段类型是否匹配（如huishou_id与垃圾表id是否同为Integer）。
关键避坑：切勿将垃圾照片、申请材料存入数据库！前期尝试导致数据库体积骤增（50张照片占250MB），改为存储文件路径（如/static/huishou/photo1.jpg），查询速度提升40%。
四、核心功能实现：3大模块满足答辩需求
无需开发所有功能，优先完成以下3个核心模块，突出开发重点：
1. 管理员端：垃圾管理与出库审核（必做）
- 核心逻辑：管理员录入垃圾信息（名称、库存、地点），生成唯一编号；审核用户出库申请，通过则更新垃圾库存，驳回需填写理由；
- 页面设计：用ElementUI表格展示垃圾列表，操作列设“编辑/删除/查看库存”；审核页面设“通过/驳回”按钮，驳回弹窗需填写理由（≥5字）。
2. 用户端：出库申请与垃圾查询（核心）
- 核心逻辑：用户按地点/类型筛选垃圾，查看库存；提交出库申请（选择垃圾、填写理由、预约时间），跟踪审核状态；
- 页面设计：垃圾列表用卡片式展示（含名称、库存、照片）；申请表单标红必填项，提交后显示“3个工作日内审核”提示。
3. 运输管理模块（答辩亮点）
- 核心逻辑：管理员录入运输信息（地点、目的地、照片），关联对应垃圾；用户可查看垃圾运输进度；
- 页面设计：运输列表展示运输状态（“在途/已完成”），点击“查看详情”可查看运输轨迹（模拟对接物流接口）。
五、测试与答辩：精简准备，高效通过
1. 核心测试用例
| 测试场景 | 操作步骤 | 预期结果 |
|---|---|---|
| 用户重复提交出库申请 | 提交同一垃圾的出库申请后，未刷新页面再次提交 | 提示“已提交申请，无需重复操作” |
| 管理员审核出库申请 | 审核通过某出库申请 | 垃圾库存减少，用户收到通过通知 |
2. 答辩准备技巧
- 演示流程：按“管理员录入垃圾→用户提交申请→管理员审核→查看运输进度”演示，重点展示“垃圾表与出库表关联逻辑”；
- 突出问题解决：讲清“双外键关联修复”“文件路径存储优化”等踩坑经历，比单纯讲技术栈更有说服力。
结语
本文核心是“聚焦垃圾分类核心业务、优先稳定技术、提前排查表关联问题”。毕设无需复杂功能，把垃圾管理、出库审核、运输跟踪做扎实，即可顺利通过答辩。
若需核心源码（带注释）、数据库脚本，可在评论区留言“SpringBoot垃圾分类系统”获取；开发中遇问题（如出库关联逻辑），也可留言咨询～ 祝毕设顺利！🎉
