简介本资源是一套面向高校计算机专业本科生毕业设计的智能垃圾分类系统完整实现方案聚焦微信小程序前端与Python后端图像识别技术的协同开发解决城市生活场景中人工分类效率低、准确率差的现实问题。压缩包共1360个文件含50个核心Python脚本含模型推理与API服务、300个JS/Vue/WXML前端逻辑文件、293张PNG图标与92张JPG测试样本图、132个Vue组件及86个JSON配置文件辅以SQL建库脚本、BAT一键部署批处理如install.bat、run.bat和MP4演示视频整体大小46.14MB。已有113人学习下载资源提供可直接运行的全栈代码、结构清晰的数据库文档、完整操作流程演示视频及初始化环境脚本覆盖从环境搭建、模型调用、接口联调到UI交互的全流程特别适合毕设选题参考、课程设计复现与AI小程序项目实战学习。 毕业设计做“基于微信小程序Python后端图像识别的智能垃圾分类系统”这个题目我在带学生和接私活的过程中见过不少自己也完整落地过一个版本。老实说这类系统在技术深度和工程完整性上都很适合做毕设但它最大的坑在于——很多同学把精力全花在训练模型上结果前后端缝合、小程序端云开发调用、数据库设计这些“脏活累活”反而没时间处理最后答辩演示时卡壳。这篇文章我不打算给你堆一个Demo式的项目介绍而是把我自己动手做这个系统的完整思路、关键代码逻辑、踩过的坑、以及如何让这个题目在答辩时显得“有深度”的经验完整拆给你。无论你是打算自己从零写还是想基于现成的源码和数据库文档去整理、复现和二次开发这篇内容都值得你收藏照着做。1. 项目整体设计与技术选型思路1.1 核心需求解析这个系统到底要解决什么问题智能垃圾分类系统的本质是通过图像识别替代“人眼判断”帮助用户在扔垃圾时快速确定垃圾属于可回收物、有害垃圾、厨余垃圾还是其他垃圾。国内目前的垃圾分类标准因城市而异但绝大多数城市都遵循“四分法”所以系统的主分类逻辑必须按这个维度走。除开图像识别这个核心点作为一套完整的毕业设计它还应该具备几块基础能力拍照识别用户通过微信小程序拍照或从相册选择一张垃圾图片交给后端识别返回垃圾类别和投放建议。文字检索作为图像识别失败时的兜底方案用户可以直接输入垃圾名称后台基于数据库做模糊查询。分类百科展示各类垃圾的详细说明、投放要点、常见物品示例方便用户主动学习。识别记录保存用户的历史识别记录方便回顾同时这也是答辩时展示“项目有完整数据闭环”的加分点。这套需求对技术栈的要求并不复杂但关键是每个模块都要落地并且能串起来。很多同学只做了识别功能其它几个模块都砍掉结果答辩时评委问“用户留存怎么体现”“数据从哪来”就答不上来这是比较亏的。1.2 技术选型背后的考量为什么是微信小程序 Python Flask PyTorch这套项目最稳妥的技术组合如下我逐个说明选型理由前端微信小程序原生开发。微信小程序在国内的普及度和生态成熟度不需要多说它自带相机调用接口wx.chooseMedia或wx.chooseImage有现成的wx.request做网络请求UI组件库可以用Vant Weapp有赞出品的小程序组件库样式漂亮、文档齐全整体开发效率远高于从零写Android/iOS应用。对于毕设而言小程序端的展示效果就是“能演示、能交互”原生开发最快达到这个目标。后端Python Flask。为什么不用Django这个项目规模不大Django这种重型框架自带Admin后台、ORM、模板引擎很多功能用不上反而增加学习成本。Flask轻量、灵活、上手快路由和请求处理一目了然答辩时能讲清楚每个接口的代码逻辑。如果你对异步有要求也可以换成FastAPI但如果之前没接触过我建议不要为了赶时髦临时换——毕设的稳定性优先于技术的新颖性。图像识别模型PyTorch ResNet18 或 MobileNetV3。这里分两种情况说明如果你打算从零训练一个垃圾分类模型首选是MobileNetV3-Small或ResNet18这类轻量级网络。ResNet18在结构上自带残差连接训练收敛稳定对新手友好MobileNetV3则在推理速度和模型体积上更有优势但训练时对学习率等超参数更敏感。如果时间紧张也可以直接迁移学习加载ImageNet预训练权重替换最后的全连接层为四分类然后冻结前面所有层只训练全连接层和最后几个残差块这样只需少量数据就能得到可用模型。数据库MySQL。虽然对比过SQLite但实际做下来还是推荐MySQL。SQLite做Demo足够但MySQL支持并发连接、事务管理更完善数据量大不担心锁库。用Navicat管理MySQL数据表比较顺手云端和本地数据库都可以连。后台管理Flask自带模板或Vue Element Admin。考虑到工作量优先用Flask Jinja2模板做一个简单的管理后台支持查看用户列表、管理垃圾词库和识别记录。如果代码基础好也可以折中成前后端分离但毕设不建议在这块过度投入。整个架构就是一条经典链路小程序 → 后端API → 模型推理服务 → MySQL。图片识别的完整流程是小程序端压缩图片 → 上传至Flask接口 → 服务端接收图片并调用PyTorch模型推理 → 返回分类结果和置信度 → 小程序端展示 → 同时后端将识别记录写入数据库。这个设计在答辩时非常容易讲清楚它是一个完整的“前端展示层 后端业务层 模型推理层 数据存储层”四层架构逐层递进结构清晰评委一听就明白。2. 图像识别核心模块从数据集到模型部署2.1 数据集准备先用公开数据集再考虑自建图像识别模型的表现严重依赖训练数据的质量和数量。这个项目的数据集准备我个人建议遵循“先跑通、再优化”的原则不要一上来就自己爬图、自己标注——时间成本极高。目前公开可用的垃圾分类数据集主要有这几个来源华为云垃圾分类数据集包含几十个类别的垃圾图片已经按类别分好目录下载后基本可以直接使用不需要额外标注。Kaggle的Garbage Classification数据集约几千张图分为纸板、玻璃、金属、纸张、塑料等几类适合做类别验证。不过它和“四分法”不完全一致需要按映射关系做合并。清华大学垃圾分类数据集较完整但需要申请权限。拿到原始数据集之后最关键的操作是类别映射。原始数据可能是几十个细分类比如塑料瓶、易拉罐、电池但系统要求的是四分类输出所以你得在代码里维护一个映射字典把细分类归并到对应的“可回收/有害/厨余/其他”大类中并同步生成统计图表每个大类有多少张图、各类别是否均衡方便写进论文。有一个非常烦人的问题原始数据集的图片尺寸、比例、质量参差不齐。如果不做统一预处理模型训练时的收敛速度和最终精度都会受影响。我在项目中使用的预处理流程如下统一缩放为224x224ResNet/MobileNet的标准输入尺寸随机水平翻转 随机旋转 15° 随机亮度饱和度扰动数据增强提升泛化能力归一化到 [0,1]并使用 ImageNet 的 mean 和 std 做标准化训练集、验证集、测试集的比例建议是8:1:1。如果你发现某些类别比如“有害垃圾”图片数量远少于其它类可以使用数据增强旋转、裁剪、色彩抖动等做过采样或使用类别权重class_weight来缓解样本不平衡否则模型会对多数类过拟合少数类识别率极低。2.2 训练细节与调参心得我在训练时使用的是 MobileNetV3 预训练权重 迁移学习最终在验证集上 Top-1 准确率约 92%。下面是我认为能直接复现的关键参数配置和心得优化器SGDmomentum0.9, weight_decay5e-4比 Adam 在这个任务上表现更稳尤其是训练中期之后的收敛效果。Adam 前期快但后期容易在最优值附近波动。学习率初始 0.001采用ReduceLROnPlateau策略验证集准确率连续 3 个 epoch 不提升就乘以 0.1最低降到 1e-6。Batch Size显卡显存够用的情况下设置 64如果显存不够就降到 32。Batch 太小会导致 BN 层统计不稳定。训练轮数冻结特征层只训练全连接约 5-8 个 epoch解冻全部层后再训练 20-30 个 epoch。核心原则是先让新分类头收敛再微调底层特征不要一上来就全量微调很容易破坏预训练权重。模型导出训练完成后用torch.jit.trace或torch.save导出模型。这里更推荐torch.jit.trace做脚本化导出这样部署时不需要完整依赖训练代码加载速度快且没有代码和历史版本耦合的问题。注意如果你使用的是 CPU 版本的 PyTorch训练可能非常慢建议在云 GPU 环境比如 Colab、AutoDL或学校实验室服务器上完成训练。CPU推理一个 224x224 图片约需要 200-500ms对小项目可以接受如果部署到服务器上建议开启 GPU CUDA 推理响应时间能压到 50ms 以内。2.3 模型服务化封装模型训练完成后不要直接在后端路由里加载模型因为每次请求都加载一次模型内存和耗时都扛不住。正确做法是写一个独立的模型服务类在启动 Flask 时预先加载模型然后各接口调用这个实例。核心代码逻辑可以参考import torch from torchvision import transforms from PIL import Image class ImageClassifier: def __init__(self, model_path, class_names, deviceNone): self.device device or (cuda if torch.cuda.is_available() else cpu) self.model torch.jit.load(model_path, map_locationself.device) self.model.eval() self.class_names class_names self.transform transforms.Compose([ transforms.Resize((224, 224)), transforms.ToTensor(), transforms.Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225]) ]) def predict(self, image_bytes): pil_image Image.open(io.BytesIO(image_bytes)).convert(RGB) input_tensor self.transform(pil_image).unsqueeze(0).to(self.device) with torch.no_grad(): outputs self.model(input_tensor) probs torch.softmax(outputs, dim1) conf, pred torch.max(probs, 1) return { category: self.class_names[pred.item()], confidence: round(conf.item(), 4) }然后 Flask 里的调用就变得非常干净classifier ImageClassifier(model.pt, [可回收, 有害, 厨余, 其他]) app.route(/api/recognize, methods[POST]) def recognize(): file request.files[image] image_bytes file.read() result classifier.predict(image_bytes) return jsonify(result)这种封装方式的好处是模型预热在启动阶段完成一次后续推理直接走内存中的模型实例无论并发请求多少都不会重复加载模型。3. 微信小程序端设计从页面到交互3.1 页面结构与核心功能清单小程序端我建议分为 5 个主页面每个页面的职责尽量单一这样后期维护和答辩讲解都轻松首页识别大按钮触发拍照/相册选择展示识别结果卡片包括分类名称、置信度、投放建议和相似物品参考。百科分类说明以 Tab 切换四个大类展示各类的详细说明、投放注意事项、常见物品列表。查询文字检索Input 输入垃圾名称请求后端模糊查询接口展示匹配结果及分类信息。记录历史记录展示本微信用户的历史识别记录按时间倒序每一条展示垃圾缩略图和识别结果。我的个人中心展示用户信息、系统说明以及“关于本项目”的入口可以放技术架构说明答辩时直接翻给评委看。核心交互流程是用户点击“拍照识别”→ 选择拍照或相册 → 得到图片 → 小程序端压缩图片 → 调后端/api/recognize→ 返回分类 → 渲染结果 → 写入历史记录。3.2 图片上传与压缩一个容易被忽视的细节微信小程序wx.chooseMedia或wx.chooseImage拿到的图片原始尺寸经常是 3000x3000 以上的高分辨率如果直接把原图上传不仅耗时后端还要做一次超大图的缩放非常浪费性能。正确做法是上传前先调用wx.compressImage压缩后再上传。我在项目中设置的压缩策略是wx.compressImage({ src: tempFilePath, quality: 70, success: (res) { const compressedPath res.tempFilePath; wx.uploadFile({ url: https://你的后端域名/api/recognize, filePath: compressedPath, name: image, success: (res) { const data JSON.parse(res.data); // 渲染识别结果 } }); } })压缩质量设为 70 在大部分手机上都足够清晰尺寸大幅下降一般从几 MB 降到一两百 KB上传速度和后端解析速度都快得多。这个细节在答辩时可以主动提出来展现你的工程意识。3.3 后端地址配置与网络请求封装小程序的网络请求必须走 HTTPS 域名且在微信公众平台配置合法域名。开发阶段有两个选择在“微信开发者工具”中勾选“不校验合法域名”这样可以直接用http://127.0.0.1:5000访问本地 Flask 服务适合开发调试。部署阶段把后端放到一台云服务器上配置 Nginx SSL 证书后再用 HTTPS 域名访问。我建议开发阶段使用本地调试 工具关闭校验的方式部署阶段再切换到服务器。这样至少能节省一天的云服务器配置时间。API 请求可以封装在一个request.js中const BASE_URL https://你的后端域名 function request(path, method, data) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL path, method: method, data: data, header: { Content-Type: application/json }, success: (res) { if (res.statusCode 200) { resolve(res.data) } else { reject(res) } }, fail: reject }) }) } module.exports { request, BASE_URL }统一封装的好处是当你把本地调试地址切到线上地址时只需要改一行BASE_URL其他所有调用处无需改动。这个设计也方便你在论文里写“前端网络层统一设计”。4. Python后端与数据库实现4.1 Flask后端接口设计后端接口按 RESTful 风格设计我这边规划的接口列表如下接口路径方法功能说明/api/recognizePOST上传垃圾图片返回分类结果/api/search?keywordxxxGET按垃圾名称模糊查询分类信息/api/history?openidxxxGET查询用户历史识别记录/api/historyDELETE清空历史记录/api/category/nameGET获取分类百科详情/api/feedbackPOST用户提交识别结果纠错反馈每个接口都做好参数校验和异常处理不要出现裸奔的 500 错误。比如/api/recognize中要处理“没有上传图片”“上传的不是有效图片”“模型推理超时”等情况统一返回 JSON 格式的错误信息方便前端处理。4.2 MySQL表结构设计与实现数据库是整个系统最容易“看起来简单”却又最容易翻车的地方。我设计的核心表如下可以直接参考用户表user字段名类型说明idINT PK AUTO_INCREMENT主键openidVARCHAR(64) UNIQUE微信用户唯一标识nicknameVARCHAR(64)昵称avatar_urlVARCHAR(256)头像地址create_timeDATETIME注册时间识别记录表recognition_record字段名类型说明idINT PK AUTO_INCREMENT主键user_idINT关联用户表image_urlVARCHAR(256)垃圾图片存储路径result_categoryVARCHAR(16)识别结果大类confidenceFLOAT置信度feedbackVARCHAR(16)用户纠错反馈无/正确/错误create_timeDATETIME识别时间垃圾名称表garbage_item字段名类型说明idINT PK AUTO_INCREMENT主键nameVARCHAR(64)垃圾名称categoryVARCHAR(16)所属大类detailTEXT投放说明image_urlVARCHAR(256)示例图片建表语句中 MySQL 引擎推荐 InnoDB字符集使用 utf8mb4因为微信用户的昵称可能包含 emoji 表情utf8mb4 才能正常存储。4.3 图片存储策略图片上传后需要持久化项目中有两类图片需要存储用户识别时上传的垃圾图片百科和垃圾词库关联的示例图我采用的方案是识别图片保存到服务器本地uploads/目录按日期分目录存放访问时通过http://host/uploads/e0/xxxx.jpg访问。如果你用云服务器且有 OSS对象存储服务也可以对接 OSS 或 COS这样可以减轻服务器压力并且在论文里增加一个“云存储”亮点。如果只为本地上传做毕设本地存储完全够用。这里要特别提一个踩坑点上传文件时一定要校验文件后缀和大小防止恶意文件上传攻击。可以在 Flask 中做如下限制ALLOWED_EXTENSIONS {png, jpg, jpeg, bmp, webp} def allowed_file(filename): return . in filename and filename.rsplit(., 1)[1].lower() in ALLOWED_EXTENSIONS def upload_file(): file request.files[image] if file and allowed_file(file.filename): # 保存 ...如果不对文件类型做校验服务器被上传恶意脚本的极端情况也不是不可能发生这个小细节在信息安全日显得尤为重要。5. 三种最容易踩的坑与排查实录这个项目开发过程中肯定会遇到一些奇怪的问题我把自己和学员们的踩坑经历整理成一份排查手册基本能覆盖你毕设过程中的绝大多数问题。5.1 小程序真机预览时无法使用本地后端现象在微信开发者工具里一切正常传代码到手机预览后接口请求全部失败。原因微信小程序运行在真机上时127.0.0.1指向的是手机本身不是电脑的本地服务。手机需要一个可以访问到电脑的局域网 IP且电脑防火墙要允许外部访问 Flask 的端口。解决开发阶段把电脑和手机连到同一个 Wi-Fi用ipconfigWindows或ifconfigMac查看电脑的局域网 IP在 Flask 启动时指定host0.0.0.0然后小程序端的BASE_URL改成http://电脑IP:5000在开发者工具中勾选“不校验合法域名”真机预览时在手机端打开“调试模式”即可正常工作。5.2 图片上传后后端报“413 Request Entity Too Large”现象在小程序端选了一张比较大的图片上传后端返回 413。原因Flask/Werkzeug 默认限制请求体大小为 1MB超过直接拒绝。解决在 Flask 配置中调大限制app Flask(__name__) app.config[MAX_CONTENT_LENGTH] 8 * 1024 * 1024 # 8MB同时在小程序端做好压缩双重保障。5.3 模型推理输出全为同一类别现象测试时无论输入什么图片模型都返回同一个类别且置信度非常高比如 99%。原因这不是模型训练的问题而是推理预处理和后端输入不一致。比如训练时用的是 RGB 三通道正常图片但后端读图后除了convert(RGB)外还做了多余操作或者归一化参数不一致。解决在predict方法中保持训练时完全一致的预处理逻辑不要做差异化的 Resize 或 Normalize。我在排查这类问题时一般会在推理代码中加入一个临时分支把输入模型的张量保存为图片比较它和训练样本的预处理结果一眼就能看出差异。5.4 MySQL 中文乱码现象数据库表中插入中文垃圾名称后显示为问号或乱码。原因数据库或表的字符集不是 utf8mb4或者连接字符串没有指定字符集。解决创建数据库时指定CREATE DATABASE garbage_classification DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;在 Flask 的 SQLAlchemy 连接串中加上charsetutf8mb4SQLALCHEMY_DATABASE_URI mysqlpymysql://username:passwordlocalhost/garbage_classification?charsetutf8mb45.5 毕设演示时的模型下载路径问题现象本地运行项目运行时一切正常换到另一台电脑比如答辩现场的笔记本跑模型加载报错“No such file or directory”。原因模型文件路径用了绝对路径比如E:/graduation/model.pth换电脑后路径失效。解决在代码中用动态路径方式定位模型文件import os BASE_DIR os.path.dirname(os.path.abspath(__file__)) MODEL_PATH os.path.join(BASE_DIR, models, model.pt)这样无论项目文件夹放在哪里都能正确找到模型文件。这一条在答辩前一定要检查真到了现场才发现路径不对就只能尴尬地对着评委解释了。6. 项目部署上线与工程化进阶建议6.1 本地上线到云服务器如果条件允许建议把系统部署到云服务器让评委在手机上直接体验。部署整体流程是购买云服务器2核4G以上的配置比较稳妥CPU推理不至于太慢安装 Python 3.9、MySQL、Nginx、Caddy自动申请 SSL上传后端代码到服务器安装依赖用 Gunicorn 启动 Flask 服务gunicorn -w 2 -b 127.0.0.1:5000 app:app配置 Nginx 反向代理将 80/443 端口转发到 5000在小程序后台配置 HTTPS 合法域名用本人微信号添加到公众平台测试成员真机体验这个完整部署过程需要有服务器基本操作经验如果没接触过 Linux建议提前两天专门练习一下。一旦部署成功答辩时直接“掏出手机扫一下小程序码现场扔一个垃圾图片识别”这个演示效果远强于录像或 PPT。6.2 从“能跑”到“优秀”的三个加分点如果你的进度比较快可以从下面三个方面再打磨打磨让项目从“合格毕设”档位跳到“优秀毕设”档位加分点一识别结果纠错闭环。在识别结果下方增加“识别正确/识别错误”的反馈按钮后端记录反馈数据定期将反馈数据导出到训练集形成“模型迭代闭环”。这在论文中可以作为后续展望部分的重要支撑表明你不只是做了一次静态识别而是设计了反馈积累机制。加分点二置信度阈值与兜底策略。当模型置信度低于阈值如 0.6时前端不直接输出分类名而是显示“识别置信度较低建议手动搜索确认”同时调用文字检索接口展示相似垃圾品类。这一设计能显著减少用户对错误结果的反感也体现你对模型预测质量的认知。加分点三分布式推理演进方案。如果后端用 Flask 承接所有请求在高并发下性能接近上限可以在论文中设计一个“模型推理服务与业务服务分离”的演进方案通过独立推理微服务承载模型调用后端只做请求转发和业务持久化接口设计完全兼容。虽然是展望性内容但能有效证明你有架构扩展思维。7. 个人实操心得与最后叮嘱这个项目做到现在前前后后我至少接触过四个同学用同题目的不同状态有的是交了论文初稿但代码还没跑通有的是模型精度很高但小程序端一塌糊涂也有的是全套能跑但没有任何亮点。我自己体会最深的一点是这个项目真正的难点不在单个环节而在全链路的整合与工程化。如果你是从零开始动手我会给你的执行顺序建议是先花两天时间跑通最小链路小程序上传一张图 → Flask 接收保存 → 给定一张固定测试图的模型推理 → 返回结果。不管精度多低先把链路打通。再在链路基础上逐步替换模型、优化精度、补齐其它模块。最后统一数据一致性字段格式、返回 JSON 结构、数据库表字段的映射关系避免前端改来改去和后端对不上。还有一个小技巧是这个项目的所有 API 接口都建议加上一个简单的 Token 校验哪怕只是前端拼接一个固定字符串放在 Header 里。这样能避免别人随随便便就能调用你的后端接口掏空数据库也让论文中“安全设计”有内容可写。虽然实现简单但反映的是工程习惯在答辩中问到时说明自己的安全设计思路也是一个容易被忽视的提分点。最后再说一句这个项目如果只是图省事直接照抄别人的源码答辩时难免被问住但如果把每一层架构、每个接口、每条数据流都理解透了哪怕是基于现成源码做的二开你也能像一个真正做出来的工程师那样去讨论问题。动手多调试、多报错你就会发现代码世界里几乎不存在解决不了的问题。本文还有配套的精品资源点击获取
简介本资源是一套面向高校计算机专业本科生毕业设计的智能垃圾分类系统完整实现方案聚焦微信小程序前端与Python后端图像识别技术的协同开发解决城市生活场景中人工分类效率低、准确率差的现实问题。压缩包共1360个文件含50个核心Python脚本含模型推理与API服务、300个JS/Vue/WXML前端逻辑文件、293张PNG图标与92张JPG测试样本图、132个Vue组件及86个JSON配置文件辅以SQL建库脚本、BAT一键部署批处理如install.bat、run.bat和MP4演示视频整体大小46.14MB。已有113人学习下载资源提供可直接运行的全栈代码、结构清晰的数据库文档、完整操作流程演示视频及初始化环境脚本覆盖从环境搭建、模型调用、接口联调到UI交互的全流程特别适合毕设选题参考、课程设计复现与AI小程序项目实战学习。 毕业设计做“基于微信小程序Python后端图像识别的智能垃圾分类系统”这个题目我在带学生和接私活的过程中见过不少自己也完整落地过一个版本。老实说这类系统在技术深度和工程完整性上都很适合做毕设但它最大的坑在于——很多同学把精力全花在训练模型上结果前后端缝合、小程序端云开发调用、数据库设计这些“脏活累活”反而没时间处理最后答辩演示时卡壳。这篇文章我不打算给你堆一个Demo式的项目介绍而是把我自己动手做这个系统的完整思路、关键代码逻辑、踩过的坑、以及如何让这个题目在答辩时显得“有深度”的经验完整拆给你。无论你是打算自己从零写还是想基于现成的源码和数据库文档去整理、复现和二次开发这篇内容都值得你收藏照着做。1. 项目整体设计与技术选型思路1.1 核心需求解析这个系统到底要解决什么问题智能垃圾分类系统的本质是通过图像识别替代“人眼判断”帮助用户在扔垃圾时快速确定垃圾属于可回收物、有害垃圾、厨余垃圾还是其他垃圾。国内目前的垃圾分类标准因城市而异但绝大多数城市都遵循“四分法”所以系统的主分类逻辑必须按这个维度走。除开图像识别这个核心点作为一套完整的毕业设计它还应该具备几块基础能力拍照识别用户通过微信小程序拍照或从相册选择一张垃圾图片交给后端识别返回垃圾类别和投放建议。文字检索作为图像识别失败时的兜底方案用户可以直接输入垃圾名称后台基于数据库做模糊查询。分类百科展示各类垃圾的详细说明、投放要点、常见物品示例方便用户主动学习。识别记录保存用户的历史识别记录方便回顾同时这也是答辩时展示“项目有完整数据闭环”的加分点。这套需求对技术栈的要求并不复杂但关键是每个模块都要落地并且能串起来。很多同学只做了识别功能其它几个模块都砍掉结果答辩时评委问“用户留存怎么体现”“数据从哪来”就答不上来这是比较亏的。1.2 技术选型背后的考量为什么是微信小程序 Python Flask PyTorch这套项目最稳妥的技术组合如下我逐个说明选型理由前端微信小程序原生开发。微信小程序在国内的普及度和生态成熟度不需要多说它自带相机调用接口wx.chooseMedia或wx.chooseImage有现成的wx.request做网络请求UI组件库可以用Vant Weapp有赞出品的小程序组件库样式漂亮、文档齐全整体开发效率远高于从零写Android/iOS应用。对于毕设而言小程序端的展示效果就是“能演示、能交互”原生开发最快达到这个目标。后端Python Flask。为什么不用Django这个项目规模不大Django这种重型框架自带Admin后台、ORM、模板引擎很多功能用不上反而增加学习成本。Flask轻量、灵活、上手快路由和请求处理一目了然答辩时能讲清楚每个接口的代码逻辑。如果你对异步有要求也可以换成FastAPI但如果之前没接触过我建议不要为了赶时髦临时换——毕设的稳定性优先于技术的新颖性。图像识别模型PyTorch ResNet18 或 MobileNetV3。这里分两种情况说明如果你打算从零训练一个垃圾分类模型首选是MobileNetV3-Small或ResNet18这类轻量级网络。ResNet18在结构上自带残差连接训练收敛稳定对新手友好MobileNetV3则在推理速度和模型体积上更有优势但训练时对学习率等超参数更敏感。如果时间紧张也可以直接迁移学习加载ImageNet预训练权重替换最后的全连接层为四分类然后冻结前面所有层只训练全连接层和最后几个残差块这样只需少量数据就能得到可用模型。数据库MySQL。虽然对比过SQLite但实际做下来还是推荐MySQL。SQLite做Demo足够但MySQL支持并发连接、事务管理更完善数据量大不担心锁库。用Navicat管理MySQL数据表比较顺手云端和本地数据库都可以连。后台管理Flask自带模板或Vue Element Admin。考虑到工作量优先用Flask Jinja2模板做一个简单的管理后台支持查看用户列表、管理垃圾词库和识别记录。如果代码基础好也可以折中成前后端分离但毕设不建议在这块过度投入。整个架构就是一条经典链路小程序 → 后端API → 模型推理服务 → MySQL。图片识别的完整流程是小程序端压缩图片 → 上传至Flask接口 → 服务端接收图片并调用PyTorch模型推理 → 返回分类结果和置信度 → 小程序端展示 → 同时后端将识别记录写入数据库。这个设计在答辩时非常容易讲清楚它是一个完整的“前端展示层 后端业务层 模型推理层 数据存储层”四层架构逐层递进结构清晰评委一听就明白。2. 图像识别核心模块从数据集到模型部署2.1 数据集准备先用公开数据集再考虑自建图像识别模型的表现严重依赖训练数据的质量和数量。这个项目的数据集准备我个人建议遵循“先跑通、再优化”的原则不要一上来就自己爬图、自己标注——时间成本极高。目前公开可用的垃圾分类数据集主要有这几个来源华为云垃圾分类数据集包含几十个类别的垃圾图片已经按类别分好目录下载后基本可以直接使用不需要额外标注。Kaggle的Garbage Classification数据集约几千张图分为纸板、玻璃、金属、纸张、塑料等几类适合做类别验证。不过它和“四分法”不完全一致需要按映射关系做合并。清华大学垃圾分类数据集较完整但需要申请权限。拿到原始数据集之后最关键的操作是类别映射。原始数据可能是几十个细分类比如塑料瓶、易拉罐、电池但系统要求的是四分类输出所以你得在代码里维护一个映射字典把细分类归并到对应的“可回收/有害/厨余/其他”大类中并同步生成统计图表每个大类有多少张图、各类别是否均衡方便写进论文。有一个非常烦人的问题原始数据集的图片尺寸、比例、质量参差不齐。如果不做统一预处理模型训练时的收敛速度和最终精度都会受影响。我在项目中使用的预处理流程如下统一缩放为224x224ResNet/MobileNet的标准输入尺寸随机水平翻转 随机旋转 15° 随机亮度饱和度扰动数据增强提升泛化能力归一化到 [0,1]并使用 ImageNet 的 mean 和 std 做标准化训练集、验证集、测试集的比例建议是8:1:1。如果你发现某些类别比如“有害垃圾”图片数量远少于其它类可以使用数据增强旋转、裁剪、色彩抖动等做过采样或使用类别权重class_weight来缓解样本不平衡否则模型会对多数类过拟合少数类识别率极低。2.2 训练细节与调参心得我在训练时使用的是 MobileNetV3 预训练权重 迁移学习最终在验证集上 Top-1 准确率约 92%。下面是我认为能直接复现的关键参数配置和心得优化器SGDmomentum0.9, weight_decay5e-4比 Adam 在这个任务上表现更稳尤其是训练中期之后的收敛效果。Adam 前期快但后期容易在最优值附近波动。学习率初始 0.001采用ReduceLROnPlateau策略验证集准确率连续 3 个 epoch 不提升就乘以 0.1最低降到 1e-6。Batch Size显卡显存够用的情况下设置 64如果显存不够就降到 32。Batch 太小会导致 BN 层统计不稳定。训练轮数冻结特征层只训练全连接约 5-8 个 epoch解冻全部层后再训练 20-30 个 epoch。核心原则是先让新分类头收敛再微调底层特征不要一上来就全量微调很容易破坏预训练权重。模型导出训练完成后用torch.jit.trace或torch.save导出模型。这里更推荐torch.jit.trace做脚本化导出这样部署时不需要完整依赖训练代码加载速度快且没有代码和历史版本耦合的问题。注意如果你使用的是 CPU 版本的 PyTorch训练可能非常慢建议在云 GPU 环境比如 Colab、AutoDL或学校实验室服务器上完成训练。CPU推理一个 224x224 图片约需要 200-500ms对小项目可以接受如果部署到服务器上建议开启 GPU CUDA 推理响应时间能压到 50ms 以内。2.3 模型服务化封装模型训练完成后不要直接在后端路由里加载模型因为每次请求都加载一次模型内存和耗时都扛不住。正确做法是写一个独立的模型服务类在启动 Flask 时预先加载模型然后各接口调用这个实例。核心代码逻辑可以参考import torch from torchvision import transforms from PIL import Image class ImageClassifier: def __init__(self, model_path, class_names, deviceNone): self.device device or (cuda if torch.cuda.is_available() else cpu) self.model torch.jit.load(model_path, map_locationself.device) self.model.eval() self.class_names class_names self.transform transforms.Compose([ transforms.Resize((224, 224)), transforms.ToTensor(), transforms.Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225]) ]) def predict(self, image_bytes): pil_image Image.open(io.BytesIO(image_bytes)).convert(RGB) input_tensor self.transform(pil_image).unsqueeze(0).to(self.device) with torch.no_grad(): outputs self.model(input_tensor) probs torch.softmax(outputs, dim1) conf, pred torch.max(probs, 1) return { category: self.class_names[pred.item()], confidence: round(conf.item(), 4) }然后 Flask 里的调用就变得非常干净classifier ImageClassifier(model.pt, [可回收, 有害, 厨余, 其他]) app.route(/api/recognize, methods[POST]) def recognize(): file request.files[image] image_bytes file.read() result classifier.predict(image_bytes) return jsonify(result)这种封装方式的好处是模型预热在启动阶段完成一次后续推理直接走内存中的模型实例无论并发请求多少都不会重复加载模型。3. 微信小程序端设计从页面到交互3.1 页面结构与核心功能清单小程序端我建议分为 5 个主页面每个页面的职责尽量单一这样后期维护和答辩讲解都轻松首页识别大按钮触发拍照/相册选择展示识别结果卡片包括分类名称、置信度、投放建议和相似物品参考。百科分类说明以 Tab 切换四个大类展示各类的详细说明、投放注意事项、常见物品列表。查询文字检索Input 输入垃圾名称请求后端模糊查询接口展示匹配结果及分类信息。记录历史记录展示本微信用户的历史识别记录按时间倒序每一条展示垃圾缩略图和识别结果。我的个人中心展示用户信息、系统说明以及“关于本项目”的入口可以放技术架构说明答辩时直接翻给评委看。核心交互流程是用户点击“拍照识别”→ 选择拍照或相册 → 得到图片 → 小程序端压缩图片 → 调后端/api/recognize→ 返回分类 → 渲染结果 → 写入历史记录。3.2 图片上传与压缩一个容易被忽视的细节微信小程序wx.chooseMedia或wx.chooseImage拿到的图片原始尺寸经常是 3000x3000 以上的高分辨率如果直接把原图上传不仅耗时后端还要做一次超大图的缩放非常浪费性能。正确做法是上传前先调用wx.compressImage压缩后再上传。我在项目中设置的压缩策略是wx.compressImage({ src: tempFilePath, quality: 70, success: (res) { const compressedPath res.tempFilePath; wx.uploadFile({ url: https://你的后端域名/api/recognize, filePath: compressedPath, name: image, success: (res) { const data JSON.parse(res.data); // 渲染识别结果 } }); } })压缩质量设为 70 在大部分手机上都足够清晰尺寸大幅下降一般从几 MB 降到一两百 KB上传速度和后端解析速度都快得多。这个细节在答辩时可以主动提出来展现你的工程意识。3.3 后端地址配置与网络请求封装小程序的网络请求必须走 HTTPS 域名且在微信公众平台配置合法域名。开发阶段有两个选择在“微信开发者工具”中勾选“不校验合法域名”这样可以直接用http://127.0.0.1:5000访问本地 Flask 服务适合开发调试。部署阶段把后端放到一台云服务器上配置 Nginx SSL 证书后再用 HTTPS 域名访问。我建议开发阶段使用本地调试 工具关闭校验的方式部署阶段再切换到服务器。这样至少能节省一天的云服务器配置时间。API 请求可以封装在一个request.js中const BASE_URL https://你的后端域名 function request(path, method, data) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL path, method: method, data: data, header: { Content-Type: application/json }, success: (res) { if (res.statusCode 200) { resolve(res.data) } else { reject(res) } }, fail: reject }) }) } module.exports { request, BASE_URL }统一封装的好处是当你把本地调试地址切到线上地址时只需要改一行BASE_URL其他所有调用处无需改动。这个设计也方便你在论文里写“前端网络层统一设计”。4. Python后端与数据库实现4.1 Flask后端接口设计后端接口按 RESTful 风格设计我这边规划的接口列表如下接口路径方法功能说明/api/recognizePOST上传垃圾图片返回分类结果/api/search?keywordxxxGET按垃圾名称模糊查询分类信息/api/history?openidxxxGET查询用户历史识别记录/api/historyDELETE清空历史记录/api/category/nameGET获取分类百科详情/api/feedbackPOST用户提交识别结果纠错反馈每个接口都做好参数校验和异常处理不要出现裸奔的 500 错误。比如/api/recognize中要处理“没有上传图片”“上传的不是有效图片”“模型推理超时”等情况统一返回 JSON 格式的错误信息方便前端处理。4.2 MySQL表结构设计与实现数据库是整个系统最容易“看起来简单”却又最容易翻车的地方。我设计的核心表如下可以直接参考用户表user字段名类型说明idINT PK AUTO_INCREMENT主键openidVARCHAR(64) UNIQUE微信用户唯一标识nicknameVARCHAR(64)昵称avatar_urlVARCHAR(256)头像地址create_timeDATETIME注册时间识别记录表recognition_record字段名类型说明idINT PK AUTO_INCREMENT主键user_idINT关联用户表image_urlVARCHAR(256)垃圾图片存储路径result_categoryVARCHAR(16)识别结果大类confidenceFLOAT置信度feedbackVARCHAR(16)用户纠错反馈无/正确/错误create_timeDATETIME识别时间垃圾名称表garbage_item字段名类型说明idINT PK AUTO_INCREMENT主键nameVARCHAR(64)垃圾名称categoryVARCHAR(16)所属大类detailTEXT投放说明image_urlVARCHAR(256)示例图片建表语句中 MySQL 引擎推荐 InnoDB字符集使用 utf8mb4因为微信用户的昵称可能包含 emoji 表情utf8mb4 才能正常存储。4.3 图片存储策略图片上传后需要持久化项目中有两类图片需要存储用户识别时上传的垃圾图片百科和垃圾词库关联的示例图我采用的方案是识别图片保存到服务器本地uploads/目录按日期分目录存放访问时通过http://host/uploads/e0/xxxx.jpg访问。如果你用云服务器且有 OSS对象存储服务也可以对接 OSS 或 COS这样可以减轻服务器压力并且在论文里增加一个“云存储”亮点。如果只为本地上传做毕设本地存储完全够用。这里要特别提一个踩坑点上传文件时一定要校验文件后缀和大小防止恶意文件上传攻击。可以在 Flask 中做如下限制ALLOWED_EXTENSIONS {png, jpg, jpeg, bmp, webp} def allowed_file(filename): return . in filename and filename.rsplit(., 1)[1].lower() in ALLOWED_EXTENSIONS def upload_file(): file request.files[image] if file and allowed_file(file.filename): # 保存 ...如果不对文件类型做校验服务器被上传恶意脚本的极端情况也不是不可能发生这个小细节在信息安全日显得尤为重要。5. 三种最容易踩的坑与排查实录这个项目开发过程中肯定会遇到一些奇怪的问题我把自己和学员们的踩坑经历整理成一份排查手册基本能覆盖你毕设过程中的绝大多数问题。5.1 小程序真机预览时无法使用本地后端现象在微信开发者工具里一切正常传代码到手机预览后接口请求全部失败。原因微信小程序运行在真机上时127.0.0.1指向的是手机本身不是电脑的本地服务。手机需要一个可以访问到电脑的局域网 IP且电脑防火墙要允许外部访问 Flask 的端口。解决开发阶段把电脑和手机连到同一个 Wi-Fi用ipconfigWindows或ifconfigMac查看电脑的局域网 IP在 Flask 启动时指定host0.0.0.0然后小程序端的BASE_URL改成http://电脑IP:5000在开发者工具中勾选“不校验合法域名”真机预览时在手机端打开“调试模式”即可正常工作。5.2 图片上传后后端报“413 Request Entity Too Large”现象在小程序端选了一张比较大的图片上传后端返回 413。原因Flask/Werkzeug 默认限制请求体大小为 1MB超过直接拒绝。解决在 Flask 配置中调大限制app Flask(__name__) app.config[MAX_CONTENT_LENGTH] 8 * 1024 * 1024 # 8MB同时在小程序端做好压缩双重保障。5.3 模型推理输出全为同一类别现象测试时无论输入什么图片模型都返回同一个类别且置信度非常高比如 99%。原因这不是模型训练的问题而是推理预处理和后端输入不一致。比如训练时用的是 RGB 三通道正常图片但后端读图后除了convert(RGB)外还做了多余操作或者归一化参数不一致。解决在predict方法中保持训练时完全一致的预处理逻辑不要做差异化的 Resize 或 Normalize。我在排查这类问题时一般会在推理代码中加入一个临时分支把输入模型的张量保存为图片比较它和训练样本的预处理结果一眼就能看出差异。5.4 MySQL 中文乱码现象数据库表中插入中文垃圾名称后显示为问号或乱码。原因数据库或表的字符集不是 utf8mb4或者连接字符串没有指定字符集。解决创建数据库时指定CREATE DATABASE garbage_classification DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;在 Flask 的 SQLAlchemy 连接串中加上charsetutf8mb4SQLALCHEMY_DATABASE_URI mysqlpymysql://username:passwordlocalhost/garbage_classification?charsetutf8mb45.5 毕设演示时的模型下载路径问题现象本地运行项目运行时一切正常换到另一台电脑比如答辩现场的笔记本跑模型加载报错“No such file or directory”。原因模型文件路径用了绝对路径比如E:/graduation/model.pth换电脑后路径失效。解决在代码中用动态路径方式定位模型文件import os BASE_DIR os.path.dirname(os.path.abspath(__file__)) MODEL_PATH os.path.join(BASE_DIR, models, model.pt)这样无论项目文件夹放在哪里都能正确找到模型文件。这一条在答辩前一定要检查真到了现场才发现路径不对就只能尴尬地对着评委解释了。6. 项目部署上线与工程化进阶建议6.1 本地上线到云服务器如果条件允许建议把系统部署到云服务器让评委在手机上直接体验。部署整体流程是购买云服务器2核4G以上的配置比较稳妥CPU推理不至于太慢安装 Python 3.9、MySQL、Nginx、Caddy自动申请 SSL上传后端代码到服务器安装依赖用 Gunicorn 启动 Flask 服务gunicorn -w 2 -b 127.0.0.1:5000 app:app配置 Nginx 反向代理将 80/443 端口转发到 5000在小程序后台配置 HTTPS 合法域名用本人微信号添加到公众平台测试成员真机体验这个完整部署过程需要有服务器基本操作经验如果没接触过 Linux建议提前两天专门练习一下。一旦部署成功答辩时直接“掏出手机扫一下小程序码现场扔一个垃圾图片识别”这个演示效果远强于录像或 PPT。6.2 从“能跑”到“优秀”的三个加分点如果你的进度比较快可以从下面三个方面再打磨打磨让项目从“合格毕设”档位跳到“优秀毕设”档位加分点一识别结果纠错闭环。在识别结果下方增加“识别正确/识别错误”的反馈按钮后端记录反馈数据定期将反馈数据导出到训练集形成“模型迭代闭环”。这在论文中可以作为后续展望部分的重要支撑表明你不只是做了一次静态识别而是设计了反馈积累机制。加分点二置信度阈值与兜底策略。当模型置信度低于阈值如 0.6时前端不直接输出分类名而是显示“识别置信度较低建议手动搜索确认”同时调用文字检索接口展示相似垃圾品类。这一设计能显著减少用户对错误结果的反感也体现你对模型预测质量的认知。加分点三分布式推理演进方案。如果后端用 Flask 承接所有请求在高并发下性能接近上限可以在论文中设计一个“模型推理服务与业务服务分离”的演进方案通过独立推理微服务承载模型调用后端只做请求转发和业务持久化接口设计完全兼容。虽然是展望性内容但能有效证明你有架构扩展思维。7. 个人实操心得与最后叮嘱这个项目做到现在前前后后我至少接触过四个同学用同题目的不同状态有的是交了论文初稿但代码还没跑通有的是模型精度很高但小程序端一塌糊涂也有的是全套能跑但没有任何亮点。我自己体会最深的一点是这个项目真正的难点不在单个环节而在全链路的整合与工程化。如果你是从零开始动手我会给你的执行顺序建议是先花两天时间跑通最小链路小程序上传一张图 → Flask 接收保存 → 给定一张固定测试图的模型推理 → 返回结果。不管精度多低先把链路打通。再在链路基础上逐步替换模型、优化精度、补齐其它模块。最后统一数据一致性字段格式、返回 JSON 结构、数据库表字段的映射关系避免前端改来改去和后端对不上。还有一个小技巧是这个项目的所有 API 接口都建议加上一个简单的 Token 校验哪怕只是前端拼接一个固定字符串放在 Header 里。这样能避免别人随随便便就能调用你的后端接口掏空数据库也让论文中“安全设计”有内容可写。虽然实现简单但反映的是工程习惯在答辩中问到时说明自己的安全设计思路也是一个容易被忽视的提分点。最后再说一句这个项目如果只是图省事直接照抄别人的源码答辩时难免被问住但如果把每一层架构、每个接口、每条数据流都理解透了哪怕是基于现成源码做的二开你也能像一个真正做出来的工程师那样去讨论问题。动手多调试、多报错你就会发现代码世界里几乎不存在解决不了的问题。本文还有配套的精品资源点击获取
